Outline
Transport Layer Security is the de facto standard on how to organize and use cryptography for Network Security. TLS libraries are now used not just to protect the privacy of the information you send and receive to a website. It is also used for complementary network security services such as DNSSEC and Resource Public Key Infrastructure.
Why Transport Layer Security Is Important (TLS)?
Without TLS all the information we send and receive to a web server can be viewed by someone else. TLS ensures all our communication with a website is private and only known between us and the web server. Throughout history attackers have captured network packets sent or to be received by clients. This can disclose sensitive information such as passwords, bank credentials, government ID, or personal identifiable information managed by a hospital. This attack is known as the Man-In-The-Middle Attack.
Here is a quick list of approved algorithms in TLS 1.3, the most recent version of TLS:
Now, those sure are a lot of algorithms. If you are interested in understanding the difference between those algorithms in the "Cipher Suites" mentioned above I strongly recommend reading "Serious Cryptography" by No Starch Press. If you already read that then read "Bulletproof TLS and PKI, Second Edition" by Ivan Ristic--a must read. Ristic gives a strong review of the pros and cons of selecting between different cipher suites--and infamous attacks that affected TLS.
TLS began with NetScape, and later the Internet Engineering Task Force standardized TLS--a family of programs of mostly federal-government approved cryptographic algorithms. Most of the algorithms you see in the above photo are approved by the federal government except for the CHACHA20 cipher and the POLY1305 MAC. Throughout history, TLS has suffered from major vulnerabilities. And this is because cryptography is very hard to program correctly. If you visit the link you will see many of the same vulnerabilities repeating.
If TLS is so important why is it flooded by so many security problems?
The Broken History of the Internet
Nothing made by humans is meant to hit perfection. The Internet was never designed with the idea that people around the world will be communicating with each other from one corner of the Earth from another. The Internet was designed by Computer Scientists that were trying to communicate from one university in the same state that were physically close to another university.
Likewise, Transport Layer Security were not written by expert cryptographers. The first few versions were haphazardly made in a startup called Netscape. Its crazy how Security Engineers insist you should never roll your own cryptography--and yet the people that develop cryptography at famous companies...are not cryptography experts anyway! Yes, companies that are world-famous companies deal with this reality everyday. And yet, security nerds insist you should not roll your own cryptographic software. Granted, these top companies have a dedicated team to test the security of the cryptographic software or work with the federal government to test the security of the cryptographic software. So don't compare yourself to them! Get a professional team to test your software. Attend security conferences to meet people like that!
And the funny thing is...the TLS libraries federal governments and the world's most prestigious businesses and universities rely on...are bloated and fraught with security vulnerabilities anyway. I am not just talking about OpenSSL like normal. Just look at the below table comparing several TLS libraries and their security vulnerabilities:
Take a look at that chart. The only two TLS libraries that do a solid job of defending against constant-timing attacks--an infamous side channel attack that threaten to steal cryptographic secrets with only a remote Internet connection--are Google's BoringSSL (hats off to the caliber of the team!) and BearSSL (you should pause this video and visit the site now!).
What's funny is BearSSL is not FIPS 140 validated--meaning it is unsuitable for use by the federal government--the organization that standardized most of the cryptography you see these libraries offer. Isn't that ironic?
The thing is--people unfortunately really don't care that much about just the strength of the security of the library as they ideally should. The reason why OpenSSL has the highest market share is that it was designed to meet as many people's needs as possible as fast as possible. OpenSSL is meant to run on any machine architecture. It is meant to run on powerful machines that speed up and protect the secrecy of cryptographic keys. These machines are called hardware security modules. If you don't know what that is you should pause this video now and look it up. Hardware Security Modules are the machines that protect business secrets from being stolen by malware. Without them the Internet would be far less safe than it is today.
OpenSSL unfortunately is poorly written and not carefully reviewed by other cryptographic developers for correctness and security. It has one of the messiest codebases ever. But it is still the most successful TLS library and is one of the few that can scale with business demands. Again hardware security modules allow businesses to protect online privacy as a user base on a computer network service grows. They are indispensable to serve the human population. Strangely only the GNUTLS library also supports this. No other. That one feature--supporting scalability of a growing user base--might just be the real reason why OpenSSL still is the king of TLS. Yet its messily written.
I am not saying I blame OpenSSL. They are so underfunded its criminal. So underfunded and understaffed we can't just blame them. They receive less than $9000 USD/year. Yeah, and that's the de facto TLS library the world's top companies and the US government relies on. That's not just sad. That's just terrifying.
OpenSSL is not the only TLS library that whose security quality badly needs more scrutiny. One of the worst problems I see in TLS libraries is that they are difficult for people to use.
Its a problem in the world of cryptographic development--the people that develop cryptographic libraries failed to be empathetic to the people that rely on them but are outside their domain of expertise. As a security developer you MUST have the empathy to determine if what you are saying is something your audience understands. But in the real world cryptographic libraries are muddy with esoteric documentation--sometimes even crappy. And even crappier code.
This is why the top second OWASP failure are cryptographic ones--normal software engineers can't understand how to use cryptography since the people that developed the software did not do a good job communicating their ideas to them. Most of the problems in the security world are communication issues. And lack of good communication breeds security problems.
Lack of Education Breeds Lack of Good Practice
Perhaps due to a lack of good documentation--most of the world is severely behind on cryptographic standards. We still have business relying on RSA to digitally sign our documents, to verify our payments, and to protect our online communication. RSA is an earlier public-key cryptosystem that is significantly easier to steal secrets from than more modern ones. RSA is very easy to program insecurely. It is easier to crack. So why is the weaker cryptographic algorithm used more often in reality.
Community Support for CryptoSystems Is Crucial for Adoption
From my research--I noticed older cryptosystems have stronger community support than newer ones. Until the community support for newer cryptosystems rivals that of the previous one--the outdated previous one will remain dominant. What do I mean by community support.
The stronger the community support for a cryptographic solution--the easier it is for someone to contact a member of the security community and solve practical problems with the cryptosystem. Think about this: how much easier is it for you to make use of RSA to protect a file you want to keep secret compared to the new post-quantum safe public-key cryptosystems. In the past I have found online blog tutorials to make use of GNUPG, any TLS library, and even pocket-sized hardware security modules such as my Yubikey.
Now I want you to find blog tutorials to use Dilithium to protect your online communication or to sign your documents. Pause this video and try it now. I will wait.
You didn't manage to find much did you? The only good resource I found was WolfSSL--which supports the algorithm in their software (hats off to the team!).
We need more people that can teach people that are struggling to use this life-changing technology to protect their freedom of speech and online privacy.
What's said is it is easier to program newer cryptosystems such as Dilithium versus older ones such as RSA--yet they lack adoption due to lack of community support (aka good documentation).
Why The World Lacks Good Teachers in Cryptography
I think its truly sad how I could more easily find a production-ready solution that offers you a commercial solution instead of a simple educational tutorial. It means the world values easy do it for-me solutions compared to the actual thing that's good for you--being skilled at using cryptography and adapting what's available to suit your needs. This would do a lot to improve the situation for online privacy--not just relying on an off-the-shelf solution.
The industry obviously values profit more than good practice. Famous security professionel such as Marcus Ranum have already complained about this (Read the Article its one of the best ones I read!).
The sad truth is--good teaching material alone does not pay. Coders need to eat and people pay for convenience--less so education. People don't actually want to build their own skills through serious work. They would rather use their money to let someone else to do their hard work for them.
That's why you see organizations use outdated infrastructure and outdated security. No one wants to go through the hassle educating human beings to upgrade their skillset in cybersecurity--doing the right thing. Its costly! But its the correct thing to do.
I originally began writing this having no idea I would reach these conclusions. But now that I wrote that--I have to admit--not only do we need to better education--we need to figure out better ways to reward people for it. Or we will be stuck in this drag where we cannot move on to better security solutions for the future. No one is going to go through the effort of training other people in good cryptography practice unless they earn enough to outsource the tasks they should not be spending their time on--food, a good living place, recreation opportunities, and tools to make them more productive.
TLS is Only 1/3 of Protecting Online Communication
TLS depends on two other technologies to function: Border Gateway Protocol (BGP) and Domain Name System. Border Gateway Protocol is the protocol that allows network protocols to be transported from router-to-router--carrying your network packets to what is supposed to be the correct IP address. Domain Name System translates domain names to what is supposed to be the correct IP address.
There is a reason why I keep saying "supposed to": neither of these protocols give a reliable assurance of carrying your information to the correct destination. Attackers have succeeded in hijacking BGP to an attacker's IP address. This is known as a BGP Hijacking Attack. Attackers have also succeeded in corrupting replacing the correct IP address mapped to a domain with the attacker's IP address--forwarding clients to an attacker's website. This is known as a DNS Cache Poisoning Attack.
What's odd is that the security world stresses TLS so much. To a much lesser extent it stresses the importance of Domain Name Systems Security Extensions--the digital signature system that prevents attackers from corrupting DNS records. Even less yet more important is Resource Public Key Infrastructure--the digital signature system to distinguish if an IP address belongs to machine under BGP. TLS and DNS both depend on BGP to function. And TLS depends on DNS to issue TLS Certificates to the correct owner of a domain. Yet for some reason the importance of DNSSEC nor RPKI is not marketed well.
The situation gets messier. Both DNSSEC and RPKI rely on TLS cryptographic libraries to do their jobs--yet TLS depends on DNS and BGP working properly to function. Technically this is ok since DNSSEC and RPKI just need the cryptographic software from TLS libraries to function. The only issue is if there is a problem with the TLS library--such as lack of audited or clean code--there are risks of security bugs that propagate from TLS.
Today I just wanted to share my concerns with the current state of cryptographic software development. What I said should make clear we are in a very sticky situation with cryptographic software development--despite the US doing a great job standardizing the cryptography we should use to protect our online privacy.
Comments