TLS handshake

Written on 12 February 2015, 09:59pm

Tagged with: , ,

The initial communication in a HTTPS connection relies on a traditional D-H key exchange – which will serve as symmetric encryption key for the rest of the HTTPS conversation.
The outline of the handshake is:
– client/server hello: list the available encryption algorithms
– certificate exchange
– certificate validation
– key exchange
– finished

Here is the process explained in layman words:

1. Client sends a Client hello message to the server with some metadata (TLS version, cipher algorithms, compression methods)
2. The server replies with a Server hello message to the client with the corresponding metadata + the Server public certificate signed by a CA.
3. The client verifies the server digital certificate and cipher a symmetric cryptography key using an asymmetric cryptography algorithm, attaching the server public key and an encrypted message for verification purposes.
4. The server decrypts the key using its private key and decrypts the verification message with it, then replies with the verification message decrypted and signed with its private key
5. The client confirm the server identity, cipher the agreed key and sends a finished message to the server, attaching the encrypted agreed key.
6. The server sends a finished message to the client, encrypted with the agreed key.
From now on the TLS session communicates information encrypted with the agreed key

The same process – explained in full details.

Note: Excepting the initial TLS handshake, the other HTTPS content (headers + payload) is encrypted with the key agreed during the TLS handshake.

Comments (3)

  1. Kontol — August 11, 2015 at 08:07

    This new one consumes too much RAM, and I think it reueirqs too much commitment from users as if it was made for advanced users, or I specifically I don’t need many of its new features. I don’t think Mozilla has any clear vision of what they really wanna do. They are heading for something but I don’t know what.


Leave a response