SSL Handshake

How do you exchange secrets without knowing the codes to use?  Typically it is a recursive kind of problem.  With the classic mode of symmetric encryption keys, it is necessary to magically transport the key to the other side.  This would often entail using a secure non-digital technique like carrying it there.

In the web, this is impractical and would hinder the use of encryption.  Thank goodness for PKI with its ability to keep the key secret while still enabling everyone to form secure communication with the owner of that key.

Years ago I researched what was necessary to support SSL with one of our products.  It was an interesting technology to study and it was impressive how effective it was.  The modern name is supposed to be TLS but it does not seem to be sticking in the market as a name.  To me, SSL sounds better.

Today I found an old Sun page talking about SSL Handshake.  It is funny how the older pages reveal more detail than the newer ones.  Perhaps we had more time to focus on it back then.

Some items that are often forgotten about:

• It is possible to support client certificates to authenticate the user
• The encryption used for the bulk of SSL data is actually symmetric key based (negotiated during initial handshake)
• The client and server negotiate the type of encryption algorithm used
• SSL was pioneered by Netscape around 1995

Here is another description of the SSL handshake from IBM.

If you would like to learn more about SSL/TLS, please review the TLS 1.2 RFC 5246.

From the RFC:

The TLS Handshake Protocol involves the following steps:

   -  Exchange hello messages to agree on algorithms, exchange random
      values, and check for session resumption.

   -  Exchange the necessary cryptographic parameters to allow the
      client and server to agree on a premaster secret.

   -  Exchange certificates and cryptographic information to allow the
      client and server to authenticate themselves.

   -  Generate a master secret from the premaster secret and exchanged
      random values.

   -  Provide security parameters to the record layer.

   -  Allow the client and server to verify that their peer has
      calculated the same security parameters and that the handshake
      occurred without tampering by an attacker.

So much traffic on the Internet is based on HTTPS which in turn is dependent on SSL/TLS. If fact, it is largely this technology which has enabled doing business on the web.

About Jeff Muir

Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide