Mail Us : info@infosekure.com
Call Now : +1 647 872 6673

What is TLS?

TLS is a protocol that provides a way for two parties to establish a secure communication channel between them.

That’s it.

But keep in mind that achieving this is no small feat. Look at TLS’ vulnerability history to see how hard it is.

TLS makes establishing a secure communication channel possible by providing three key services:

  • Confidentiality: ensures that data exchanged between peers is kept secret from third-parties. This is especially important for sensitive data, like passwords, credit cards, and the embarrassing contents of our shopping carts. Confidentiality is the characteristic that is most commonly associated with TLS, and its purpose is usually well understood;
  • Integrity: makes sure that data transmitted between peers is reliable and not tampered with during transit. Note that in the context of TLS, “integrity” refers to message authentication;
  • Authentication: ensures that clients communicate with legitimate servers. This is fundamental for assuring both confidentiality, and integrity, by providing trustworthy keying material for encryption and message authentication. Note that authentication and integrity are always important, whether the transmitted data is confidential or not. Optionally, TLS can also be used to authenticate clients, e.g. through client certificates, but this is less common;

Why do we need TLS?

One common criticism against TLS is that “TLS is slow”; for the vast majority of use cases, it is a misconception, even more so in TLS 1.3.

Another argument is that “All information on my website is public, so I do not need TLS”. A service providing public information may not require confidentiality, but authentication and integrity should never be optional. Otherwise, a user visiting an unprotected website has no guarantees about the authenticity of the information contained on it. The user may be attacked or, at best, annoyed by a potential man-in-the-middle — think Wi-Fi networks, or less ethical ISPs.

Some possible attack scenarios follow.

  • Subtly change a small, but critical, piece of information on a website. Such as a bank account number, cryptocurrency wallet address, phone number, email, and others;
  • Launch an “opportunistic cingryptojack” attack by injecting cryptocurrency mining code on the original webpage;
  • Redirect the victim to a phishing page to steal their credentials;
  • Inject ads and analytics/tracking javascript.

A brief TLS timeline

In the beginning, there was SSL 1.0. Not much public information is available. According to one source, several design flaws, such as missing data integrity and no replay protection, prevented SSL 1.0 from seeing the light of day;
SSL 2.0, the first public version, is eventually released in March 1995, as part of Netscape Navigator 1.1 browser. Several security issues are found, such as cipher downgrade and length-extension attacks;
SSL 3.0 is released in March 1996, with Netscape Navigator 2, fixing several vulnerabilities found in SSL 2.0;
TLS 1.0, a.k.a. SSL 3.1, is released in January 1999, after a standardization effort by the IETF. It is an incremental evolution over SSL 3.0, bringing no dramatic changes;
TLS 1.1 is released in April 2006. It includes mitigations to attacks on CBC ciphers. One particular change, explicit initialization vectors, will eventually prevent BEAST, five years into the future;
TLS 1.2 is released in August 2008. Changes include support for authenticated encryption with associated data (AEAD) ciphers, like AES-GCM, and stricter protocol validations;
TLS 1.3 is released in August 2018. There are many major differences from TLS 1.2, to the point that some believe it should be called TLS 2.0. We will briefly cover them below.

What is new in TLS 1.3

1. Perfect-forward secrecy is now mandatory.
2. TLS 1.3 comes with a redesigned, safer and faster 1-RTT handshake. In TLS 1.3, after the initial handshake messages, everything is encrypted. This means that even server certificates are encrypted.
3, A ton of stuff was removed: renegotiation, compression, and many legacy algorithms: DSA, RC4, SHA1, MD5, CBC MAC-then-Encrypt ciphers
4. Supposedly lot more reselient against downgrade attacks

 

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close