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