Introduction
2018 update: This article was 4 years old, and even then presented disputable opinion. Many things have changed since then, we're having TLS 1.3, which eliminates a number of cryptographic concerns and enforces correct uses. Still, many challenges stand unaddressed. We've remixed the article to keep relevant problems, and outline solutions to those solved, along with a few thoughts on what and when you can use instead.
Everyday software developers trust SSL / TLS encryption to protect their communications without considering whether or not this is the right thing to do. While developing and improving our crypto library Themis, we monitor SSL vulnerabilities - they are a good lesson to anyone building encrypted communications stack, and it's always better to learn from mistakes of others.
This article provides a short overview on what we (and other security and cryptographic engineers around the world) find wrong with SSL/TLS and particularly in the case of non-Web application development, when you should use it and when you should avoid it, what you can replace it with.
Warning! Don't let the title mislead you: we advocate using better and safer schemes, not dumping SSL and going naked in the hostile environment! If, after reading the post, you still would like to go on with SSL as your only security measure, please, take the time to use best industry practices to use it.
Note: SSL, TLS and SSL/TLS are used interchangeably in this article, except where the exact version or version family is specified.
What SSL/TLS is supposed to provide
Wikipedia accurately defines TLS as:
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both of which are frequently referred to as 'SSL', are cryptographic protocols designed to provide communications security over a computer network. They use X.509 certificates and hence asymmetric cryptography to authenticate the counterpart with whom they are communicating and to negotiate a symmetric session key. This session key is then used to encrypt data flowing between the parties. This allows for data/message confidentiality, and message authentication codes for message integrity and as a by-product, message authentication.
SSL/TLS seeks to solve two broad problems for undefined and unregulated parties:
A user who wants to connect securely to many heterogeneous services using a single client application like a web browser.
A provider who wants to offer a secure service (with low friction) to many heterogeneous clients through HTTP server with SSL.
So, what exactly is wrong with SSL?
Stop and think for a moment of the complexity that these desires precipitate:
The user's desire to connect securely to an arbitrary service and have trust in both the security and authenticity of the service underpins the need for the severely non-trivial Certificate Authority infrastructure.
The providers desire to offer a low friction service, while at the same time having no explicit control over the client application being used, underpins the need to offer backward compatibilities and a range of cryptographic algorithms (with varying degrees of security).
In some cases, like the modern web, we don't have much choice apart from SSL: it is already there and it can't be replaced easily, so many components relying on SSL, and SSL somehow does the job most of the time.
In other cases, where developers have control over both client and server, specifically in mobile world, developers can consciously choose something more relevant, but for various reasons they don't.
General challenges
TLS, as any public-key based transport encryption scheme, is facing general design problems of public key cryptography. Many cryptographers work around by defining constrains as "the system works under assumptions of X",- but to understand the bigger picture, it is wise to have a close look at these problems.
These assumptions are mainly bound to three problems:
Identification/trust. Any public key is useless unless we really know it belongs to other party. We want either to get that key from a remote party directly, which defeats a bit the whole purpose of "being able to set up trusted connections with parties whom we won't know yet", or have a trusted third-party certifying that the key actually belongs to the party we're trying to establish trust with. This is, essentially, why we have the whole PKI/CA infrastructure.
Revocation. Compromise of a private key (which, in the end, is just a file on the hard disk in many cases) requires key invalidation procedure. To address that, we want PKI/CA infrastructure to either have a list of "invalid" (revoked) certificates (CRL) or online validation procedure (OCSP).
Central Authority trust. Parties intermediating our trust to remote nodes may be compromised or misbehave.
These concerns are well explained and discussed in this essay, we'll discuss on addressing some of these challenges later in the post.
A "short" list SSL-specific of problems
It should come as no surprise that SSL/TLS in the attempt to be “All things to everyone” (or “The One Ring to Rule Them All”) has to be complex both in design and implementation and thus open to flaws and exploits:
protocol design:
protocol itself is obscure and complicated: which makes it hard to audit and easy to introduce bugs. TLS 1.3 is an attempt to address these challenges, and it does eliminate some of the pitfalls.
Protocol lacks important features: perfect forward secrecy comes only in most recent TLS 1.2 in some (not all) ciphersuites, and most ciphersuites in TLS 1.3.
Protocol mandates only client authenticating the server, reverse is optional: works by default without authenticating the client, which is how the web security should be built, but isn't sufficient for trusted application-server communication.
Communication leaks data: session status, identity of parties.
Authentication before encryption: misplaced sequence of authentication and encryption led to POODLE attack's second coming. TLS 1.3 mainly offers AEAD mode of symmetric encryption, which eliminates the problem completely, if appropriate ciphersuite is chosen. Ciphersuites to use:
TLS13-CHACHA20-POLY1305-SHA256, TLS13-AES-256-GCM-SHA384Poor choice of ciphers and cipher modes:
Performance over security: diffie-hellman exchanges are used in worst way possible, opening doors to abuse.
Most bad ciphers are kept in SSL for too long: for example, RC4 is known to have weaknesses ~10 years before actually getting exploited, yet it is still widely supported by default SSL configurations, because it was used to mitigate another cryptographic attack some time ago. This is only addressed in TLS 1.3 by disallowing anything but AEAD symmetric ciphers.
Most bad ciphers are still in your browser and your server: just check for yourself how's my ssl, ssl labs
Certificate trust model: certificate authority, certain certificate parameters and structure of trust is flawed too: they've been created for too generic purpose and adapted to the needs of certificate authorities, not end-users:
OCSP/CSR revocation list verification is nearly useless: failure to verify for revocation status doesn't stop browsers and apps from proceeding (soft-fail). CSR relies on availability of CA's servers, has plenty of problems. It took us to 2018 for major browser vendors to start explicitly warning about non-SSL connections and soft-fail to unencrypted mode.
The model: the trust model behind CAs is at least questionable.
Root of trust problem: pocket CAs allow remote governments to pretend being Google.
SSL pinning is hard to do and easy to break
Complicated PKI infrastructure is necessary to maintain CAs: which is, again, a risk vector of it's own.
Issuing certificates relies on DNS and e-mail, which delivers your certificates. E-mail's domain is not required to be verified.
CAs are incentivized to hide breaches since they undermine the concept of trust, so when they're hacked, there's a chance you won't know the truth. And they do get hacked: DigiNotar, Comodo, and they do try to keep it below the radar.
Some CAs are actually selling subordinate root certificates to third parties to impersonate virtually anyone, moreover, they admit it and consider reasonable practice.
...And you can impersonate being a CA with sufficient computing power yourself, taking a bunch of playstations and clever hash collision attack.
Complexity and stack problems: most of these problems are bugs that arrive, get fixed and vanish in history. But they demonstrate how complexity of the whole stack leads to very, very nasty bugs, and sometime they inspire next generations of exploits, addressing the same weaknesses under new angles. Did you know that POODLE and BEAST are relatives?
Through compression: CRIME vulnerability, which was theoretically predicted 10 years ago
Mixed content: mixing HTTP and HTTPS poses significant threats even without any bugs (HTTPS mixed content vulnerability). Similarly, going from HTTP to HTTPS via link in HTTP content (that applies not only to web in browser, redirects in web views in mobile apps count, too) is a bad idea some smart people know how to exploit (sslstrip). Only in 2017 browsers and web developers started giving a thought of detecting and preventing mixed-content vulnerabilities, and it's still a long way to go.
Weakest party defines the ciphersuite: when two parties have weak cipher suites enabled and one of them doesn't have any strong ones, for the sake of connectivity they will use weak ones, creating false sense of security while there ain't any.
Implementations are really very buggy: let the numbers of biggest vulnerability databases speak for themselves: CVE, NVD.
Why does this even happen to such an important security instrument?
Apart from complicated protocol design (which has it's pros and cons as an internet protocol), SSL is prone to some conceptual problems:
Legacy and compatibility...
SSL has long history of problems - not least due to decades-long-lasting compatibility and legacy code and obscure implementations of rather a complicated protocol. For example, the very first SSL protocol (SNP) was introduced with "It is designed to resemble the Berkeley sockets interface so that security can be easily retrofitted into existing socket programs with only minor modifications." attitude in mind. This is not exactly what you want a security protocol to focus on. Lately, TLS 1.3 addresses most of these issues by throwing most obviously insecure cryptographic choices away.
A multifunctional coffee machine with integrated ethernet switch and FM radio
TLS, although designed for security, tries to do much more: negotiate network, compress data, be backwards compatible (backwards compatibility in rapidly changing security landscape is an odd priority, specifically in 2015, where updating things is not so effortful as it was). Inventing a new crypto algorithm with long, strong keys, but making it backwards-compatible with DES and 56 bit key makes no sense, right?
Many problems arise partly because TLS itself violates one of the most important Unix design principles: "Do One Thing and Do It Well".
Security is a system, not a pluggable library
Since TLS is a massive interdependent system, users wanting to use it have to be aware that plugging in SSL/TLS library is insufficient. SSL/TLS should be managed as a system:
trusted CA certificates have to be reviewed regularly
measures have to be taken to protect private keys
enabled cipher-suites have to be reviewed
each peer has to have different keys for different cipher-suites (RSA, ECDSA)
compatibility for peer software
... and many many more minor things (see annex for link list)
Who should we be afraid of?
Although there is a popular misconception that man-in-the-middle, cipher weakening and traffic decryption are complicated technical endeavours, they are not so anymore. With modern tools, it is not that hard: internet providers, law enforcement, malicious ad providers and malware all do it with ease to achieve their ends.
Vulnerabilities mentioned in this article allow attackers to:
Steal your data. Secrets you would like to keep - will be stolen.
Steal your identity. Your authentication credentials will be used to impersonate you: at your work, at your bank and in your communications with friends and family.
Modify your transactions. Your passwords can be changed or a rogue bank account can be inserted into a transaction you've already securely authorised.
Impersonate a trussed service. You will be mislead into giving out even more data.
If your application is vulnerable, these are the risks you are exposing your users to.
And, by the way, there are companies who's business is specifically exploit SSL at company, city or nation scale:
BlueCoat: SSL Visibility appliance
GigaMon: SSL Decryption in GigaSMART
WaveCrest: CyBlock
Mitigating the risks
As this article aims to illustrate, SSL/TLS is born of the needs of general Web Services accessed through a browser. In contrast, mobile applications, regular client-server infrastructures (be it distributed network systems or a bunch of desktop applications attached to a server) have significantly different attributes especially in the case of and end-to-end client/server based service:
The person connects to a specific service associated with the application. Trust is vested in the application server/application vendor rather than the CA infrastructure.
The service provider (especially if they are also the application vendor) can mandate specific client application behaviours and capabilities.
In such cases with much of it's raison d’être absent, one must question whether using SSL/TLS is appropriate as opposed to one of the more focussed and lightweight libraries that provides secure network messaging such as NaCL; or our own library Themis. Indeed, Themis was designed specifically to provide good socket protection and session communication protection, while being secure, cross-platform and easy to use.
So, what should you do with your next application?
In short, it is as ever a case of picking the right tool for the job:
If you need the wide range of behaviours associated with Web users, there are important choices to be made about the implementation of SSL/TLS that you deploy. Check here or scroll to article annex for wider list of options.
If must have SSL/TLS inside you application (for example that is all that is offered by the service you connect to), implement best regular TLS practices and specific application schemes that you can trust:
force handling of OCSP errors
disable weak ciphers and bad TLS settings from this cheat sheet
still encrypt most critical fields with something (Secure Cell from Themis for both iOS and Android, RNCryptor for iOS, Google KeyCzar for Android.
If your application is part of an client-server/end-to-end service and can avoid relying on SSL/TLS, consider using a library that does exactly what you want (NaCl, Mozilla NSS, Themis to name a few).
Further reading and links
Some SSL alternatives for client/server applications:
Themis: this is free open-source library we as a company developed, because we were not satisfied with absence of free, secure socket solution for our own needs.
NaCl / LibSodium: Networking and Cryptography library (NaCl) was designed by prominent cryptographic scientist and software developer, Daniel J. Bernstein, libsodium is a more portable and cross-platform friendly port of it.
Aside from plugging easy-to-use, hard to break encryption schemes into your own applications, there are protocol construction kits, which enable you to bootstrap your own communications scheme, at the same time enforcing secure cryptographic practices. However, building communication security protocol for real-world use should be carried out by professionals: no matter how much we grumble in TLS's address, thousands of human hours of extremely smart security engineers and cryptographers have been put into improving it - if they failed, it's a very small probability that most people would do better.
STROBE protocol framework, if you'd like to homebrew your own cryptographic protocol for fun and learning.
Noise protocol framework, another, more down-to-earth, attempt at building construction kit for building secure transport protocols. Some popular security solutions are using parts of Noise Framework in production, yet we are to see the more thorough security analysis of their merit.
Understanding problems with SSL:
BoringSSL: Google's BoringSSL initiative is OpenSSL fork driven by desire to throw away lots of legacy OpenSSL code, avoid problematic programming practices, clean the backwards-compatibility where possible. This article outlines some of the Big G's concerns for SSL itself.
SSL Pulse or how exactly is safe SSL-protected Internet is, today
Lessons Learned From Previous SSL/TLS Attacks, a scientific study of reasons, unseen cause-and-effect relationships and wrong judgment in history of SSL
CloudFlare's Keyless SSL scheme, which allows you to lower attack surface on the most precious asset in the whole system - private key.
Deploying SSL properly if you really have to:
OWASP guide, TLS Cheat Sheet
Electronic Frontier Foundation good SSL tutorial
Thanks for reading!
If you're looking to implement security, apply for our Customer Success Program. Also, consider checking out other Cossack Labs’ products like Themis, Acra, Hermes, or Toughbase.
