CC BY-ND 2.0 image image by Clinton Steeds
CloudFlare is always trying to improve customer experience by adopting the latest and best web technologies so that our customers (and their visitors) have a fast and a secure web browsing experience.
More and more web sites are now using HTTPS by default. This sea change has been spearheaded by many groups including CloudFlare enabling free SSL for millions of sites with Universal SSL, Google moving towards marking plain HTTP as insecure in Chrome, and the Let’s Encrypt project’s plans to make certificates free in 2015.
Not only is the encrypted web more secure, it can also be faster than the unencrypted web if the latest HTTPS features are implemented. HTTPS sites are blazing fast on CloudFlare because we keep up with the latest performance-enhancing features:
SPDY 3.1 is on by default for all customers. SPDY enables faster-than-HTTP download speeds by enabling multiplexing
OCSP stapling: faster revocation checking.
Optimized certificate bundles using CFSSL, our open source SSL bundler: an optimized certificate chain provides faster validation of certificates in the browser
ECDSA certificates for all free customers with Universal SSL: smaller certificates with smaller keys result in faster connection establishment times
Global session ticket resumption for faster session resumptions on globally load balanced servers: connections to sites you have already visited are jump-started requiring one less round-trip to resume
Today we are adding a new feature — actually a new form of encryption — that improves mobile performance: ChaCha20-Poly1305 cipher suites. Until today, Google services were the only major sites on the Internet that supported this new algorithm. Now all sites on CloudFlare support it, too. This means mobile browsers get a better experience when visiting sites using CloudFlare.
As of the launch today (February 23, 2015), nearly 10% of https connections to CloudFlare use the new ciphersuites. The following graph shows the uptick when we turned ChaCha20/Poly1305 on globally:
TLS to the max
The protocol for encrypting HTTPS connections is called Transport Layer Security (TLS). One of the nice features of TLS is that new encryption algorithms or ciphers can be proposed and added to the specification.
As we described in our introduction to TLS, there are several components to a TLS cipher suite. There is one algorithm for each of the following:
key establishment (typically a Diffie-Hellman variant or RSA)
authentication (the certificate type)
confidentiality (a symmetric cipher)
integrity (a hash function)
The new cipher suites we have added include a new symmetric cipher used for the encryption of data (based on the ChaCha20 and Poly1305 algorithms). There are no secure encryption algorithms optimized for mobile browsers and APIs in TLS right now—these new ciphers fill that gap.
There are two types of ciphers typically used to encrypt data with TLS: block ciphers and stream ciphers. In a block cipher, the data is broken up into chunks of a fixed size and each block is encrypted. In a stream cipher, the data is encrypted one byte at a time. Both types of ciphers have their advantages, block ciphers are generally fast in hardware and somewhat slow in software, while stream ciphers often have fast software implementations.
TLS has a secure block cipher, AES, that has been implemented in hardware and is generally very fast. One current problem with TLS is that there is no secure choice of stream cipher. The de facto stream cipher for TLS is RC4, which has been shown to have biases and is no longer considered secure.
AES is a fine cipher to use on most modern computers. Intel processors since Westmere in 2010 come with AES hardware support that makes AES operations effectively free. This makes it an ideal cipher choice for both our servers and for web visitors using modern desktop and laptop computers. It’s not ideal for older computers and mobile devices. Phones and tablets don’t typically have cryptographic hardware for AES and are therefore required to use software implementations of ciphers. The AES-GCM cipher can be particularly costly when implemented in software. This is less than optimal on devices where every processor cycle can cost you precious battery life. A low-cost stream cipher would be ideal for these mobile devices, but the only option (RC4) is no longer secure.
In order to provide a battery-friendly alternative to AES for mobile devices, several engineers from Google set out to find and implement a fast and secure stream cipher to add to TLS. Their choice — ChaCha20-Poly1305 — was included in Chrome 31 in November 2013, and Chrome for Android and iOS at the end of April 2014.
Having the option to choose a secure stream cipher in TLS is a good thing for mobile performance. Adding cipher diversity is also good insurance. If someone finds a flaw in one of the AES-based cipher suites sometime in the future, it gives a safe and fast option to fall back to.
Security
We previously spoke about the relative strength of different types of cryptography. Some keys are stronger than others, and when using new algorithms, the keys have to be chosen with the appropriate cryptographic strength. These new cipher suites are even more secure than the best standard choices.
The new cipher suites make use of two algorithms: ChaCha20, a stream cipher; and Poly1305, a code authenticator. Both of these cryptographic primitives were invented by Professor Dan Bernstein (djb) back in 2008 and 2005. They have been thoroughly vetted by academia and battle tested in Chrome for over a year.
From the IETF internet draft:
The ChaCha20 cipher is designed to provide 256-bit security.
The Poly1305 authenticator is designed to ensure that forged messages are rejected with a probability of 1-(n/(2^102)) for a 16n-byte message, even after sending 2^64 legitimate messages, so it is SUF-CMA in the terminology of [AE](http://cseweb.ucsd.edu/~mihir/papers/oem.html).In sum, the security level is more than sufficient for HTTPS. CloudFlare’s AES-GCM cipher provides around 128 bits of security, which is considered more than enough to future-proof communication. ChaCha20 goes far beyond that, providing 256 bits of security.
Poly1305 provides authentication, protecting TLS against attackers inserting fake messages into a secure stream. Poly1305’s key strength is considered strong enough to stop this attack, providing around 100 bits of security. Authentication in TLS is slightly less important than encryption because even if an attacker can add a fake message to the stream, they can’t read the information inside without breaking the encryption key.
ChaCha20-Poly1305 also uses the current recommended construction for combining encryption and authentication. It’s built using an Authenticated Encryption with Associated Data (AEAD) construction. AEAD is a way of combining a cipher and an authenticator together to get the combined properties of encryption and authentication. This would be done previously with two different algorithms, typically a block cipher and an HMAC. Authenticated encryption makes it impossible to decrypt a ciphertext out of order which helps rule out a whole class of problems including BEAST, Lucky 13 and POODLE. AEAD also makes the age-old discussion of MAC-then-encrypt vs encrypt-then-MAC obsolete by combining the two in the same operation. Our other preferred TLS 1.2 encryption algorithm, AES-GCM, is also an AEAD.
Performance
The new cipher suites are fast. As Adam Langley described, ChaCha20-Poly1305 is three times faster than AES-128-GCM on mobile devices. Spending less time on decryption means faster page rendering and better battery life. Although the cipher part of TLS may not be the biggest source of battery consumption (the handshake is more expensive (PDF)), spending fewer CPU cycles on encryption saves battery life, especially on large files.
For example: decrypting a 1MB file on the Galaxy Nexus (OMAP 4460 chip):
AES-128-GCM: 41.6ms
ChaCha20-Poly1305: 13.2msThe difference is more dramatic on less powerful Android phones and old iPhones running Chrome. There is also a comparable difference on pre-Sandy Bridge and low-powered Intel CPUs. With ChaCha/Poly, older computers and mobile devices spend less time and computational power on decryption.
On desktop computers with hardware AES support, AES-128-GCM is still the faster choice. CloudFlare is able to intelligently choose whether to choose AES or ChaCha/Poly for different clients based on the client’s advertised cipher preference. For recent Intel processors, we use the standard AES-GCM algorithm. For browsers on machines that do not have a hardware AES chip, we prefer the ChaCha20-Poly1305.
In order to support over a million HTTPS sites on our servers, we have to make sure CPU usage is low. To help improve performance we are using an open source assembly code version of ChaCha/Poly by CloudFlare engineer Vlad Krasnov and others that has been optimized for our servers’ Intel CPUs. This keeps the cost of encrypting data with this new cipher to a minimum.
Browser support and future directions
As of the most recent browser statistics, Chrome has over a third of the web browser market, making this change significant to a large number of users. Although ChaCha20-Poly1305 is a Chrome-only feature for now, it could gain even more widespread adoption soon. Mozilla is planning on adding support for ChaCha20-Poly1305 in Firefox, although this might take a while to complete. Apple also has a pending ticket tracking the implementation on iOS, although is unlikely to be completed since new 64-bit ARM processors (like the ones in iPhone 5s and later) have support for AES in hardware.
One thing to note is that the version of ChaCha/Poly implemented by both CloudFlare and Chrome is not the final version that will be standardized by the IETF. A more recent draft with slight modifications has been published and is on the road to standardization. We plan on adopting this new version of the cipher once it has been finalized.
Looking Ahead
ChaCha20-Poly1305 is a new cipher with a useful purpose: it improves performance for browsers in constrained environments. At the very least, it provides algorithm agility in case someone finds a serious flaw in AES-GCM, which is possible due to its fragility. In the future we plan to keep on adding the latest and best TLS features for our customers. You can track our configuration as it changes on Github.
If you want to enable ChaCha/Poly on your web server, we have included the patch for OpenSSL 1.0.2 here.