What the fun is SSL/TLS. Let’s find out.

  • TLS stands for Transport Layer Security 
  • SSL stands for Secure Sockets Layer 

SSL is a transport layer protocol that ensures secure transfer of data between the client and the server by encrypting the data shared between the two.  

But Wait! TCP is also a transport layer protocol and isn’t TCP doing the same thing?
NO !
TCP is a protocol that ensures that the connection is established.
SSL is a protocol that ensures that the connection established is also secure, i.e. the data is encrypted during transit.

How it works? 

HTTP sends the requests unencrypted over the TCP connection. Anyone listening or sniffing the connection will be able to read those messages. This attack is called Man-in-the-Middle attack (MMA). So if you are sending password or credit card number etc., you will compromise your data. 

To protect the data, SSL protocol was introduced. HTTPS is a secure layer of HTTP. Just like HTTP, HTTPS first performs the TCP 3-Way handshake and establishes the TCP connection. After this, SSL establishes security connection by performing SSL handshake. Just like 3-way TCP handshake (SYN, SYN/ACK, ACK), SSL also allows few handshake messages between client and server that guarantees that any message sent after that will be encrypted. What about encryption? Let’s see.

SSL Encryption  

Symmetric Key – A symmetric key is an encryption key which can encrypt a data and only it can decrypt it. Meaning if i use a symmetric key to encrypt any data, I will have to use only this key to decrypt it. I cannot decrypt it using any other key.

Asymmetric Key – An asymmetric key is a pair of Public Key and a Private Key, such that public key can only encrypt the data and private key can only decrypt it.

Problem: 

By now, we know we need to encrypt the data. For encryption, we need a key. Let’s say the client C encrypts the data with a symmetric key and sends the data to the server. But server is not able to read the data because it is encrypted and since the key is symmetric, server cannot decrypt the data as server doesn’t have that key.

The solution is that the key used by client to encrypt, a copy of it should also be present with the server to decrypt it. 

Now if C also sends the key over the network, hacker will access the key and data both and decrypt it. So no use of sending symmetric key like that over the server.

Solution is Asymmetric Key. 

An asymmetric key has two parts- 

  • Public Key – For Encryption 
  • Private Key – For Decryption 

Half Solution: 

  1. Client C not sends a hello message to the server (not the actual data). This is first message of SSL handshake.
  2. Server will have a public key and a private key.  
  3. Server sends the public key to the Client C. This is the second message of SSL handshake. Now even if the hacker accesses this key, it won’t matter because public key cannot decrypt anything. In fact, this is the reason it is called public key. 
  4. The client gets the public key. Client then takes its own “symmetric” key say “CK” and it encrypts the key CK itself with public key sent by the server.
  5. Now client sends the encrypted CK (E-CK) to the server. At this point, hacker can listen to the E-CK but it cannot do anything because public key cannot decrypt. This is the third message of SSL handshake.
  6. The server receives the encrypted E-CK and uses its private key to decrypt it back to CK.
     
  7. Now our problem is solved, both client and server have CK (a common symmetric key). 
  8. From here on, client will send the data encrypted with CK, and server will decrypt it with CK. 
     

But here is the catch, the Man-in-the-middle can still attack the connection. Attacker can act as a proxy (mimic the client) and intercept the connection.

In step 3, when server sends the public key to client, attacker can intercept and get that public key. Now instead of sending the original public key to client, the attacker sends its own public key (it also has a private key). Now, when in step 4 client gets the attacker’s public key, it sends CK but encrypted with attacker’s public key. Naturally attacker can now decrypt the data, get the CK and forward the request to server. The problem now is that all 3 (client, server and attacker) have the CK.

Full Solution: 

Now the SSL encryption is completed but the handshake is still risky, but client does not know whether the public key it receives in step 4 is from the server only.  

This is where SSL Certificates come in. 

There is a dedicated authority called CA (Certificates Authority) that is also called issuer which creates and issues the certificates to the servers.  

  • The Server goes to an issuer and says – “Please create a signed certificate for me, so that I can prove to the client that it is my public key and not some attacker’s.” 
  • The issuer asks for server’s public key (also sent to client in step 3), say (SK). 
  • The issuer also has its own public key, say (IK).  
  • The issuer then prepares the certificate and adds its signature. The signature is as follows 
     
    SSL Signature = Server’s public key (SK) + Issuer’s Public Key (IK) 
     
  •  Now this signed certificate is given to server. 
  • Server now sends its public key (SK) to the client along with certificate. 
  • Client receives the certificate and SK.  
  • Client reaches out to the issuer and asks for issuer’s public key. (IK). 
  • Client reproduces the signature (with above formula) and matches the signature on the certificate. 
  • Now if the signature matches, the SSL encryption is validated and connection is now fully secured. 
     

Voila ! SSL handshake is now complete. Now, once TCP connection is established, and SSL encryption is completed, HTTPS sends HTTP packets (encrypted) and data transfer takes place.

SSL was created in 1990s by Netscape and many versions were release but SSL 3.0 was the last version and it has not been updated since 1996 and it also had multiple security issues. 

Thus, TLS was created to overcome such vulnerabilities and is constantly getting updated. TLS latest version is TLS 3.0. 

TLS is a successor of SSL and can be simply seen as an upgraded version of SSL. 

That’s it!

Check out best resources below –
SSL, TLS, HTTPS Explained
How SSL Certificate Works? – HTTPS Explained

If you love this content, please share it, comment down your feedback and follow for more.

Leave a Reply

Your email address will not be published. Required fields are marked *