document updated 14 years ago, on Aug 24, 2010
Once in a while, it's really useful to be able to use Wireshark to observe the plaintext inside an SSH or SSL connection, for debugging purposes. Here's how to do it:
These are whitehat techniques, and most assume that you have complete control over both the client and server, and are able to make configuration changes necessary to do disrobed logging.
- SSL
- SSH v2
- Step 1) obtain the session key somehow (TODO: how?). Step 2) Once you have the session key, Wireshark will NOT decrypt it itself, you have to use another tool to process the .pcap file first. (TODO: how?)
- cr0.org's ssh_decoder will decrypt a .pcap file
- Sandstorm Communications’ NetIntercept product reportedly does it, though it costs $$
- TODO: look into this more...
- reference material
- there are several numbers that exist by the end of key-exchange, that seem to be used for later encryption:
- session identifier — used to prevent replay attacks
- session key — a symmetric key, the key is known only to the server+client, and is used ONLY during this one session
- shared secret — a number that's used to derive the session key, but in a way that neither side knows the full session key
- as a fallback, there are several MITM programs that can do it that way:
- SSH v1
- For SSH v1, it may be sufficient to obtain the server key instead of the session key, to decrypt packet logs.
- you can use -c none to tell SSH-1 (but not SSH-2) to use "none" for the cipher
- there are plenty [1][2] of caveats, however