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

[Pascal Quantin <pascal.quantin () gmail com>]

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?

> 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...

Cheers,
Pascal.

___________________________________________________________________________
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