What is SSL?

This is a fairly technical explanation, so if you don’t have any interest in
the ins-and-outs of SSL, you can skip this section with the take away that SSL is an extremely
secure and a neat way for browsers and servers to setup secure channels.

With that said, I’ll commence with the explanation.

When a browser makes an HTTPS request, the browser first does an DNS lookup
on the hostname to get the IP address. The browser makes a connection to the
server at this IP address on port 443 (by default) to start setting up the
secure connection. The server replies with its public SSL certificate, which
the browser will then verify, checking its signature against the
pre-installed certificate authority keys. This certificate authority’s
signature gives you faith that the entity you are talking to is whom you
expect it to be. The SSL certificate from the server contains information
such as what hostname the certificate was built for and how long the
certificate is good for. It may also contain other information about the
business, such as contact information, but this is not required. This step
is where the browser will show SSL errors to the user, such as the hostname
mismatch or certificate expiration. The most common error that people see is
the hostname mismatch. If you typed in “https://www.example.com” and the SSL
certificate was built for just “example.com”, you’ll see the mismatch
notice.

The data is transmitted encrypted using symmetric key cryptography.
Symmetric key cryptography involves the sender and receiver (in this case,
the browser and the server) both having the same key which is then used to both
encrypt and decrypt a message. The advantage of this type of protocol is
that encryption and decryption are very fast while still being incredibly
secure. The downside of this is the issue of how to get the key from the
client to the browser without anyone in the middle stealing it. This is
where another kind of cryptography, public key cryptography comes in.

Public-key cryptography consists of the message receiver having two keys,
one being public and the other being private. To send an encrypted message,
the sender uses the receiver’s public key to encrypt the message. To decrypt
this message, the receiver uses the private key against the message. The
public key is available for anyone to use, but the private key should be
never be shared with anyone, because if this key gets out, then any messages
encrypted with the public key can be decrypted by anyone possessing the
private key. A good analogy for this type of cryptography is to think of it
like a mailbox. Anyone is allowed to drop a letter in, but only the owner of
the mailbox has the key to unlock it and get the letters out.

So after the browser makes its request to begin the secure transaction, the
server will reply with its SSL certificate, which contains its public key.
After the browser checks out the authenticity of the certificate, it will
generate a brand-new, temporary symmetric key. The browser will encrypt this
new key with the SSL certificate’s public key, and send it back. Since only
the server is able to decrypt this message and get the symmetric key out,
the symmetric key has been safely transported from the browser to the
server, with no one being able to snoop on it while in transit. From then
on, the browser and client will do all of its encryption and decryption with
this symmetric key, due to its speed advantage mentioned earlier. Thus, a
relatively fast and secure channel has been created between the server and
browser.

To sum up, here’s a quick rundown of the full SSL transaction:

1. The client requests an HTTPS URL.
2. The server replies with its public certificate.
3. The browser will verify the authenticity of this certificate. If it’s
   not valid in some way, the browser will show the user the problem(s)
   with the SSL certificate and let them decide what to do.
4. If everything checks out from step 3, the client generates a brand-new
   symmetric key, encrypts it with the server’s public key from the
   certificate, and sends it back.
5. The server decrypts this encrypted key with its private key and sends
   back a message saying that the connection has been made. This message is
   also encrypted with the symmetric key.
6. If the browser can decrypt this message, then a secure channel has been
   created and communication can continue with everything being encrypted
   with the new symmetric key.
7. At the end of the session, the symmetric key is destroyed.

This protocol completes the two goals of SSL: secure communication and
guaranteed authentication.

The cool thing about the SSL protocol is that the secure channel is created
before anything is transferred, even the URL itself. That means if
you request “https://www.example.com/some_secret_resource” the browser does
a DNS lookup of “www.example.com”, goes through the above steps, and after
the secure channel has been created, then the full URL is sent to the
server. The DNS lookup, if it doesn’t come out of the client’s DNS cache,
will be the only way to verify what server the user is trying to contact.
Someone on the outside can tell the client is trying to contact a certain IP
address and see the encrypted traffic, but that’s basically the sum total of
an observer’s view of the transaction.

—

In summary, if you don’t want an outsider to see what you are transmitting
between the browser and the server, an SSL certificate is a simple way to
get a high-level of privacy and security.