Four Words: "Then Some Magic Happens"

It has become very clear to me recently that admins that are in charge of web clients do not fully understand the HTTPS (SSL) protocol. I was involved in one such incident recently that ended very badly due to a misunderstanding of this protocol. So, here is the HTTPS (SSL) protocol explained as plainly as I can - I hope this sheds some light on what I can not easily find on google (with a short attention span):

SSL is designed mainly for two main security tenets, Confidentiality and Authentication (Before the posts start, yes I know that the "A" in "CIA" doesn't stand for authentication). When I browse to a trusted site, I want to know that I am talking only to the person that I want to talk and that my data is not being seen by anybody else.

The way that SSL achieves this is by using trusted third parties (Certificate Authorities a.k.a CAs) and Public Key Infrastructure. I won't go into details about Public Key cryptography, but just know that if you have a public key in your possession and you use it to encrypt data, the only system that can decrypt that message is a system that possesses the private key (and vice-versa). PKI is used for authentication.

Part of the whole process is setting up encryption. Encryption is negotiated within the SSL protocol's initial handshake - at the same time as calculating authentication. Once the handshake is finished, a tunnel is created using a less computationally hungry process known as symmetric key cryptography (again, I won't go into detail, just know that once this is negotiated the traffic is now encrypted).

As you can see I have created a (rather crude) diagram of SSL with steps 1-6. This may be an over-simplification, but it is definitely a good foundation. Here's a description:

1. When any modern browser is installed, it is sent with several CA issuer certificates. These issuer certificates contain a public key for the issuer, among other information.


2. When a web designer decides to use SSL he needs to purchase a certificate that is signed using the CA's private key.


3. The web browser starts a connection to an HTTPS site. Along with this request the client sends all supported encryption schemes.


4. As a response to the browser's connection request, the Server sends a copy of the certificate from step 2. Along with this transmission is the server's answer to the encryption negotiation.


5. Once a certificate is downloaded, the signature of the certificate (that was signed using the CA's private key) is checked using the CA's public key (installed in the browser in step 1 - note that there is no need to use the network for this). No error is thrown if this verification checks out.


6. The connection succeeds, the client can now download and upload to the web site with the security of encryption.