Who needs the Wireshark GUI right; let’s do this at the command line and be grown up about things. This is a straight copy of my popular Using Wireshark to Decode/Decrypt SSL/TLS Packets post, only using ssldump to decode/decrypt SSL/TLS packets at the CLI instead of Wireshark. Aside from the obvious advantages, immediacy and efficiency of a CLI tool, ssldump also provides some very useful, nicely parsed data around the SSL/TLS connection itself too. I’ve had cause to use this tool recently where writing a tcpdump to file and using Wireshark simply hasn’t been possible/permitted. This tool ‘saved the day’ I can tell you.

You might note that ssldump hasn’t been updated in a major way for over a decade (but has been ‘patched’ as late as 2013); not a problem, it still works a treat. +1 To the authors and the architecture of tools like this (including the original author, Eric Rescorla who has contributed to a significant number of RFCs (the last in 2013) but who also unfortunately played a part in Dual EC DRBG). Another free tool, another simple error waiting in the wings to cough bleed you dry? Not in the same league but really, security and it’s analysis etc. seems to rely on far too many tools and packages the authors of which simply don’t have the resources to maintain to a high standard. That, or they rely on other tools that don’t. If they can all contribute time, money and resources to ODL, why the heck can’t our favourite and/or trusted companies, vendors and ‘partners’ support the security realm a bit more too. Conflict of interest perhaps – if so, that’s sad and perhaps a comment on our culture. If security and safety are only worthwhile if there’s profit involved, well…

Isn’t SSL/TLS Secure?

Don’t let this article give you the impression it’s not; as you’ll see from the next section, there’s a good deal of requirements that must be met. However, there are plenty of other reasons to consider it insecure. If you’re reading this article and you’re responsible for and care about the privacy and security of your traffic, please keep in mind that SSL/TLS, in reality, presents no more than a façade of security today; in the same way money apparently represents real value and different sex marriages normality and stability.

A year on from the Wireshark version of this article and these comments, Heartbleed and POODLE still top the security pop charts and things have only gotten worse.

Ignoring our post-PRISM world for a moment (everyone is anyway right?); from a technical standpoint SSLv2 and SSLv3 (regardless of the ciphers etc. used with it) are widely considered as insecure. You really shouldn’t be using them; however, don’t just use TLS and consider that enough to offer a good security posture. How it’s configured and the options and ciphers you allow (or not) are far more important, but that’s an article for another day.

If you have an interest, I’d highly recommend you take a look at the possibilities around how things might improve, starting with this Security Collapse in the HTTPS Market article. It’s given me some hope at least.

Taking PRISM’s (and other country’s similar program’s) implications into account, frequent technical weaknesses exploited through techniques such as BEAST or BREACH, the ease with which a fake CA can be installed on most devices and the decidedly risky nature of ‘trusting’ any Certificate Authorities (CAs) after recent scandals and revelations, I’d have a hard time convincing anyone to use SSL/TLS. That is, if there was an alternative, which there isn’t. It probably doesn’t matter anyway, why try and break encryption when you can just knock on the door and ask politely like most government agencies and police forces can in some form or other.

I use self-signed certificates for the on-line services I run for myself; there’s a reason I run them myself. Any false security I may have had around any large organisation (including government) being as fallible and poorly organised as the people within it and unable to consume the necessary volume of information to be effective without genuinely prohibitive expense has vanished in recent years. Again, you can read more about that in a later article; I’m far from a security pro so take this whole section with a pinch of salt.

Requirements

I know this list seems pretty long; I don’t think that’s necessarily a bad thing; if you can’t meet all these requirements, you probably shouldn’t be attempting to decrypt the data. As ever, preparation is key; if you think you’ll need to do this even if just once a month, find out what you need to do to make meeting these prerequisites less onerous.

• A Linux host/system.
• The libpcap library (that comes with tcpdump).
• OpenSSL.
• The private key used to encrypt the data must be available on the system.
• The private key file must be in the a format supported by OpenSSL.
• The private key file should only contain the private key, not the public key (aka the certificate). Files frequently contain both, check by viewing the file in a true text editor. You only need the text delimited by the header and footer shown below;

  Header:

  —–BEGIN RSA PRIVATE KEY—–

  Footer:

  —–END RSA PRIVATE KEY—–

• RSA keys must have been used to encrypt the data.
• The capture must include both ‘sides’ of a conversation. In other words, the capture must include the full client and server exchange.
• Important: The capture must include the initial SSL/TLS session establishment. In other words, the CLIENTHELLO and SERVERHELLO exchange. Beware captures taken where a session has been resumed. Ideally, ensure any capture either a) is of packets related to an entirely new host connecting or b) where a host that has already previously established a session is used, it is used after a considerable time after the last session was established.
• Important: Ensure the use of a Diffie-Hellman Ephemeral (DHE/EDH) or RSA Ephemeral cipher suite is not negotiated between the two hosts. This is indicated by the use of aServerKeyExchange message. There is no way to decrypt data where ephemeral ciphers are used. You may need modify cipher strings on relevant hosts to ensure this is the case.

Using ssldump to Decode/Decrypt SSL/TLS Packets

This is the simple bit really, assuming ssldump is already installed on your Linux host. If its not it shouldn’t be too hard to install via your favourite package manager (the package name is ‘ssldump’).

Your syntax should be something like this:

• -k specifies the location of the key file to be used (also use -p password if its password protected0
• -i specifies the capture interface
• -d displays the application data
• -X display the application data in ASCII as well as Hex
• -n disabled host and port name resolution
• -q minimises information about the SSL/TLS session; if you need to debug the session itself obviously remove this (and the -d and -X parameters)
• ‘expression’ is a filter expression, see my tcpdump Expressions Masterclass for more detail on the subject if you need it

So, if, for example, you wanted capture and decrypt packets on interface eth0, to/from host 10.11.12.50 using a key located at /etc/stealmykeys/test.key you would use a command like this:

Job done, in real time… very satisfying. If you do want to use the tool with an existing .pcap file, no problem. Just use the -r parameter and don’t bother with -i.

Note fragmented packets are not supported.

Allowing Others to Decrypt Without The Private Key

Well, there’s good news and there is bad. You can’t send a .pcap file over or anything like that but you can just pipe the output to a file and send that instead. I’m all ears if there is a better way.

Update: I discovered this is possible using the -M option, on F5 gear at least, more details here. Shame they haven’t contributed to code back to the community.

Notes & Issues

• Ensure you’ve met all the requirements listed earlier.

• ssldump can only decrypt SSL/TLS packet data if RSA keys are used to encrypt the data. If a Diffie-Hellman Ephemeral (DHE) or RSA ephemeral cipher suite is used, the RSA keys are only used to secure the DH or RSA exchange, not encrypt the data. Thus, even if you have the correct RSA private key, you will not be able to decrypt the data with ssldump, Wireshark or any other tool. You can check which cipher suite is being used by examining the Server Hello packet sent by the host that holds the private key, if the cipher suite specified begins TLS_DHE or SSL_DHE, you will not be able to decrypt the data. If the server sends a ServerKeyExchangemessage, you will not be able to decrypt the data. I’ve no idea how to prevent RSA ephemeral use. For DHE, your only option (if possible) is to modify either the client or server configuration so that DHE cipher suites are not used.

• For Firefox, enter this URL in the address bar: about:config, click the warning button and then enter this in the filter bar: security.ssl3.dhe. Set each preference displayed to:false and then filter again for security.ssl3.ecdhe and do the same. Don’t forget to re-enable everything later.

• Server side (not recommended), if using OpenSSL you could also change any configured cipher strings to include !DHE and !ECDHE.

• With Java something like jdk.TLS.disabledALGORITHMS=DHE, ECDHE in the relevant place should suffice.

• The issue detailed above may also occur with exportable RSA cipher suites (those using keys under 1024 bits in size) which you shouldn’t be using anyway.

• ssldump can only decrypt SSL/TLS packet data if the capture includes the initial SSL/TLS session establishment. Re-used/resumed sessions cannot be decrypted; you can identify these as the server will not send a certificate.

• Check your PEM private key file contains the correct header and footer, as shown previously, and no others;

• Check your private key file is in a supported format.
• You can find the ssldump man page online here: http://www.rtfm.com/ssldump/Ssldump.html.

Summary

This can be a real life-saver and it can also be a real pain; especially if you tell others you can do it and then find the capture you have isn’t suitable or DHE or similar is in use. Make sure you caveat what might be possible and ideally, avoid the need to do this at all, it’s better that way.

Just as an aside, on the subject of performance, try using ECXXX where you can, the performance is great. (For those using F5’s, I don’t think these are ‘native’ so probably that negates the benefits.)

• If you’re trying to troubleshoot HTTP issues, you may be better off running iehttpheaders for IE or LiveHTTPHeaders for Firefox on the client browser. As noted in the comments below, you can also use the built in developer/debugging tools available in Chrome or Safari.
• Better yet, see my Viewing HTTP Headers Using Browser Developer Tools article for how to do this without plugins and the like.

I’d highly recommend the free Crypto 101 course/book for those new to this subject (or needing to brush up).