Quick and Dirty SSL Myth Busting

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!


  • Thank you for writing this article.
    I’ve read the reason we don’t just use public-key encryption (using something like RSA) for the entire session is public-key encryption is much slower than symmetric-key encryption (e.g., AES.) That’s why it uses the RSA conversation to exchange AES keys and then uses the AES flow for the actual user data.

    The ASA5500 can use SSL to startup the AnyConnect Secure Mobility Client. Wonder if that needs a patch.

  • Jimmy Hale says:

    Hey Joe,

    I really find your website extremely valuable, and I appreciate the work you’ve put into it. Your contribution to knowledge and learning to the network community is awesome. I’ve just started my venture toward CCIE R/S certification and I think I’ll be well acquainted with your site. ;)

    Hey, question on your article regarding SSL and the heart bleed vulnerability. The acronyms that are indicated — CA, CN, and OU. I’m assuming the CA means Certificate Authority? What about CN and OU? I’m one of those “Voice” nerds that sometimes gets lost in the network and security realms of technology. Thanks in advance for your response.

    Jimmy Lee Hale
    Telecommunications – Unified Communications – IP Telephony Professional
    ph: +1 (650) 714-3568
    email: jimmyleehale@gmail.com

    • Joe Astorino says:

      CN = Common Name
      OU = Organizational Unit

      These are typically fields you find in a digital certificate to help identify the device

    • Gennady says:

      Hi, i am an application developer, i have some questions, not sure if you know?

      I have some functions i want to use in my code:

      these functions:


      setIP(string ip_address, string subnet_mask) – what is subnet mask, what should it be?


      setGateway(string gateway) – what should it be ? Do i have to change it as well I change my ip adress?


      setDNS(string NIC, string DNS) – what should it be ? Do i have to change it?


      setWINS(string NIC,string priWINS,string secWINS) and WINS what should it be?

      Could you please give and example of all those values, and what should they be?

      Basically what I want is to set and hide my PC in the some timing interval so to appear

      as a new person on some website. Which functions do i need to use,

      only setIP(…) or other ones as well? Give some examples of those parameters.

      Thanks in advance.

  • Kamil says:

    Good article.

    Easier to memorize if we take a first part of negotiation as an authentication process and a second part as an encryption where separate symmetrical key is generated for traffic encryption.

Leave a Reply