.:SSLFail:.

This is Part 1 of a series of posts about Netscape’s SSLv3 spec.

When working on my first SSL Client I went looking for the official RFC to correctly implement the SSLv3 protocol. Near total FAIL.

The SSLv3 protocol was created by Netscape back in 1995. The file that most people (continue to) reference is:

http://www.netscape.com/eng/ssl3/draft302.txt

Which is tragically some horrible 404 page now. Even Openssl.org continues to cite this as the official spec for SSLv3.

The file has been moved into the care of the The Mozilla Foundation and can now be found here:

http://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft302.txt

Once you have found the SSLv3 spec you get to read one of the most ambitious and sadly disappointing specs ever written. SSLv3 got so many ideas right and fell just short of explaining them in enough detail that developers could easily build their own clients. What saved SSLv3 was the set of packet traces of live connections that Netscape put together.

http://www.mozilla.org/projects/security/pki/nss/ssl/traces/index.html

They spoke the universal language of hex and came close to being the best illustration of this protocol in action. Unfortunately they too fell short of properly explaining what was going on. The non-client auth trace used export keys and the 128 bit RC4 trace used client-auth. This left out perhaps the most common scenario seen on the Internet – the high encryption (>=128 bit) non-client auth session.

What makes these connection traces difficult to construct (and annotate) is that by design SSL is difficult to sniff and recreate. Looking directly at encrypted traffic will do you little good in understanding the algorithms that encrypted it.

I am going to do my best to recreate the original Netscape traces as well as add some more modern traces of traffic typically seen today.

On with the show …
SSL_RSA_EXPORT_WITH_RC4_40_MD5 no client-auth.

PACKET 1 :: CLIENT >> SERVER

Although it is listed as an SSLv2 Client Hello it carries SSLv3 information. There was a time when there were HTTP servers on the Internet which only spoke SSLv2. By sending the SSLv3 information in an SSLv2 Client Hello users were able to safely contact tcp(443) without crashing servers. These days nearly all clients will default to TLSv1/SSLv3 so there is little reason to actually use this old format anymore.

The record layer is not considered part of the SSL Handshake and is usually listed separately – you will see why shortly.

The SSLv2 Client Hello (minus the record layer) is added to the handshake data. Why is this important? To complete the SSL Handshake (SSL Finished Message) all Handshake Data sent from both the Client and Server is required. When coding this you just keep concatenating these byte strings together.

Now as we trace through the SSL Connection this handshake data is going to get fairly large. The Netscape traces use an MD5 and SHA1 hash to track the progress. However they use the values of the internal hash registers, which for practical coding purposes is near useless. Listing the hash digest as you add data to it allows you follow along and ensure you have added the correct data.

Netscape lists the starting values of MD5 and SHA1 hashes as:

MD5 state: 67452301 efcdab89 98badcfe 10325476
SHA1 state: 67452301 efcdab89 98badcfe 10325476 c3d2e1f0

However if you were to create a brand new md5 or sha object (in Python) and call digest() you get:

MD5 Digest d41d8cd98f00b204e9800998ecf8427e
SHA Digest da39a3ee5e6b4b0d3255bfef95601890afd80709

I have not seen an easy way to view the internal state registers of these hash objects – and really why bother? Just list the digest instead …

If you search for the obscure hex strings above you will eventually find out they are the default starting values of MD5 and SHA1 state registers.

RFC 1321 Section 3.3

word A: 01 23 45 67
word B: 89 ab cd ef
word C: fe dc ba 98
word D: 76 54 32 10

FIPS 180 Section 5.3.1

0 H = 67452301
1 H = efcdab89
2 H = 98badcfe
3 H = 10325476
4 H = c3d2e1f0

I have no idea why Netscape chose this akward method of hash usage.

If you add the handshake data to your MD5 and SHA1 objects and check the digest you will see the following values for the first packet.

As is usually the case when studying the SSL Protocol, the most confusing parts are often the secondary protocols involved (of which there are a TON).

In Part 2 of this series I will explain the First Server Packet.