SSL (Secure Socket Layer)

Before getting into SSL, we should see how things works without SSL and what's the need for any such protocol ?

So let's say you want to send some data from client to server, how it will be send in a normal TCP connection ? It will be send as paint text. In that case, what if someone interprets and sneaks into data being transferred. This will lead to Man in the Middle attack and your precious data will be compromised.

Now, how can we prevent this Man in the middle attack ? Technically we cannot stop somehow from accessing what we are sending because it is send over the internet but there is one thing we can do, what if out data is still accessible to the hacker but it's not useful for him/her. How can we achieve something like this ? We can encrypt out data in such a way that only server will be able to decrypt it. I think this approach should work.

Let's see, how can we encrypt our data ?

Symmetric Encryption : In this encryption, which we have one single key that will be used to encrypt as well as to decrypt. Let's check if this solves our use case or not ? So our client now has a key using which it will encrypt the data before sending it to server but first it needs to send it's key to server so that sever will be able to decrypt the data but what if while sending the key to server, it is stolen by the man in the middle. Then encrypting data would be waste because MM would be able to decrypt your every single message because it has the client key.

So this is clear that it is not working for our use case.

Asymmetric Encryption: In this mode, there will be 2 keys - Public Key and Private Key, Public key will be used to encrypt the data and Private key will be used to decrypt the data. Let's try to use this mode in our use case.

So, our server has 2 keys one public and other private and our client has one symmetric key.

Now, our server will send it's Public key to the client. Server will send it's Public key because we do not care even if it is stolen because it can be used only to encrypt data and not to decrypt data. After this, client will use the server's Public key to encrypt its Symmetric Key and will send it to server over the internet. Now if hacker accesses it, it will not be able to decrypt it because it can only be decrypted with Server's Private Key which hacker does not have access to.

Now our server and client both have the Client's Symmetric Key, using which client will encrypt the data before sending it to server and using same server will be able to decrypt the data.

Looks good !!! Are we safe to send data now ? That's it ??

Actually not yet, there is still a loophole in this approach which can be misused by the attacker. Let's understand that !!!!

At first when server send it's Public key, as we know it can be stolen by attacker and we were not at all worried about this because anyways it is server's Public key and not the Private key and it can be only used to encrypt the data and not decrypt the data. But what if attacker takes the Server's Public Key with itself and sends it's own (Attacker's Public Key) to client. Now client will think if it has come from server and it will encrypt it's Public Key using Attacker's Public Key thinking that it's the Server's Public Key and send it to server but before reaching to the server, Attacker again sneaks the message and gets the encrypted Client's Symmetric Key but the fun part is - it is encrypted using Attacker's Public Key, therefore attacker will easily decrypt it using it's Private Key. Now attacker will encrypt the Client's Symmetric key using Server's Public Key so that message looks authentic and server should also be able to decrypt the Client's Public Key and they can continue sending data to each other. Here, connection between client and server is completely compromised and both are unaware or this. They will keep on sending critical data to each other thinking that the data is encrypted and no one can interpret it but in reality their every single message is being decrypted by attacker.

Before we see the solution to this problem, first understand the root issue. So basically our protocol was working perfect but problem comes when attackers sends client its Public key as if it is sent by server. What if somehow client can verify if the Public key it has received is actually belongs to the server it is trying to communicate ?

That's what our solution is !! So now, server along will it's public key, will also send its SSL Certificate. Now what is this SSL Certificate ?

SSL Certificate is a certificate issued by some authority using which any client can verify if the Public key it has received is actually belongs to correct server it wants to communicate or belongs to some attacker. But how does that works ?

Basically , Certificate Issuing authority is also a server in itself which also has it's own Public and Private Key. When certificate was actually issued to the domain, a signature was created using Server's Public Key and Authority's Public Key.

Now, when server will send it's Public key to client, it will also send it's SSL Certificate. After this, client needs to verify if this public key it has received actually belongs to correct server or not. To do this, it will do to the Certificate Issuing authority and asks them "hey authority, i want to verify the authenticity of a certificate issued by your, please give me your Public Key (Authority's Public Key)". Now client will generate the signature using Server's Public Key and Authority's Public Key, if it matches the signature present on certificate, Server's Public Key is correct otherwise it belongs to some attacker and further communication will be blocked.

Now our connection is no longer a HTTP connection, it is now HTTPS (Secure HTTP)

That's how SSL Certificate makes our web safe !!!