TLS stands for “Transport Layer Security” and it’s rather important. Why’s that? Oh, I’m glad you asked. Here’s me, yelling my password across the office to you:
“PASSWORD!!!”
You heard me loud and clear, right? But so did basically anyone else nearby. Now let’s work in a little TLS love and attention, and yell again:
“Large pile of nonsense where the password should be!”
Wow! What happened? Imagine my endlessly yelled password is available to really clever people, uh, standing outside my window listening in. Imagine someone soundproofed said room to enable continued, secure, password yelling. I can yell “Password!” at you all day long, and all anyone else will hear is garbage.
That, in a roundabout “analogy crashing to the ground” sort of way, is TLS. It’s a cryptographic protocol that keeps your communications secure as they make their way from point A to point B. It’s very hard to intercept, listen in, or crack.
Here comes TLS 1.3
SSL—Secure Socket Layer—came about in 1995 with version 2.0, courtesy of Netscape. Over the years, it slowly morphed into something else, becoming TLS in 1999. After more alterations and updates, TLS 1.2 came about in 2008, and we’ve been running with it ever since.
Now, after four years of work and 28 revisions, TLS 1.3 is almost ready to make its debut. This new version makes alterations to how HTTPs connections work, and the Internet Engineering Task Force have stated that it “…will enable client and server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.”
Bad news for scammers, and quite possibly also for high-level law enforcement operatives with a hand in computer-based digital observation. Outdated encryption is also out the window, with TLS 1.3 consigning long-term broken forms of encryption to the dustbin.
What’s changing with TLS
Here’s a short selection of alterations from the TLS Wiki page, and as you can see, there’s a fair bit of functionality being stripped out to make way for the new revisions:
- Removing support for weak and lesser-used named elliptic curves (see elliptic-curve cryptography)
- Removing support for MD5 and SHA-224 cryptographic hash functions
- Requiring digital signatures even when a previous configuration is used
- Integrating HKDF and the semi-ephemeral DH proposal
- Replacing resumption with PSK and tickets
- Supporting 1-RTT handshakes and initial support for 0-RTT (see round-trip delay time)
- Dropping support for many insecure or obsolete features, including compression, renegotiation, non-AEAD ciphers, static RSA and static DH key exchange, custom DHE groups, point format negotiation, Change Cipher Spec protocol, Hello message UNIX time, and the length field AD input to AEAD ciphers
Indeed, one of the biggest problems caused by this new set of comprehensive changes are those faced by financial institutions, and anyone dealing with regulatory compliance. Due to how the new setup works, it’ll be harder for them to inspect traffic on their networks and see what’s taking place. There’s also the potential for technical flaws causing some major headaches, as is evidenced by the spectacular bricking of 50,000 Chromebooks last year after an update was applied.
Despite the inevitable teething problems, ultimately this is good news for most of us, with the exception of a few organisations who’ll have to find new ways to work with it. Hopefully, a stronger set of security protocols with TLS 1.3 will result in a very big headache for people dabbling in mischief.
