On Mon, Feb 23, 2015 at 03:32:48PM +0100, Gianrico wrote:
> I am looking for advices/opinions for a new feature.
>
> Basically I would like to have the possibility of specifying the inner
> app data protocol when dissecting/decrypting ssl/dtls using the keylog
> file.
>
> There are situations when the inner protocol might be a custom
> protocol (ssl vpn in my case).
> At the moment it looks like you can specify the inner protocol only
> when using the ssl key and uat table.
>
> By the way, for obvious reasons, when troubleshooting with third party
> captures it is becoming more frequent to receive the (pre)-master
> secret (when RSA in use).
>
> I have proposed this patch :
>
> https://code.wireshark.org/review/#/c/7233/
>
> Peter properly noted that this is a hack and it would be better to
> keep the keylog file clean and move the setting somewhere else.
SSL "keylog" suggests that it contains names, adding metadata could be
done, but I think there is a better approach. Consider what would happen
if this file is missing (but you have RSA keys), then the packets are
still not dissected as wanted.
It looks like that the current method of associating an application data
protocol with SSL is inflexible. It causes bugs such as
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10984 (worth
reading, it contains an analysis and some suggestions).
Your goal is likely to force the correct protocol on a SSL Application
Data stream. The current methods for this are:
- Add a heuristics dissector with heur_dissector_add("ssl", ...)
- Register with ssl_dissector_add(port, "proto", is_tcp)
Both have shortcomings:
- The heuristics dissector gets called for each packet even though
SSL/TLS is stream-oriented. Since you often cannot decrypt the
stream without knowing the decryption state, it is pretty much
guaranteed that the first packet is always available. As such, it
would make more sense to call the heuristics dissector only once for
the first packet.
- The ssl_dissector_add function allows for registration of only one
protocol per port.
I propose to make one or more of these changes:
- Call the heuristics dissector only for the first data frame.
- Decouple the list of valid protocols from
transport_proto/addr/server_port->appdata_proto/keyfile
associations. This allows for multiple valid protocols while linking
one unique key per transport_proto/address/server_port tuple.
(Jeff, comments?)
- Allow a wildcard protocol name in the UAT dialog just to set the key,
not the protocol ("any", "*" or the empty string?).
- Select an appdata protocol in this order: STARTTLS hint, heuristics,
associations, (first available) dissector hint.
Why the suggested protocol selection order?
- STARTTLS hint is quite strong.
- Good heuristics can do "the right thing" automatically.
- Associations are entered by the user.
- For protocols such as SMTP, there is one clear choice which is great.
For port 443, the best guess is HTTP (which should have been caught
by the heuristics dissector) but others are possible.
Gianrico, do you think that good heuristics is possible for your
protocols?
> I would like to have, anyway, the flexibility of having multiple app
> data dissector when multiple (pre)master kays are in the keylog file
> (see again proposed patch for an example)
>
> Please let me know your thoughts and if that makes sense to be
> implemented or should i just keep it for me.
A concern with the current approach would be backwards compatibility. By
using "PROTO 443,http RSA (pre-master) (masterkey)", the file becomes
useless for older Wireshark versions (and other implementations using
this file, if they exist).
--
Kind regards,
Peter Wu
https://lekensteyn.nl
Attachment:
pgp1_hHbCrTxu.pgp
Description: PGP signature
