How HTTPS works
HTTPS and TLS certificates in a nut shell
HTTPS is very important these days most websites require it!
Without HTTPS, the communication between the browser and the server is in plain text.
This means that the password you enter or that credit card number you send over the Internet can be read by anyone who can intercept it.
HTTPS is designed to solve this problem, to make the data sent over the Internet unreadable by anyone other than the sender and the receiver.
With HTTPS, data is sent in an encrypted form using TLS protocol. TLS stands for Transport Layer Security. If the encrypted data gets intercepted by a hacker, it will be unreadable and meaningless for him.
There are several steps in the process of encryption.
1. TLS handshake The browser establishes a TCP connection with the server.
a. SYN
b. SYN ACK
c. ACK
2. Establish certificate for communication
a. Client Hello:
The browser sends a client hello to the server. In this hello message, the browser tells the server the following things one, what TLS version it can support?
I. It could be TLS 1.2, TLS 1.3, etc.
II. which cipher suite it supports.
A cipher suite is a set of encryption algorithms to use to encrypt data.
b. Server Hello:
After receiving the client hello, the server gets to choose the cipher suite and the TLS version to use based on the options as received from the client. It sends those in the server hello message back to the client.
c. Share certificate:
The server then sends a certificate to the client.
One of the key data in the certificate is public key for the server. The client uses the public key for asymmetric encryption. So that the data that is encrypted by a public key can only be decrypted by its private key.
This concludes step two, the hello phase of the TLS handshake. At this point, the client has a server certificate and the client and server have agreed upon a TLS version and the cipher suite to be used.
3. Exchange Keys
This is the step where the client and the server come up with a shared encryption key to be used for encrypting the data.
This is where the symmetric encryption comes into the picture. Again, with a symmetric encryption, the data encrypted on the client side using the public key from the server can only be decrypted by the server. This is how the client sends an encryption key safely to the server over the Internet. All this is done in the client key exchange message. The exact detail varies depending on the cipher we used.
Here. If we use RSA as an example, since it is the easiest to understand,
the client generates an encryption key, also called a session key,
Encrypts session key with the server’s public key and sends the encrypted session key to the server over the Internet.
The server receives the encrypted session key and decrypts it with its private key.
Now, both sides hold the session key, and this is where they enter step four of the TLS handshake, where they use the session key and the agreed upon cipher suite for further communications between the client and the server.
Now you may ask, why don’t we just use asymmetric encryption for everything?
The main reason is that asymmetric encryption is computationally expensive, it is not suitable for bulk data transmission.
However, asymmetric encryption is not the only way to share the session key between the client and the server. In fact, in TLS 1.3 , RSA is no longer supported as a method for key exchange. Diffie Hellman is a more common way nowadays for exchanging session keys. Diffie Hellman is complicated, it uses some advanced math involving large prime numbers to derive a shared session key without ever transmitting a public key over the network.
