These are the starting values for your MD5 and SHA-1 Hash Objects.
State = useless
Hash = digest() of all handshake data seen so far
Buf Hash = digest() of all 64 byte blocked handshake data
Buffered Data = 63 or less bytes of data waiting to be added to the hashes

Now each handshake section of the packet is added to the hash objects in 64 byte blocks. If you do not yet have 64 bytes to add you simply hold onto them in a buffer.

While the hash states listed in the original packet traces were useless the buffered data was pretty handy, it was a clear indication of what pieces to add to the hash objects. In this packet we add 74 more bytes to the 52 we had saved up from before. After using up the first 64 bytes we are left with 62 left over.

This is where the packets start getting really long. Although the certificates are long (and very complicated) they are one of the very few SSL packets with ASCII printable text. When looking at a packet dump these are the most recognizable packets of an SSL transaction.

The following packet is where this demo trace really goes off the rails. Netscape chose to illustrate one of the more complicated capabilities of SSL. Although client side certificates are essential to SSL VPN connections, they are very seldom seen in standard HTTPS sessions.

Finally we get to the Server Hello Done message.

Client sends its identity to the Server. This step is not commonly seen.

Now here is the first packet with actual encryption. This packet contains the pre-master secret that has been asymmetrically encrypted with the server’s public key. This pre-master secret will be used to calculate the symmetric key. I will focus on this packet in a future post as it is very interesting.

Certificate Verify message – not commonly seen as client authentication is rare.

The Client Change Cipher Spec message is not included in the hashes. The Client Finished message however is. This packet (or portion of a packet) is the first symmetrically encrypted data we have seen so far. At this point in the handshake both the server and client posses a shared key.

When this packet is unencrypted you will find a message that can only be verified if you have all the handshake data seen thus far. This is a little harder than just adding a couple of captured packets, as several portions of the message need to be excluded (all record data and change cipher spec messages). The server then does the same thing with this newly included data and completes the handshake by constructing the server finished message. I will look at this final step in my next post.

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.