As of 2018, almost 60% of the whole internet is using SSL to encrypt data transfers. Personally, I've had to deal with SSL certificates on so many occasions. Do we know how it really works? I thought I did, until I decided to write about it.
In this short blog post, I'm hoping to share some technical aspects of SSL that I found interesting.
So, what is SSL/TLS?
SSL stands for Secure Sockets Layer, and it is a digital certificate that authenticates a website's identity and creates an encrypted connection between the website server and the web browser. TLS (Transport Layer Security) is a newer iteration of SSL which is still in use today, however the initials of SSL stuck to the general vocabulary, so TLS is often referred to as SSL for simplicity.
Why SSL?
By definition, SSL will give you a secure environment to exchange information, so it is super important to use it whenever you need to safely login, process payments or even run an API call. That happens on pretty much every website, right?
How does SSL work?
Before we dive into SSL encryption from a technical point of view, the way it works from a high level is as follows:
- A browser (you) attempts to connect to a website.
- The browser requests that the website identifies itself.
- The website sends the browser a copy of its SSL certificate in response.
- The browser checks to see whether it trusts the SSL certificate.
- The website then returns a digitally signed acknowledgment to start an SSL encrypted session.
- Encrypted data is shared between the browser and the website.
As you can see, from a high level overview this is a pretty straight forward process. But something very interesting happens in order to establish a secure connection, that is also fast and scalable.
Symmetric and Asymmetric Encryption
Symmetric Encryption is a method that uses a shared key for encryption and decryption. In other words, you encrypt a document with a password, and in order for others to see the document, they will need the password.
This is the oldest known method of encryption, and while it is very fast and scalable, it is not the most secure. What happens if the shared key is accessed by unwanted parties? In this case, anybody holding the shared key will be able to decrypt the document.
This is not good, so what can be done?
This is where Asymmetric encryption comes in. By using a shared key for encryption (public key) and a private key to decrypt, we won't have to worry about the shared key being compromised.
This seems a bit more complicated. So, how does it work?
The security in asymmetric encrypted environments come from two different keys:
- Public key encryption: Anyone can see this, and it is initially sent by the website holding the private key.
- Private key encryption: Only the authenticated website has access.
Anyone can access the public key and encrypt data with it. However, once encrypted, that data can only be decrypted by using the right private key. Of course, the private key must be kept safe and secure in order to prevent it from being compromised. So, only the authorized person or server has access to the private key.
These two keys are completely separate but totally equal in power. You will always need both keys to decrypt a message.
The result is much stronger security, however there are some downsides when it comes to performance.
Pure asymmetric encryption would often be like 3 to 5 decimal orders of magnitude slower than symmetric encryption is. - Source
This is a big problem for web. Network requests need to happen fast. There are so many API calls a website makes, so many requests to authenticate or purchase. We simply cannot have a backlog of network calls that otherwise will cause applications to fail.
The solution for SSL?
Let's use both Symmetric and Asymmetric Encryption!
SSL certificates use asymmetric encryption to establish a secure connection. After the connection has been established securely, a symmetrically encrypted key is shared between the browser and server.
Based on the image above, the breakdown of this combination of asymmetric and symmetric encryptions is as follows:
Server sends a copy of its asymmetric public key.
Browser will create a symmetric session key and encrypts it with the server's asymmetric public key. Then sends it to the server.
Server decrypts the encrypted session key using the asymmetric private key to get the symmetric session key.
Server and Browser now encrypt and decrypt all data flow with the symmetric session key. This allows for a secure connection because only the browser and the server know the symmetric session key, and the session key is only used for that session.
A new session (requiring a new copy of asymmetric public key) will be needed if a day later the browser makes a request to the server.
This combination of encryption techniques is what ensures performance while keeping connections secure.
Closing Notes
While this is a process that kinda happens out of the box, and developers don't really need to think about all this, I believe it's extremely important to have a decent understanding of the overall process. You can definitely borrow the hybrid encryption model from SSL, and implement it for other purposes.
See you on the next one ✌🏼