SSL (or alternatively TLS) is a complex thing. There are many key concepts hidden behind SSL that most of us ignore and we are only concerned about our website security without even looking at how things work at the backend. In this article, I’ll walk through some of the fundamentals of SSL including:
- Types of Encryption (Symmetric, Asymmetric, and Hybrid)
- Public Key Infrastructure (PKI)
- Public Key Exchange (PKE)
Types of Encryption:
Symmetric Encryption: In symmetric encryption, the client and the server both share a common key (called as secret key) that is used for encrypting and decrypting messages sent over a communication channel. Messages encrypted with the secret key can only be decrypted using the same secret key. This is just like conventional door locks in our homes, in which the same key is used to both close and open the lock. Cryptographic algorithms that use symmetric algorithms are DES, 3DES, Blowfish, etc.
The problem with Symmetric encryption is that entities who are communicating using symmetric encryption must share the secret key over an insecure communication medium i.e the internet. Here, I am considering any medium that is not controlled by us as insecure. Thus, an intruder can always jump in the middle, steal our private key and intercept between our conversation. This is a major drawback of symmetric encryption (although it is faster than asymmetric encryption).
Asymmetric Encryption: In asymmetric encryption, we have a pair of keys (public and private keys) at the sender’s as well as the receiver’s end. The public key is globally distributed whereas the private key is only tied to the user itself and is never shared with anyone. Major algorithms that use asymmetric algorithms are RSA, Diffie-Hellman and Elliptical Curve (ECC), etc.
Let’s take an example of two users, Alice and Bob to understand asymmetric encryption.
Suppose if Alice wants to send a message to Bob, she’ll encrypt her message with Bob’s public key and send it to the communication channel. Even if an intruder manages to get the encrypted message during transmission, he can only see garbage since the message cannot be decrypted by any other key other than Bob’s private key. The same is true for Bob as well.
Asymmetric encryption was a major success over symmetric encryption but had its own drawbacks. It was considered extremely slow and tends to consume a lot of processing power and, thus was considered inefficient when processing large chunks of data.
Hybrid Encryption: Hybrid encryption is a combination of both symmetric and asymmetric encryption. In hybrid encryption, the shared secret key is shared among the two parties (symmetric encryption) in a way that Alice encrypts the shared key with the help of Bob’s public key (asymmetric encryption). This secret key can only be decrypted with Bob’s private key and hence, a man in the middle attack is not possible even if the key is transmitted over an insecure medium. Hybrid encryption is a kind of encryption we use in public key exchange (or alternatively in an SSL/TLS handshake).
Public Key Infrastructure (PKI):
A public key infrastructure is a framework based on asymmetric technologies that allow the validation, revocation, and verification of digital certificates and also authorizes the keys linked with those certificates. It allows the internet users to transmit their data over a secure medium by verifying the authenticity of certificate holding entities such as Web servers (Nginx, Apache, IIS etc). In short, a PKI states how to generate trusted certificates from a Certificate Authority (CA) and makes sure that other devices trust those certificates.
SSL/TLS Five Way Handshake:
Let’s look at the conceptual handshake of TLS/SSL Protocol. Assume that Alice is the browser, and Bob is the SSL server. The handshake proceeds as follows:
- The SSL/TLS handshake between an SSL Client (Alice in this case) and an SSL Server (Bob) is initialized with a “Client Hello” message. This message includes multiple parameters such as SSL/TLS versions, the cryptographic algorithms (cipher suites) that “Alice” supports along with a random string known as “Client random” that will be used to generate a pre-master secret key in later steps to encrypt the overall communication.
- The server (Bob) responds to Alice with the “Server Hello” message after selecting the supported SSL/TLS version and cipher suites from the list provided by Alice (usually it’s the latest version supported). Bob also sends a random string called “Server random” along with it’s certificate to Alice for verification and authorization.
- At this point, Alice makes sure that Bob is exactly the one who it claims to be, by verifying it’s certificate from its list of supported Certificate Authorities. This verification is done by checking the digital signatures and intermediate certificates by the client. Once verification is completed, we are good to go ahead.
- Now Alice will generate another random string called a Pre-Master Secret key that is encrypted by Bob’s public key and sent to him in the same step, which is going to be decrypted at the server end with Bob’s private key. This pre-master key, server random and client random combined will be used to formulate a final secret key (Master key) that will, from now on, be used to encrypt further communication.
- The handshake is completed with the “Client finished” message that will be sent to Bob by encrypting it with the newly created secret key, indicating that Alice is now ready for secure communication
- The server in response will end the handshake with the “Server finished” message encrypted with the secret key, indicating that Bob is also ready for secure communication.
Sources:
https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10660_.htm
