In my last post I started talking about why your data might not be as secure as you think during an HTTPS session. We made it as far as the mandatory handshake requirements with SSL and TLS. In this post I’ll get into the optional features which is the start of where things can go wrong.

Optional portions of the SSL/TLS handshake

After the initial client/server exchange, the two end points are free to choose which options they feel are appropriate, depending on how the administrator has configured them. Next we could:

1. Client can check the authenticity of the server using local info
2. Client can go back to the trusted authority and check the certificates authenticity
3. Client can check the authenticity of the trusted authority’s issuing server
4. Client can send a copy of its digital certificate to the server
5. Server can validate the client’s digital certificate if it has one
6. Server can require the client to have a valid digital certificate

Wow! Lots of possibilities. We typically don’t implement the last three unless we have control of both ends of the connection (like with a VPN). For a secure connection to a Web server, we’re typically looking at just the first three possibilities.

How digital certificates work

First, let’s talk about those digital certificates. A digital certificate contains the public key for the entity described within the certificate. So the server is basically saying “This is who I am and here is my public key for asymmetrically encrypted communications”. The way you know you can trust this certificate is that it has been digitally signed by a mutually trusted third party, like Verisign. Specifically, its been signed using the private key of a certain server under Verisign’s control. The concept is you can use the public key of the Verisign server to check the signature created by its private key. If the hash validates, you know the digital certificate has not been messed with.

OK, here’s our first problem. The information we use to validate the web server’s certificate is actually a copy of the Verisign server’s digital certificate stored on the local system. Hummm. So if the client becomes compromised, we can fool it into thinking a bogus digital certificate is actually legitimate, right? Absolutely. However this would only be useful in specific situations. If I can compromise the client there are probably easier ways to get access to the information I’m looking for.

If we want to ensure we’re safe however, we can go with option #3 above and check the validity of the locally stored Verisign certificate. This would send us out to Verisign server #2 to get its digital certificate. If we want to insure that our copy of Verisign server #1′s digital certificate is OK, we can use Verisign server #2′s public key to check the hash. If the hash validates, we know the digital certificate for Verisign server #1 is valid.

Hummm. So how do I know an attacker didn’t mess with the transfer of Verisign server #2′s digital certificate? Because that has been digitally signed by Verisign server #3. Go get that server’s public key and check the hash. How do I know Verisign server #3′s cert has not been messed with? You guessed it. Go get the digital certificate from Verisign server #4. While this sounds pretty complex (and it is!) this gives us sound math we can work with. In other words, smart crypto people can look at this math and predict how safe it is to use. Cool. I’m a geek so trusting math is a natural. The problem however occurs at the bottom of the rabbit hole.

Why should I trust you?

Eventually we will run into what is called a self signed digital certificate. This is basically a server’s way of saying “trust me because I say so”. In other words, there is no math to calculate if we should trust this server or not. All we have is “warm and fuzzy”. In other words, we need to sit in a Buda pose, sign Kum Ba Yah, get in touch with our inner child, pointy up our ears, and ask ourselves “How do we feel?”. Really, that’s all we’ve got, and there is no wrong answer because its subjective. If we “feel” that final system is secure, then it is. If we “feel” it is insecure than it is. There is no math to help point us in one direction or the other.

What if the trusted third party messes up?

So you may be asking yourself “All that sounds great, but what if the trusted third party makes a mistake and gives a digital certificate to the wrong party?”. First of all, that could NEVER happen. Oh wait, it has happened. Seriously, this is a valid concern as the chances of catching this after the fact are minimal.

Its possible to “revoke” a digital certificate. This is a trusted third party’s way of saying “Oops, we screwed up. You really should not trust that digital certificate we said is trustworthy”. So the concept is, when you get the Web server’s digital certificate you can go back to the issuing server to see if its been revoked.

OK, that’s set the groundwork for our HTTP session. In the next installment we’ll talk about what can specifically go wrong if we trust the security of the rabbit hole.

Related posts:

1. What does the little lock icon mean in my browser? – Part 3
2. What does the little lock icon mean in my browser? – Part 1

• Previous Entry: What does the little lock icon mean in my browser? – Part 1
• Next Entry: What does the little lock icon mean in my browser? – Part 3