- 1.0 – never released
- 2.0 – had security flaws (released in 1995)
- 3.0 – obsolete (released in 1996)
- 1.0 – slight upgrade of SSL v3.0 (released in 1999)
- 1.1 (2006)
- 1.2 – still currently used (2008)
- 1.3 – currently in use (March 2018)
Browser wants to establish connection to a server.
Step 1) Client starts TLS 1.2 handshake
This TLS handshake process can only start after the TCP handshake is made with the server.
First move makes the client. Client sends ‘Hello’ message to the server. Inside that message, there are following things:
- It contains all supported SSL/TLS protocol versions client supports.
- It contains all cipher suite (encryption methods) client supports (AES, RSA, EDC, 3DCA)
Step 2) Server responds back to the client
Now, the server has SSL/TLS versions and encryption methods client can support. It is now server’s turn to send his data to the client. Before analyzing any further, let’s see what each of these terms mean:
What is certificate file? – Certificate file associates domain name of the server with the public key the server needs to send to the client. The certificate file contains Certificate Authority (CA) who approved this certificate. In order for server to use SSL/TLS encryption, he needs to have certificate file.
How the certificate file is made? – Certificate file is made when a server ‘asks’ Certificate Authority (CA) to sign server’s public key, which proves to his clients that his public key is signed and trusted. However, the server must prove to the Certificate Authority (CA) he is the right one, and not someone bad (attacker). Knowing that, server creates private/public key and sends public key to CA. The CA makes sure public key is right and signs the certificate file so that the server can share it with its clients. By doing so, when clients receive certificate file, they know it has been signed by X certificate authority. Thus, they can trust this server. Long story short, certificate file verifies the server is legit.
What is digital signature? – They are electronic forms of real life signatures. Digital signature locks files or messages with a secure key that proves the identity of the file or message owner. They are issued by a Certificate Authority (CA).
So, let’s go back to our TLS handshake. Now it is server’s turn to send data to a client. This is what he sends:
- Server agrees on which encryption method will be used to share public keys
- Server sends ‘Certificate file’. It contains following:
- There is server’s public key signed by CA (i.e RSA 2048). This public key is used by client to encrypt future messages to the server before they accept symmetric keys encryption.
- There is serial number that is unique for tat certificate file (issued by CA)
- There is digital signature provided by CA. It is usually signed with SHA256 hashing algorithm
- There is issuer or the name of CA who signed server’s public key.
- There is valid data until the certificate expires
- Server sends ‘Hello done’ message
So far, everything has been transferred in plaintext!
Step 3) Client receives server’s message and sends new stuff back to server
First thing client does is checks the certificate file he just received. What client wants to know is if the certificate has been revoked, if it is still valid and stuff like that. Next, based on the public key he got, client generates ‘Pre-Master Secret Key (PMSK) and encrypts it with server’s public key. Also, keeps unencrypted PMSK for himself. Now, client has newly generated PMSK that nobody knows and it is ready to sent it back to server (encrypted with server’s public key). Again, nobody would be able to decrypt that PMSK since it is encrypted with server’s public key. Only the server can decrypt with his private key. This symmetric key (PMSK) will be used to encrypt/decrypt all traffic in the future between client and server.
Furthemore, client sends ‘Change cipher spec’ message telling server to use that PMSK in the future as symmetric encryption method. At this point, both parties have made their way to securely have unique symmetric key that is used for encrypting/decrypting all traffic between them.
Lastly, client sends ‘Client finished’ message to the server.
Step 4 ) Server’s last message before data transfer begins
Server gets client’s PMSK and decrypts it with his private key. He now has symmetric key, too.
Server sends ‘Change Cipher Spec’ message, agreeing to the client he is ready with symmetric encryption.
Lastly, server sends ‘Finished’ message and encrypted communication can begin.