TLS aka Transport layer security is a successor of SSL. It is the standard cryptographic protocol in the industry right now. It is also built with the same specification as SSL builds upon. It authenticates, encrypts the data.
Bare in mind TLS does not secure the data on the system, it simply ensures the secure delivery of the data over the internet.
Underneath TLS uses a combination of symmetric and asymmetric cryptography as this provides a good balance between performance and security.
So why not SSL?
TLS is a successor of SSL and the difference between is very minor in a sense for SSL V3 and TLS 1.0 but it is noticeable for a very technical person.
- Cipher suites.
- Alert messages.
- Record protocol.
- Handshake process.
- Message Authentication.
Where does it sit?
How does it work then?
A TLS handshake initiates a TLS session but it is not a secure session even itself. The TLS handshake does not encrypt data but it does determine the encryption method and it is started with the negotiation of a TLS version.
The handshake uses asymmetric encryption to initiate a connection. Let’s visualize this below:
- The client (browser) initiates the handshake by sending a ‘hello’ message to the server. The message includes:
- TLS version.
- Cipher suites support.
- A string of random bytes known as ‘client random’.
- In reply to the client message, the server also sends a message containing
- SSL certificate.
- Prefered cipher suite.
- Server random message.
- Client verifies the certificate with the authorities that issued it.
- If everything goes well, then the client sends one more random string that is extracted from the certificate and encrypted with the server public key aka as premaster secret (shared secret).
- Server decrypt the premaster secret using its private key. If it successfully decrypts the secret that means the client and the server confirm their identity, hereafter the server and the client both generate a master key using the previously generated random numbers and the premaster key.
- The client sends its master key and changes its encryption key to this master key onwards. (basically it changes asymmetrically to symmetric).
- After that the server matches with its own generated master key with the client’s master key. If it matches the key that means both the parties are authenticated and the server also agrees to use the master key onwards. (asymmetric to symmetric encryption).
- At last the final message was sent from the server encrypted using the shared secret key which is a session key.
- Both the parties are synced and agree to start the data transfer.
This is the way TLS 1.2 works and it delivers the best encryption till the arrival of TLS 1.3.
TLS 1.3 (A worthy upgrade?)
4 major upgrades happened in TLS 1.3 over TLS 1.2
- Reduction of round trip processing, resulting in a faster handshake.
- Use of perfect forward secrecy.
- Removal of vulnerable algorithms and ciphers.
- Zero round trip time (0-RTT)
Handshake creates a secure tunnel for communication over the internet for the client and the server. But it has some cost for computation. In TLS 1.2, the handshake involves multiple communication or round trips before finalizing a secure communication. Here TLS 1.3 comes into play and reduces the number of roundtrips during the handshake. The shorted handshake results in better and faster performance without compromising the security aspect of it.
Perfect forward secrecy is a feature that prevents any middle man from being able to decrypt the data from a historical or future session if the server's primary key is compromised. It uses unique session keys that are generated frequently and automatically for preventing the session key(shared key) from leaking.
Algorithms and Ciphers:
TLS 1.3 has shrunk the size of cipher suits that is used for encryption. TLS 1.3 only includes the support for algorithms that currently have no known vulnerabilities as well as only those that have the perfect forward secrecy.
Zero Round Trip Time:
As with SSL, TLS relies on key exchanges to establish a secure session. In earlier versions, keys could be exchanged during the handshake using one of two mechanisms: a static RSA key, or a Diffie-Hellman key. In TLS 1.3, RSA has been removed, along with all static (non-PFS) key exchanges, while retaining ephemeral Diffie-Hellman keys.
In simple terms, if a previously visited client (visited a site recently) accesses the server, then the client can skip all of the round trips for a secure communication channel and get the document from the server. Of course, the server has to check for the shared key to resume that session.
Eliminating an entire round-trip on the handshake saves time and improves overall site performance