Why you shouldn’t rely on SSL in your next app

…or at least understand it’s realistic role and risk model, if you can.

Introduction

Everyday software developers trust SSL / TLS encryption to protect their communications without considering whether or not this is the right thing to do. We frequently see new SSL vulnerabilities. Theoretical threats rapidly become practical. But we still see (perhaps for the sake of convenience and familiarity) SSL /TLS being deployed everywhere without a backthought, providing a false sense of security rather than security itself.

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, when you should avoid it and why.

Warning! Don’t let the title mislead you: we advocate using better and safer schemes than relying solely on SSL, 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, at least take the time to use best industry experience to do so, securely.

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.

A “short” list 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:

1. protocol design:

• protocol itself is obscure and complicated: which makes it hard to audit and easy to introduce bugs: infamous heartbleed
• protocol lacks important features: perfect forward secrecy comes only in most recent TLS 1.2 in some (not all) ciphersuites
• protocol mandates only client authenticating the server, reverse is optional: works by default without authenticating the client
• communication leaks data: session status, identity of parties
• authentication before encryption: misplaced sequence of authentication and encryption led to POODLE attack’s second coming

2. bad 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.
• most bad ciphers are still in your browser and your server: just check for yourself how’s my ssl, ssl labs

3. 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). CSRrelies on availability of CA’s servers, has plenty of problems.
• 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.

4. 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).
• 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.

5. 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.

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 endeavors, 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 libraryThemis. 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 ranging 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:
• SSL Pinning
• 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:

1. 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.
2. 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.
3. Noise protocol framework for designing transport security the way you need it.

Understanding problems with SSL:

1. 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.
2. SSL Pulse or how exactly is safe SSL-protected Internet is, today
3. Lessons Learned From Previous SSL/TLS Attacks, a scientific study of reasons, unseen cause-and-effect relationships and wrong judgment in history of SSL

Deploying SSL properly if you really have to:

1. OWASP guide, TLS Cheat Sheet
2. SSL Labs guide
3. Electronic Frontier Foundation good SSL tutorial

Thanks for reading!

P.S. This article was originally published on our blog.