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.
Well, I tracked down the document (it is now at http://docs.oracle.com/cd/E19957-01/816-6156-10/contents.htm#1041643) and you are right it does have more content. I have spent some time looking for statements as comprehensive as “The client uses the public key from the CA’s certificate (which it found in its list of trusted CAs in step 2) to validate the CA’s digital signature on the server certificate being presented.”
Thank you for the pointer.