Two very different encryption methods, each with a place in the SSL ecosystem
Let’s talk about encryption. Specifically let’s talk about two different kinds of encryption: symmetric and asymmetric.
Both types play a major role in regard to SSL, but to fully understand them we first need to zoom all the way out and have a discussion about the concept of encryption in general.
Encryption is the practice of scrambling information in such a way that only an authorized party can descramble it. In the context of SSL, we’re talking about securing connections between internet users (clients) and the websites they visit (servers), which means scrambling any data sent between the two.
Over a standard HTTP connection, communication is unsecure, meaning that any interested third party can intercept or even manipulate the data being transmitted. When an SSL certificate is installed, the website can migrate to HTTPS, the secure version of HTTP. When a connection is made via HTTPS, it is encrypted.
However, when we refer to encryption, we are referring to two very different styles of encryption.
Asymmetric Encryption During the SSL Handshake
When you visit a website with an SSL Certificate installed the first thing that your browser is going to do is perform an action called the SSL Handshake with the server the certificate is installed on.
This SSL Handshake is a process wherein the browser checks the validity of the SSL Certificate and negotiates the terms of an encrypted connection. Frankly, the SSL Handshake is an impressive feat of technology given that it requires a number of steps and checks, which all take place in a span of milliseconds.
After the browser checks to make sure the certificate was issued by a trusted CA, is still in its validity period and has not been revoked, it makes sure that the certificate in question is the rightful owner of its corresponding public key.
You may have heard about public/private keys. Of the pairing, the private key usually gets a little more recognition, you’ve likely seen them advertised as 2048-bit signature keys. This is in reference to the amount of security – in this case, 2048-bits – that are associated with the key.
Public/Private keys are an example of asymmetric encryption. The public key is capable of encrypting while the private key is capable of decrypting. With asymmetric encryption, the communication can only go one way.
For the sake of the SSL handshake, the browser uses asymmetric encryption to verify the public/private key pair, and by extension the certificate itself (as we mentioned, this is one of many checks). In order to do this, the browser will use the readily available public key to encrypt a small bit of throwaway data. If the server is capable of decrypting this data and sending it back in plaintext, then it has proven that its private key corresponds with the public key.
Now the browser and the server can begin their encrypted connection.
Symmetric Encryption in the Form of Session Keys
After using asymmetric encryption during the SSL Handshake as a sort of verification method, the browser and the server negotiate the terms of an encrypted connection and exchange what are called Session Keys.
Session keys facilitate a form of symmetric encryption that is used to communicate during a secure session. Whereas a private key is usually 2048-bit (or occasionally 4096 or 1024), session keys tend to be smaller, which also means less secure. This isn’t something that should alarm you though. Even at 128/256-bit, session keys would still require a dedicated supercomputer working for years on end before their encryption could be cracked. Or, put another way, session keys are still plenty secure.
The reason for the size difference is simply speed and performance. A 2048-bit key can be more cumbersome to work with in some situations. 128/256-bit strength is still sufficient but allows for much better performance which is an important factor during an encrypted connection.
With symmetric encryption, the keys can perform both functions: they can both encrypt and decrypt. This allows clients and servers that are both in possession of a corresponding session key to communicate securely. After all, without the correct key no one – no third party, no matter how sophisticated – can spy on the connection.
The session keys remain active for the entire duration of the encrypted connection. At the point the connection ends the keys are discarded and new keys are generated upon the next visit. It’s simple, but quite effective.
As you can see, symmetric and asymmetric encryption function in different ways, while one form allows both parties to encrypt and decrypt, the other facilitates a more one-sided form of communication.
Both are integral parts of SSL though. Asymmetric encryption helps to verify ownership of the public/private key pair during the SSL handshake while symmetric encryption is the method used for actually communicating during a secure connection.