How SSL Works:
How SSL Works: SSL is a protocol that operates over the TCP layer. It is made such that its implementation does not bring any change on how HTTP work and for this reason, HTTP and HTTPS are not very different at a higher level layer. The purpose of using an SSL connection is to prevent attackers and evesdroppers from learning anything about the communication that is happening.
Because of SSL, the site remains very secure and potential evesdroppers cannot see anything important apart from just the IP address, type of connection in which the communication is happening, the length of the encrypted data and what type of encryption and compression are being used.
Others can also sometimes see the hostname to which the communication is sent to, from a browser, and the reason for that is because usually, a user enters the domain name of the website to initiate a communication. The browser makes a request to the DNS to get the IP address that corresponds to the domain name. After getting the domain name, the browser talks to only the IP address of the server. Clearly, a browser makes a request using the hostname in order to get the IP address of the server from the DNS and this can be seen by anyone who is eavesdropping the communication.
How does SSL Work?
Firstly, the client has to make a TCP connection with the server. After making a TCP connection the SSL handshake is initiated by the client. Usually, a client is a browser but at times it can also be an application that makes use of HTTP such as putty, windows update and more.
When the client starts TCP connection it also initiates SSL handshake by sending information to the server regarding what version of SSL or TLS it wants to use what types of encryption it can use and what all kinds of compression method it can use.
It is this server that chooses which is the highest version of SSL or TLS that is supported by both the client and the server, which is the highest encryption that is supported by the client and the server and even optionally its uses the compression.
After the basic setup is done the server sends the SSL certificate, which the client should be directly trusting or at least it should be trusted by an intermediate that is trusted by the client.
After verifying the certificate provided by the server,a data encrypted with a key is sent by the client. It can be a public key or even an empty key. The nature of the key depends on the nature of the encryption that was chosen by the server. At this point, the client sends the server an encrypted message and authentication code letting the server know that all the communication will be encrypted.
The server verifies the message and checks if the message can be decrypted and in return the same message to the client which the client will check for the match. If it is the same message without any missing data or tampering, the client can know that the server is secure. The handshake is complete and now the two computers can communicate securely using encrypted data.
To close a connection close_notify alert is used and therefore if an attacker tries to terminate the connection by sending a FIN packet, both the host and the client will know that the connection has been interrupted by a third person. And therefore discontinue any new exchange of data.
How to trust SSL/TLS certificate
When a website wants to trust a server and know that the server is not an imposter, it needs a public key and a private key. The public key is public and is known to every concerned entity and the private key is known to only the server.
Having a central server that has the records for all the websites in the world is not reasonable because the database will be very large and updates should be happening every hour.
And therefore it is more reasonable to have a rich list of certificate authorities who independently manage the domain names and the keys by themselves. This strategy helps in avoiding the need for a centralised database altogether. When we install the operating system or the web browser a list of certificate authorities also came with it. This list of certificate authorities can be modified anytime by the user and therefore we can add the certificate authority is that we trust and remove the certificate authorities we do not trust, at will.
In the list of certificate authority certificate, a list of the public keys is stored when the website’s server sends the certificate, it also mentions the certificate authority that the website used to sign the certificate. This certificate authority uses a key that is private and therefore it is not possible for anybody else to sign the certificate on the behalf of the certificate authority and creates the first line of defence against intruders.
When the certificate is signed incorrectly by a margin of even one bit the client or the browser will reject the handshake and therefore the communication with an imposter server will terminate.
Public and Private Key:
Usually, the public key encrypts the data between the server and the client and the private key decrypt the data. Usually, the browser while encrypts a message with the certificate’s private key and send it to the server and if the server can repeat the decrypted message back to the client then the client can know that it is a right server trusted by the client and the certificate authority, without actually revealing the private key.
Trusting the certificate authority:
Ultimately the client and the server has to trust the certificate authority and if the certificate authority is compromised it is very easy for an attacker to gain access to the data that is being exchanged between the servers.
Organisations such as Microsoft and Mozilla constantly ensure that the certificate authority is working properly and all the rules are followed by the certificate authority. This ensures that the clients who connect to the servers of Microsoft and Mozilla are safe and secure.
Message authentication code
All the messages that are being exchanged are signed by a message authentication code.
With the help of the key, hashing cypher and message the browser can calculate the message authentication code (MAC) for the particular message. When the computer in the other end receives the message it can also calculate the message authentication code for that message. And when the message authentication code does not match the browser knows that the communication has been compromised and it will stop communicating immediately. Since an imposter or an attacker does not know the private key, the message authentication code calculated by him will be different from the actual message authentication code and therefore message authentication code is a way to keep the communication more secure.
The advantage of a large encryption key:
Everyone knows the public key for the server and therefore anyone can use the public key of the server and encrypt a message and send it to the server. The server will receive all these messages and decrypt the message. The server will send the decrypted message back to everyone who sent to the server. And when the message matches what was originally sent to the server, the client or the browser will know that this is the server that it can trust.
This technique is very intuitive and it can be made better by using longer public and private keys. The key is just the basis for encryption and if the base message is also long, the encrypted message becomes more complex for the intruders to break in. This is why the longer the keys, in terms of the number of bits, the more secure the communication gets.
In this post, we read how SSL works. We saw the importance of using SSL and all the kinds of exchanges that happens between server and client. SSL is encrypting the data between the server and client in order to prevent the intruders from reading our data. SSL requires a public key and a private key. It also takes help from a third person, certificate authority, to ensure that everything works without fail.
If you have any doubts, please ask in the comments below. Thanks and stay tuned to TecKangaroo.