We all know that https or http over a secure connection is the norm right now. Let’s cut to the chase and see how it works.
The client say a web browser starts by saying “Hello” to the server and sends its cipher suite – namely the algorithms it supports and the like. The server negotiates with the client and they decide on a suite of cryptographic protocols that they will use to communicate. The server also sends the client its digital certificate which contains its public key.
The client now verifies the certificate against its set of installed root CAs and once it’s satisfied it sends out a “Hello Done” to the server.
The client now uses the public key and conjures up a pre-master secret key which is one of the ingredients for the symmetric key which it will cook up later on. It encrypts this pre-master secret key with the public key and then initiates a key exchange with the server using maybe a protocol like Diffie Hellman Exchange or RSA. The client notifies the server that it is doing a cipher change and then sends out a message saying it’s finished.
The server for its part receives the encrypted pre-master key. It then decrypts it with it’s private key.
Now both the server and the client have a shared secret key.
A snapshot of the TLS handshake
Using this shared secret they create the symmetric key which they will use henceforth to encrypt all data transmission.
Data transmission using a symmetric key is far more efficient and less time consuming.
Once the symmetric key is computed possibly using an algorithm like AES after suitably adjusting it for a bit strength, the client and server transmit all data blocks encrypting and decrypting them using the symmetric key.
So that’s it folks! Happy secure httping!