Re: Improving the SSL keys dialog, how to handle migrations?

[Peter Wu <peter () lekensteyn nl>]

On Sat, Oct 03, 2015 at 07:05:50PM +0200, Pascal Quantin wrote:
> Hi Peter,
>
> Some general comments in-line. I'm not a user of SSL/DTLS dissectors so I
> do not have any real suggestion for your proposals.
>
> Le 3 oct. 2015 6:53 PM, "Peter Wu" <peter () lekensteyn nl> a écrit :
> > Hi,
> >
> > So far SSL/DTLS private RSA key files were entered in an UAT dialog
> > (ssl_keys) using address, port, protocol, keyfile and password.
> >
> > Since the public key part of a private key is sufficient to match SSL
> > sessions for decryption (https://code.wireshark.org/review/10766), I
> > want to remove the former fields.
> >
> > The address+port mapping to SSL can already be substituted by Decode
> > As... SSL.
>
> Is it really similar? It only allows you to configure SSL for a given port,
> right? Isn't there the risk a port number being reused for non SSL
> communication with another address?

In the current implementation it is similar, even if the UI is
suggesting otherwise. That is why I am suggesting removal of it.
The address+port is only used for matching private keys (previously
tracked via the "SslService" struct)

The port is also a hint for TCP/UDP dissectors and additionally lets the
SSL dissector know that the port is handled by the configured protocol
(say, HTTP).

> > The port to app_handle (subprotocol) mapping is problematic (see
> > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10984#c12) and I
> > would like to remove it here, but I can imagine that some users want to
> > override the app_handle anyway. For those use cases, I am considering a
> > new Decode As setting (ssl.tcp_port, ssl.udp_port). (Limitation: since
> > you can only override per port, setting tcp/443 to spdy instead of http
> > might not have the intended effect.)
> >
> > How should I handle the UAT change? For simple preferences there is
> > prefs_register_obsolete_preference, but there is nothing for UATs AFAIK.
> > Maybe I can use Wireshark 2.0 as an excuse to break backwards
> > compatibility for this setting? Alternative option is to create a new
> > "ssl_keys2" file and import from "ssl_keys" if it does not already
> > exist (but this makes the code more ugly).
>
> Creating a ssl_keys2 file seems to be a seamless approach for users. But
> would it be complex to write? The deadline for 2.0 is soon...

It does not look trivial. The two patches that are now in Gerrit are
preparatory work (use RSA public key instead of address + port for
matching), the UI/UAT part needs more work.

The current UAT dialog is broken anyway, moving fields with tab does
not work and empty entries can be saved, bypassing UAT callbacks.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe