TLS 1.2 for ssldump data decrypt revisited

A few months ago I posted a patch to SourceForge to add TLS1.2 data decrypt support to the ssldump tool. As the change was picked up, it became clear that the patch wasn’t decrypting properly for some ciphers. I spent some time looking at it but before I could figure it out, an email came to me from Paul Aurich, also from F5 (via our bug tracker)

From: Paul Aurich via bugzillaTo: David Holmes
2012-03-11 comment26The HMAC is dynamic, and is now part of the ciphersuite definition;for all ciphersuites specified in the TLSv1.2 RFC, it is SHA256,but other specifications (e.g. some of the TLS/GCM specs *do* usethe record layer MAC hash [when it's stronger than SHA256]).A simple change that may work (and may be future proof -- being atleast as strong as SHA256 is a SHOULD in RFC5246), but issomewhat ugly:digests[((ssl->cs->dig < DIG_SHA256) ? DIG_SHA256 : ssl->cs->dig) - 0x40](alternately: explicitly specify the TLS v1.2+ PRF in CipherSuites[])

Paul also pointed out that stream ciphers don’t have an initialization vector, a fact I knew since I still carry a torch for the RC4 cipher, but had neglected to account for in my code. Fortunately, the change was also a one-liner.

if (ssl->version>=0x0302 && ssl->cs->block > 1) {

After applying Paul’s tweaks, ssldump appears to be working on all the captures that I’ve thrown at it. If either Paul or I get a chance we’ll get these changes up to SourceForge. Until then, feel free to make apply his changes to the patch that I put up earlier.