Introduction to TLS

Typical application of TLS is communication between client–side web–browser and server–side website. As the client has to be sure that it is communicating with the correct server and there is no eavesdropping or data manipulation, the communication has to be encrypted. Encryption of communication ensures confidentiality, integrity, authenticity and non – repudiation.

As the client and server can't share a symmetric key in open channel, asymmetric key has to be used to exchange the symmetric key. But as anybody can connect to the server, client doesn't require its set of public key–private key. Only server–side set of public–private key is required.

The client generates a symmetric key, encrypts it with the public key of the server and sends it to the server. The server decrypts the cipher-text using its private key to get the symmetric key. The symmetric key is used for further communication.

TLS refers to this exchange of generated key between server and client. It allows the client to request certificate from the server, telling the client it has connected to the corrct server; negotiating cipher to be used; generating the key; sending the key to the server; and, exchanging the data using this symmetric key.

TLS protocol is evolved by the TLS Working Group of IETF. Currently version 1.3 of TLS is being discussed within the group.

TLS 1.3 is supposed to strengthen the security of communications by using the latest of cryptographic algorithms, and removing support for weaker algorithms like MD5, SHA-224 etc…

Existing Work

Lot of work is being done on developing newer and improved version of TLS. TLS–related Id on IETF talk about ECC and key management. To begin with, we concentrated on two internet–drafts:

1.0 TLS Cached Information Extension: This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information. i.e, The client hashes the certificate chain and sends it to the server with the ClientHello. If this hash matches hash of the certificates as calculated by server, server need not send the certificate-chain. Obviously, this method is used when the connection between client and server has taken place before and is being resumed. The client has stored the server certificate during previous communication.

2.0 TLS False Start: This document refers to a strategy that is used by the client to shorten round-trip-time (RTT) during handshake by sending the application data before the handshake is completed. The data cannot be read by an intruder because it is encrypted with the symmetric key. The symmetric key is encrypted with public key of the server and can be read by the server and server alone. RTT is reduced from two full round-trips to one and half round- trip.

Our Work

We went through both the drafts and raised several questions including the very usefulness of the approach, possibility of the Man-in-the-Middle attack, possibility of reducing the RTT further, etc. On going through the mailing list archive of the two drafts, we found that these issues have already been discussed.

One idea is to use checksum instead of SHA-1 or SHA-256 because it is faster and hashing is being used only for identification purpose and not for cryptographic reason. As SHA-1 or SHA-256 or checksum can be applied on the certificate-chain offline and hash stored for repeated use in future; using checksum results in a very small saving of time and not very beneficial. However we communicated the above to the forum.