Quick and Dirty SSL Myth Busting

• By Joe Astorino
• April 9, 2014
• 5 Comments

Hi guys,

So, it is April, 2014 and the media is buzzing with news about the recent OpenSSL vulnerability known as heartbleed.  It’s a perfect time to refresh some basic knowledge on SSL and how it interacts with digital certificates. Part of the big problem with heartbleed, is that it can allow an attacker to obtain the web server’s private key. Obviously, this is a very very bad thing.  It could allow the attacker to pull of a successful man in the middle attack.  However, there seems to be a fairly well believed myth about SSL – The myth that says the servers private key is actually the piece responsible for the encryption and decryption of the actual HTTP data between the client and the server.  This is just not true, and I’m about to show you why.

So, quick and dirty here is basically how SSL works

The Certificate Request

First, the web server generates a public and private key pair.  I’m assuming you have basic knowledge of asymmetric encryption and how PKI works, and that you understand the private key is ONLY for you and the public key is…well public.  After the key pair is generated, you are going to make a certificate request to a trusted CA.  In that request, you are going to include all the relevant information, like your CN, your organization, etc etc..additionally you are going to provide the CA with your public key.

CA Signs Your Certificate

The CA receives your certificate request, and has validated one way or another that you are who you say you are.  The CA’s job at this point is to create your digital certificate, and digitally sign it.  OK, what exactly does that mean?  It means, the CA creates the digital certificate, that has all the information you submitted.  It then hashes the certificate, and encrypts the hash with the CA private key. Why does it do this?  When a client connects to your web server down the road, and pulls the digital certificate, the client wants to know that you are who you say you are. That authentication is purely based on the fact that “The CA says so” and the client trusts the CA. How does it work technically though?

To make sure your web server is who it says it is, the client will decrypt the hash of your certificate that the server encrypted with it’s private key (The digital signature). If the decryption is successful, the client will hash the now decrypted certificate and compare that hash it computed to the decrypted hash. If the two match,  it proves the CA signed the certificate because the only thing the public key you used to decrypt the hash can decrypt is something encrypted by the CA private key and only the CA has that key. At that point, the client knows for sure that the CA signed your certificate, which is basically saying the client knows that the CA vouches for you…and in PKI that is good enough. Through this proxy of trust, the client is now saying “Your server is indeed who it claims to be”

The Negotiation

Here is where we break the myth.  So, we have our fresh new shiny digital certificate.  Remember, this contains all our information like CN, OU, etc …as well as our public key AND a hash of our certificate that was encrypted by the CA’s private key…also known as a digital signature. Now, a client connects.  Here is the play by play

• Client initiates a connection to the server, and there are some SSL negotiations that take place.  Things like what cipher we are going to use, versions and other goodies

• The server sends the client its digital certificate.

• Client validates the digital certificate.  How? The client sees the certificate is signed by the CA, and it has the CA’s public key because the CA’s public key is part of the CA’s certificate that is already preloaded into the browser. Remember, all “signed” means is that the CA hashed your certificate and encrypted the hash with it’s private key. The client decrypts this hash using the public key of the CA that is in the CA’s certificate. After decrypting the hash, the client hashes the certificate itself.  If the hash the client gets matches the hash that it just decrypted, that means the CA did indeed sign the certificate.  If the CA signed the certificate that implies that the server is who it says it is, because the browser trusts the CA.

• Next, the client generates a random symmetrical key!  It encrypts this symmetrical key using the servers public key (that again it got from the servers certificate) and sends it to the server

• The server decrypts the symmetrical key sent by the client with it’s own private key.  Remember, only the server has this private key that can decrypt the symmetrical key sent by the client using the servers public key

• It is now THIS symmetrical key that is used to encrypt the actual data between the client and the server!

As you can see, while the private key of the server is insanely important and must be kept secret, it is not actually the private key that is ultimately used to encrypt the web traffic between the client and the server…it is the symmetrical key used in the above negotiation process.  Hopefully, this helps you in your understanding of SSL/TLS security!