Transport Layer Security (TLS) is the standard protocol used over the Internet to encrypt communications between computers; many other Internet protocols, be them for the web, for email or for other services, use TLS as a foundation to secure their transmissions.
TLS evolved from its predecessor, Secure Sockets Layer (SSL); the names TLS and SSL are often used interchangeably, though the latter is deprecated. In about twenty years, only five versions of SSL/TLS were deployed: SSL 2, SSL 3, TLS 1.0, TLS 1.1 and TLS 1.2 (TLS 1.3, as of early 2017, is in the making). As time goes by, computation power increases, conceptual flaws are discovered and implementation errors are found, so old versions of security protocols become insecure and should be removed from use as soon as possible.
However, older versions of server and client software will not be able to speak newer versions of the protocol, and this is why moving to newer protocol versions is a slow and difficult process, often leaving opportunities for attacks; it is not easy to disallow the usage of older versions, because this will effectively deny service to older clients.
It is important to know that TLS is a framework that can use different algorithms for every connection; a communication using a given version of TLS may be more or less secure depending on the specific algorithms that are agreed when establishing it.
There are in fact three different operations that have to be done to secure a transmission:
- key agreement is the decision on which algorithms will be used for the following two operations, including the exchange of related parameters such as encryption keys/certificates;
- enciphering, using the cipher suite agreed in the previous phase, is the conversion of plain text information into encrypted values that can be sent securely over the network;
- data integrity verification is the check performed upon each block of received data to ensure that it was completely transmitted, that it really came from the expected source and that it was not modified during the transmission.
There are thus four different parameters that define the exact way of encrypting a communication with TLS: the TLS protocol version, the key agreement algorithm, the cipher suite and the data integrity algorithm.
Depending on the chosen algorithms, there may be further significant parameters; for example, the length of the encryption key(s). Even a secure algorithm can become insecure if its parameters are not adequate; for example, using an encryption key too short. In this case, brute force attacks (trying all possible values until the correct one is found) may be successful in breaking the encryption in an acceptable amount of time, which becomes shorter and shorter as the available CPU power increases.
Even today, while most services have moved to the latest versions of the TLS protocol, still many of them use insecure algorithms and cipher suites, or keys that are too short. Also, while many services will try to set up the communication in a secure way, they will however accept a client’s request to downgrade it to an insecure protocol version, algorithm or cipher suite, thus allowing a protocol downgrade attack, that can only be prevented by disabling insecure parameters altogether – though this will deny service to older clients.
Examples of widely used but insecure algorithms include cipher suites such as RC4, DES/3DES and MD5, SHA-1 as a data integrity algorithm, and basically anything with key lengths smaller than 1024 bits (but 2048 bits is now the minimum recommended key size).
Additionally, key agreement algorithms should provide forward secrecy, meaning that if a private encryption key is ever obtained by an attacker, which will inevitably allow the attacker to decipher any future communication based on that key, the attacker however should not be able to decipher past conversations. The only key agreement algorithms currently providing forward secrecy are Ephemeral Diffie-Hellman (DHE) and Elliptic Curve Ephemeral Diffie-Hellman (ECDHE).
Finally, TLS in itself does not provide any certainty on the actual identity of the parties in the communication. Even if one party sends a certificate to the other, stating some identity information about itself, that information does not have any credibility unless it can be verified with other trusted sources, for example because the certificate is signed by a certification authority or can be validated through DANE.
