How SSL handshake works?

Let’s start with what is SSL. SSL stands for “Secure Sockets Layer”. It is a protocol that operates directly on top of Transmission Control Protocol(although there are also implementations for datagram based protocols such as UDP) and ensures that the information exchange between two parties is done with authenticity, integrity and confidentiality.

SSL protocol requires SSL certificates to be present on the server side so that any client connecting to the server can verify the SSL certificate from the server to verify it authenticity. There are certification authorities or certificate authorities (CA) which can provide such certificates for servers and help clients verify the certificates. These certificates not only help with encryption but also authenticate the identity of the owner of a website, adding another layer of security. The SSL certificate is then used as proof of the company’s identity. These certificates can be divided into three authentication groups, based on the level of authentication, which are:

1. DOMAIN VALIDATION CERTIFICATES: Can just verify if the control over domain name.
2. ORGANISATION VALIDATION CERTIFICATES: Can verify both domain name and the authenticity of the company as a legal entity.
3. EXTENDED VALIDATION CERTIFICATES: Has both the above and various other verifications proving that the SSL certificate belongs to a registered company

Now that we know what SSL certificates are lets go to the SSL handshake. As mentioned earlier SSL protocol works on top of TCP, hence the SSL handshake begins after TCP connection is established between two parties (say client and server). The SSL handshake enables the client and server to establish the secret keys with which they communicate for the rest of the message. On a high level the following are done during this handshake:

1. Agree on the version of the protocol to use.
2. Select cryptographic algorithms.
3. Authenticate each other by exchanging and validating SSL certificates. Although client validation is generally optional.
4. Use asymmetric encryption techniques to generate a shared secret key, which avoids the key distribution problem. SSL or TLS then uses the shared key for the symmetric encryption of messages, which is faster than asymmetric encryption.

The basic principle is that using SSL certificates and asymmetric encryption, a secret key can be established which is only known to the server or client even when all the messages sent/received during this handshake can be seen by anyone in the channnel. Once the secret key is established this can be used to communicate securely.

As SSL operates directly on top of the TCP, it allows higher protocol layers to remain unchanged while still providing a secure connection. So underneath the SSL layer, the other protocol layers are able to function as normal.

If an SSL certificate is being used correctly, all an attacker will be able to see is which IP and port is connected and roughly how much data is being sent. They may be able to terminate the connection but both the server and user will be able to tell this has been done by a third party. However, they will not be able to intercept any information, which makes it essentially an ineffective step.

In typical use, the attacker will also be able to figure out which hostname you’re connecting to (but not the rest of the URL) as although HTTPS itself does not expose the hostname, your browser will usually need to make a DNS request first to find out what IP address to send the request to.