Recently I thought it was time to get back to basics, time to get in to the detail and I gave an internal session at Microsoft on (TLS) Transport Layer Security 1.3 and why its such step change for TLS.
I am sure you are probably aware TLS is an encryption protocol that protects Internet communications. It is the successor of the now-deprecated SSL (Secure Sockets Layer), which is a cryptographic protocol designed to provide communications security over a computer network.
Before I talk to you about TLS 1.3, lets spend 5 minutes looking at the history of TLS and SSL.
A Quick Bit Of History
Cryptography is an arms race and it is ever changing, what is secure today may not be secure tomorrow and I don’t know what everyone’s tech hobbies are but reading about cryptography and its evolution is certainly interesting, well for me.
If we start with SSL, it was developed by Netscape in 1995 with the grand purpose of creating secure communications between clients and websites, a pretty grand plan I am sure we would all agree. Netscape handed over SSL to the IETF (Internet Engineering Task Force) in 1999
TLS as we know has replaced SSL and can be seen as the next version of SSL, that said the name SSL has stuck at least from a marketing point of view
Both SSL and TLS work by using certificates to authenticate and encrypt, although TLS 1.3 modifies this. I’m not going to dwell any more on SSL, but it wasn’t too long before it was being to show its vulnerabilities.
There were downgrade attacks like POODLE, allowing you to use an older SSL version. SSL 2.0 deprecated in 2011, SSL 3.0 deprecated in 2015 and TLS was an improvement over SSL.
TLS 1.0 – 1999
TLS was 1.0 defined in 1999 but it was different enough that it could not interoperate with SSL 3.0
It did allow for a downgrade to SSL 3.0. Which could be looked at as a weakness, but when you introduce a new standard you can’t get everyone on it right away.
Kind of like say SSD drives, if you are old enough to remember, the days of ATA commands like SEEK, they implemented the ATA command set to be compatible with drives of the day before moving to more native signaling and control via NVMe.
TLS 1.1 – 2006
2006 ushered in TLS 1.1. Not to many changes here.
TLS added protection against cipher-block chaining attacks which prevented someone being to decrypt data, without knowing the key. Take a look at the link above, but the essence of cipher-block chaining attacks is using a “tell” concept which gives an attacker information about whether the action they’re executing is correct or not.
Imagine playing chess with a child. I know my daughters face lights up when she thinks she is about to make a good move, there is that tell or oracle I mentioned. That’s the concept of this type of attack.
TLS 1.2 – 2008
Defined in August 2008
MD5-SHA1 combination replaced by SHA-256, so we have some stronger hashing algorithms.
TLS 1.2, defined TLS Extensions which is RFC 6066. The TLS extensions specified are below and the extensions focused on extending the functionality of TLS
- Server_name
- Max_fragment_length
- Client_certificate_url
- Trusted_ca_keys
- Truncated_hmac
- Status_request.
TLS 1.3 – 2018
TLS 1.3, what we are here to learn about, its defined in another RFC at https://tools.ietf.org/html/rfc8446#section-1.2
Unsatisfied with the outdated design of TLS 1.2 and two-round-trip overhead, the IETF set about defining a new version of TLS. In August 2013 the IETF laid out a wish list of features for the new protocol:
They were
- Reduce Handshake Latency
- Encrypt Significantly More of Handshake
- Improve Cross-Protocol Attack Resistance
- Convert Entirely to AEAD Cipher Suites
So 10 years had passed, 28 drafts and TLS 1.3 became a new standard in March 2018
It removed support for older / vulnerable encryption standards MD5 and SHA224 as well support for weak and less used Elliptical Curves.
But still there were some issues to work through. Most noticeably Chrome, version 56 and proxies from Symantec.
There was a pretty public documented issue with school district in the USA, the Montgomery County Public Schools updated to Chrome 56
One-third of Chromebooks and “some” Windows PCs suddenly could not get through the login screen any longer, Google says this was because Symantec Blue Coat security software implemented TLS 1.3 improperly. Google temporarily paused rollout of TLS 1.3 in Chrome.
A few more teething issues but the advantages of TLS 1.3 was pretty clear.
Performance
Lets relate it back to the IETF’s wish list and start with performance
For a browser and web server to agree on a key, they need to exchange cryptographic data. The “handshake” in TLS, has remained largely unchanged since TLS was standardized in 1999. The handshake requires two additional round-trips between the browser and the server before encrypted data can be sent (or one when resuming a previous connection). The additional cost of the TLS handshake for HTTPS results in a noticeable hit to latency compared to an HTTP alone. This additional delay can negatively impact performance-focused applications.
If we look at the image above, each one way trip lets say is 50ms, I am going to be saving 100ms. It could be more. it could be more, I am in Melbourne, Australia, its 220ms round trip to Microsoft.com.
From an end-users experience this just translates in to a snappier performance.
Compatibility
It would be great to obviously just tell everyone to turn on TLS 1.3, lets get that performance gain I just spoke of but the reality is customers may have browser support policies or SOE’s (Standard Operating Environments) based on browsers, I was going to make a joke about organisations still using Internet Explorer 6 support, but you get my point.
I like to write code, scripting mainly. Older versions of Windows 10 didn’t have native TLS 1.3 support nor do versions of OSX < 10.14.
That’s the bad news, the good news is if you maintain your software hygiene which we should all do, and as a society businesses and individuals the like are getting better at this, and as I pen this in 2021, TLS 1.3 support should be a given.
Facebook is recording more than 70% of traffic is being served with TLS 1.3 and overall penetration of TLS will continue to grow as browsers and apps add support for TLS 1.3. There is a good article on how Facebook implemented TLS 1.3 on their engineering blog.
As we can see with the fullness of time there will be support for TLS 1.3 in all browsers and OS’es and given the performance gains it warrants adopting where possible because saving hundred of milliseconds per round trip (potentially) just by leveraging a modern version of TLS is an easy win.
Security
I did say in the title of this session TLS 1.3 was more secure and it is.
In the last two decades, we as a society have learned a lot about how to write secure cryptographic protocols. Attacks like POODLE, SLOTH and so on have showed that even TLS 1.2 contains antiquated ideas from the early days of cryptographic design, back to the 70’s. One of the design goals of TLS 1.3 was to correct previous mistakes by removing potentially dangerous design elements, again this goes back to the IETF wishlist.
I want to talk to you about RSA and Diffi Hellman as two alternate ways of establishing a shared secret with public key cryptography.
Lets look at RSA or the Rivest, Shamir and Adelman method first as this is the more simplistic method.
The client encrypts the shared secret with the servers public key and sends it along. The server then uses its private key to decrypt the shared secret and like that , they then both share the same secret.
So to summarise in TLS’s RSA key exchange, the shared secret is decided by the client, who then encrypts it to the server’s public key (extracted from the certificate) and sends it to the server.
Now lets talk about Diffie-Hellman.
In Diffie-Hellman, the client and server both start by creating a public-private key pair. They then send the public portion of their key share to the other party. When each party receives the public key share of the other, they combine it with their own private key and end up with the same value: the “pre-main” secret. The server then uses a digital signature to ensure the exchange hasn’t been tampered with. This key exchange is “ephemeral” and the client and server both choose a new key pair for every exchange. Really key point here.
Both modes result in the client and server having a shared secret, but RSA mode has a serious downside, it doesn’t support forward secrecy, which means if someone records the encrypted conversation and then obtains the RSA private key of the server, they can decrypt the conversation. This even applies if the conversation was recorded and the key is obtained some time well into the future. In a world where recording of encrypted conversations is possible and using exploits like Heartbleed to steal private keys can occur, this is a realistic threat.
To reduce the risks caused by non-forward secret connections and million-message attacks, RSA encryption was removed from TLS 1.3, leaving ephemeral Diffie-Hellman as the only key exchange mechanism.
In 2015 LogJam and WeakDH showed that many TLS servers could be tricked into using small numbers for Diffie-Hellman, allowing an attacker to break the security of the protocol and decrypt conversation
TLS 1.3 brought a few more changes on Diffie-Hellman front, in previous version of TLS the choice of parameters was up to the client. This resulted in some implementations choosing incorrectly, resulting in vulnerable implementations being deployed. TLS 1.3 takes this choice away.
Like any good Solution Architect TLS 1.3 takes the opinionated route, restricting the Diffie-Hellman parameters to ones that are known to be secure
TLS 1.3 and Microsoft
Like most vendors, support for TLS 1.3 in Microsoft’s products is mixed but the following article details our approach from OS through to Frameworks regarding TLS 1.3 – Microsoft TLS 1.3 Support Reference | Developer Support
If you were wondering what about Azure, TLS 1.3 are roadmap items for many of our a PaaS services.
Summary
I have only scratched the surface on TLS 1.3 but I hope it’s clear to see that is a step-change in both performance and security.
I hope this has sparked you imagination to dive deeper and dive deeper in to an RFC or two.
I work for @Microsoft but opinions expressed are my own
Thanks
Shane Baldacchino