.:SSLFail:.

This SSL Packet Trace is based on the Server View found here. My goal is to add useful hash information to the packet dump which in its original form only contained the state register values.

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.

Royal Pingdom has a post up mention that Netcraft has announced there are now one million sites that are using SSL. That’s valid certs, trusted by a third party, not expired and where the common name matches the hostname.  That’s a far cry from the 3293 found in Netcrafts first SSL survey.

Does this survey catch everything? Probably not, but it’s most likely a good starting point.

Now, how did Royal Pingdom determine that there are potentially 219K in expired certs? They based it on a 2007 survey from Venafi (referenced here), that said 18% of Fortune 1000 websites had expired certificates. They applied the percentage to the Netcraft total and, voila… 219K. They also go on to say that even if you have that it’s still 100K websites with expired certificates.

I’d be willing to wager a guess that if the number is off it’s mark, that it’s probably too low rather than two high. I encounter sites all the time with expired certs. Mind you, since we started SSLFail.com, I’ve had a harder time finding them.  However, I did happen to stumble across one just the other day and since we don’t feature screenshots with IE often enough… here you go.

OpenRCE.org Expired SSL

We just received a link to our own site. It would appear that someone was looking and discovered that we don’t have a SSL Enabled site. This is very true, but we’re not a large company with tons of visitors (in fact we’re still at less than 1000 unique visitors) and we’re not asking you for your passwords or allowing you to do online banking (however, feel free to email me your online banking information ).

We could setup a self-signed certificate to allow for encryption, but then you’d have to walk through those annoying “Add An Exception” screens for this site.

The reality of it is that not everyone needs SSL, although I’m sure in saying that even some of my fellow SSLFail.com bloggers will disagree with me.

That being said, if anyone feels we require a SSL cert, let me know… I doubt I’ll shell out the money for one, but maybe a SSL vendor will come along and read this and offer us one free of charge .

We are off the domain mismatch SSL Errors right now so I thought I would highlight another one that I find pretty often – Mixed Content Errors.

My (current) browser of choice Chrome defines Mixed Content Errors as;

“Your connection to www.website.com is encrypted with 128-bit encryption. However this page includes other resources which are not secure. These resources can be viewed by others in transit, and can be modified by an attacker to change the look or behavior of the page.”

Oh Noes!

Royalbank serving up mixed content

Here is HSBC doing so on its homepage

Continue reading…

[Update: apparently Romain and I posted the same image, so I've removed the image from my comment]

We recently had a link submitted (Thanks Jirka) that I think is a great example of betraying user trust in the SSL Realm. The link in question belongs to Microsoft and links to none other than their phishing filter FAQ. I can’t get this site to load without SSL in my browser (however, that could simply be network issues), so SSL is the only choice. I refuse to believe that Microsoft couldn’t afford a wildcard certificate to avoid this issue, or another IP address with a single domain cert. Sure once again, it may just be a ssl_error_bad_cert_domain error, but does this error need to exist?

Given my last post on ssl_error_bad_cert_domain error you probably wouldn’t expect me to post another one so soon, but I thought that this really demonstrated my point. Mike Murray posted to twitter earlier today that something was up with their SSL and asked if perhaps it was a compromise of sorts.  Tonight he sent us a a copy of the image. Mike’s a bright guy and well known in around InfoSec, if this made him question what was going on then I think it’s safe to say that these SSL error messages are a hindrance to our day to day use of the web.

I know I’ve already posted a Twitter SSL Fail in Chrome, but here’s the image Mike sent:

Twitter SSL Fail Image

Since the site went live and our first ssl_error_bad_cert_domain error (note: I will be using the Firefox error message to identify most of these errors) was posted, we’ve been receiving emails, comments and IMs regarding this SSL error and why it isn’t a security issue, and how we shouldn’t be posting them. There may be some truth in that, so many sites throw this error that it’s not even funny. I was sent lists yesterday that contained financial institutions, vendors and others who all had this error.

Now as a commenter mentioned this is just a matter of two domains pointing to the same A record. For the record though, it doesn’t necessarily have to be the same A record but more on that later. This issue was something I had in th back of my mind when I mentioned this concept to Marcin, and I’m really glad that people have picked up on it and mentioned it because I get to write this post already.

You see I could care less if there’s “no security implications” to the error message. Although I disagree with that, I believe it’s more accurate to say there’s “no technical security implications”. My concern with this error messages is user perception. The point that I wanted to make was just how plentiful these messages are in the latest round of browsers. However, it should be noted that Firefox is more lenient than IE7 and Chrome in some cases.

You can’t tell a user to “be wary” of SSL errors and know where they are going, there’s more to it than that. There are sites that may throw ssl_error_bad_cert_domain due to the cert containing or not containing ‘www’. There are, however, bigger errors that I’ve seen.

One of these errors may deserve it’s own discussion page, but instead we’ll discuss it here. The error can be seen on: reddit.com, westjet.com and others. The error message contains: The certificate is only valid for a248.e.akamai.net. Now anyone who’s reading this blog probably knows what Akamai is, but does your family know? Do your non-IT coworkers know? Does that person sitting across from you on transit know? Asking people to accept these is like opening the door to MitM. What happens when I MitM their connection and it asks them to accept a certificate that’s valid for loadbalance.mymaliciouswebsite.com. How does your average user know the difference?

So yes, to the technical this is a non-issue but to the people using the computer every day that know nothing about how it operates, or why it works… this is an issue. We’re training users to click through. People argued this point on Vista (it also happens on Ubuntu and OS X), that people would just always click. If this is a vald argument for operating systems, then we should be worried about what this means for web browsing. I encounter more SSL error pages daily than I do UAC pop-ups from Vista.

For those of you saying that doesn’t affect the encrypted status of the traffic, I ask that you remember that that is only one side of SSL. The other is as a form of verification, to authenticate that the site you’re visiting is the site that it says it is. This is where my concern comes from, this is the issue that I have. I should not visit my online banking website and see The certificate is only valid for a248.e.akamai.net but I know of at least one bank who’s main website brings up that message.

So how do we fix this? I’ve also been asked this question already. I guess the answer for that depends on where you think the problem lies. The simplest answer is most likely user education, but we all know educating a user is easier to say than it is to do. So who’s fault is it? Is it the fault of the browser for introducing all these “in your face” error messages? Is it the responsibility of the websites to purchase additional SSL certs to deal with these one off cases? Should certificate vendors be more open with pricing and bundling? I don’t really know the answer but I think it’s something we need to start thinking about.

Possible Fixes:

1. Browsers remove ssl_error_bad_cert_domain error for sites where stripping www. (or appending www.) leads to the domain identified in the certificate.
2. Website Owners purchase appropriate certificates, purchasing wild card SSL certificates to accomodate sites with multiple associated domain names or buying multiple certificates when their websites span multiple TLDs/ccTLDs
3. SSL Vendors provide greatly reduced rates to purchase certificates for multiple TLDs or decreased costs on wild card SSL certs (which interesting enough doesn’t have a price on the Verisign Wildcard SSL page)

I can think of a few other fixes, and a couple of theories that I’m in the process of testing.  I will incorporate updates to the list as I confirm my theories, but I also want people to suggest fixes in the comments.

So in the end will you continue to see ssl_error_bad_cert_domain error images posted? Most likely, however we will most likely stick to larger, popular sites and please know that we’re only doing it in hopes that the website owner will resolve the problem. Not to fix any technical errors (although we’ll always post people with technical issues) but to prevent users from learning to quickly click-through browser error messages.

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.