If you got to this second paragraph you probably heard that TLS today is very cheap to deploy. Considerable effort was put to optimize the cryptography stacks of OpenSSL and BoringSSL, as well as the hardware that runs them. However, aside for the occasional benchmark, that can tell us how many GB/s a given algorithm can encrypt, or how many signatures a certain elliptic curve can generate, I did not find much information about the cost of crypto in real world TLS deployments.

CC BY-SA 2.0 image by Michele M. F.

As Cloudflare is the largest provider of TLS on the planet, one would think we perform a lot of cryptography related tasks, and one would be absolutely correct. More than half of our external traffic is now TLS, as well as all of our internal traffic. Being in that position means that crypto performance is critical to our success, and as it happens, every now and then we like to profile our production servers, to identify and fix hot spots.

In this post I want to share the latest profiling results that relate to crypto.

The profiled server is located in our Frankfurt data center, and sports 2 Xeon Silver 4116 processors. Every geography has a slightly different use pattern of TLS. In Frankfurt 73% of the requests are TLS, and the negotiated cipher-suites break down like so:

Processing all of those different ciphersuites, BoringSSL consumes just 1.8% of the CPU time. That’s right, mere 1.8%. And that is not even pure cryptography, there is a considerable overhead involved too.

Let’s take a deeper dive, shall we?

If we break down the negotiated cipher suites, by the AEAD used, we get the following breakdown:

BoringSSL speed tells us that AES-128-GCM, ChaCha20-Poly1305 and AES-128-CBC-SHA1 can achieve encryption speeds of 3,733.3 MB/s, 1,486.9 MB/s and 387.0 MB/s, but this speed varies greatly as a function of the record size. Indeed we see that GCM uses proportionately less CPU time.

Still the CPU time consumed by encryption and decryption depends on typical record size, as well as the amount of data processed, both metrics we don’t currently log. We do know that ChaCha20-Poly1305 is usually used by older phones, where the connections are short lived to save power, while AES-CBC is used for … well your guess is as good as mine who still uses AES-CBC and for what, but good thing its usage keeps declining.

Finally keep in mind that 6.8% of BoringSSL usage in the graph translates into 6.8% x 1.8% = 0.12% of total CPU time.

Public key algorithms in TLS serve two functions.

The first function is as a key exchange algorithm, the prevalent algorithm here is ECDHE that uses the NIST P256 curve, the runner up is ECDHE using DJB’s x25519 curve. Finally there is a small fraction that still uses RSA for key exchange, the only key exchange algorithm currently used, that does not provide Forward Secrecy guarantees.

The second function is that of a signature used to sign the handshake parameters and thus authenticate the server to the client. As a signature RSA is very much alive, present in almost one quarter of the connections, the other three quarters using ECDSA.

BoringSSL speed reports that a single core on our server can perform 1,120 RSA2048 signatures/s, 120 RSA4096 signatures/s, 18,477 P256 ESDSA signatures/s, 9,394 P256 ECDHE operations/s and 9,278 x25519 ECDHE operations/s.

Looking at the CPU consumption, it is clear that RSA is very expensive. Roughly half the time BoringSSL performs an operation related to RSA. P256 consumes twice as much CPU time as x25519, but considering that it handles twice as much key-exchanges, while also being used as a signature, that is commendable.

If you want to make the internet a better place, please get an ECDSA signed certificate next time!

Only two hash function are currently used in TLS: SHA1 and SHA2 (including SHA384). SHA3 will probably debut with TLS1.3. Hash functions serve several purposes in TLS. First, they are used as part of the signature for both the certificate and the handshake, second they are used for key derivation, finally when using AES-CBC, SHA1 and SHA2 are used in HMAC to authenticate the records.

Here we see SHA1 consuming more resources than expected, but that is really because it is used as HMAC, whereas most cipher suites that negotiate SHA256 use AEADs. In terms of benchmarks BoringSSL speed reports 667.7 MB/s for SHA1, 309.0 MB/s for SHA256 and 436.0 MB/s for SHA512 (truncated to SHA384 in TLS, that is not visible in the graphs because its usage approaches 0%).

Using TLS is very cheap, even at the scale of Cloudflare. Modern crypto is very fast, with AES-GCM and P256 being great examples. RSA, once a staple of cryptography, that truly made SSL accessible to everyone, is now a dying dinosaur, replaced by faster and safer algorithms, still consumes a disproportionate amount of resources, but even that is easily manageable.

The future however is less clear. As we approach the era of Quantum computers it is clear that TLS must adapt sooner rather than later. We already support SIDH as a key exchange algorithm for some services, and there is a NIST competition in place, that will determine the most likely Post Quantum candidates for TLS adoption, but none of the candidates can outperform P256. I just hope that when I profile our edge two years from now, my conclusion won’t change to “Whoa, crypto is expensive!”.

Today we can safely confirm that this prediction is coming true, as for the first time ever the share of AES-CBC cipher suites on Cloudflare’s edge network dropped below that of ChaCha20-Poly1305 suites, and is fast approaching the 10% mark.

CC BY-SA 2.0 image by aesop

Over the course of the last six months, AES-CBC shed more than 33% of its “market” share, dropping from 20% to just 13.4%.

All of that share, went to AES-GCM, that currently encrypts over 71.2% of all connections. ChaCha20-Poly1305 is stable, with 15.3% of all connections opting for that cipher. Surprisingly 3DES is still around, with 0.1% of the connections.

The internal AES-CBC cipher suite breakdown as follows:

The majority of AES-CBC connections use ECDHE-RSA or RSA key exchange, and not ECDHE-ECDSA, which implies that we mostly deal with older clients.

In other good new, the use of ECDSA surpassed that of RSA at the beginning of the year. Currently more than 60% of all connections use the ECDSA signature.

Although 2048-bit RSA is not broken, it is generally considered less secure than 256-bit ECDSA, and is significantly slower to boot.

Last, but not least, 98.4% of all connections are PFS, using ECDHE for key exchange. That's up from 97.6% six months ago.

All in all we see the continuation of the positive trend on the web towards safer and faster cryptography. We believe this trend will continue with the finalization of TLS 1.3 later this year.

The encrypted Internet is about to become a whole lot snappier. When it comes to browsing, we’ve been driving around in a beat-up car from the 90s for a while. Little does anyone know, we’re all about to trade in our station wagons for a smoking new sports car. The reason for this speed boost is TLS 1.3, a new encryption protocol that improves both speed and security for Internet users everywhere. As of today, TLS 1.3 is available to all CloudFlare customers.

Many of the major web properties you visit are encrypted, which is indicated by the padlock icon and the presence of “https” instead of “http” in the address bar. The “s” stands for secure. When you connect to an HTTPS site, the communication between you and the website is encrypted, which makes browsing the web dramatically more secure, protecting your communication from prying eyes and the injection of malicious code. HTTPS is not only used by websites, it also secures the majority of APIs and mobile application backends.

The underlying technology that enables secure communication on the Internet is a protocol called Transport Layer Security (TLS). TLS is an evolution of Secure Sockets Layer (SSL), a protocol developed by Netscape in the 1990s. The Internet Engineering Task Force (IETF), a standards body, has been in charge of defining the protocol, which has gone through several iterations. The last version, TLS 1.2, was standardized in 2008 and is currently supported by the majority of browsers and HTTPS-enabled web services.

TLS 1.2 can be secure when configured correctly, but its age has begun to show. In the last few years, several high-profile attacks have been published that revealed flaws in the protocol. Eight years is a long time in computer security, so the IETF have been working on a new version of the protocol, TLS 1.3, which should be finalized by the end of 2016.

TLS 1.3 is a major overhaul and has two main advantages over previous versions:

• Enhanced security

• Improved speed

Most of the attacks on TLS from the last few years targeted vestigial pieces of the protocol left around from the 90s. TLS 1.2 is highly configurable, and vulnerable sites simply failed to disable the older features in hopes of being compatible with old browsers.

TLS 1.3 embraces the “less is more” philosophy, removing support for older broken forms of cryptography. That means you can’t turn on the potentially vulnerable stuff, even if you try. The list of TLS 1.2 features that have been removed is extensive, and most of the exiled features have been associated with high profile attacks. These include:

• RSA key transport — Doesn’t provide forward secrecy

• CBC mode ciphers — Responsible for BEAST, and Lucky 13

• RC4 stream cipher — Not secure for use in HTTPS

• SHA-1 hash function — Deprecated in favor of SHA-2

• Arbitrary Diffie-Hellman groups — CVE-2016-0701

• Export ciphers — Responsible for FREAK and LogJam

CC 2.0 Generic Aqua Mechanical

TLS 1.3 removes the “bad crypto smell” of these legacy features, making it less likely that attacks on previous versions of the protocol will affect TLS 1.3. This streamlining also makes TLS 1.3 much simpler to configure for server operators. A secondary side effect of the update is that the protocol can be made much faster, resulting in a better web browsing experience.

Fast page load times are critical to the success of web services. Amazon famously found that every additional 100ms of page load time decreases sales by 1%. A major component of page load time is latency: the time it takes to send data between the browser and the web server.

The impact of latency is especially noticeable for:a) users on mobile devicesb) users that geographically far away from the server

A message from Sydney to New York and back can take over 200ms, enough for humans to notice. Mobile browsing can also increase latency for a connection. Sending a message over a modern 4G mobile network routinely adds over 100ms of latency to requests. On 3G networks, which are still common in Europe, add over 200ms of additional latency. Even home WiFi connections and ISPs add dozens of milliseconds to requests. This additional latency can make mobile browsing feel slow. Unfortunately, encryption can make these slow connections seem slower. TLS 1.3 helps improve this situation.

To send a message to an encrypted site, you must first establish shared cryptographic keys. This process is called a cryptographic handshake. It requires special messages to be sent back and forth between the browser and the website. The TLS handshake happens behind the scenes whenever you connect to an encrypted site with your browser.

With TLS 1.2, two round-trips are needed to complete the handshake before the request can be sent. Accessing a site over a mobile network can add more than half a second to its load time. With TLS 1.3, the initial handshake is cut in half, requiring only one round-trip. That’s like going from a fast station wagon (0-60mph in 10 seconds) to a Tesla Model S (5 seconds).

If the round-trip time for a connection is around 100ms, the speed boost from TLS 1.3 is enough to take sites that seem “sluggish” (over 300ms), and turn them into sites that load comfortably fast (under 300ms).

The more efficient handshake is only possible because some of the legacy features present in TLS 1.2 were removed from the protocol. TLS 1.3 also has the additional advantage that for sites you’ve visited recently, you can send data on the first message to the server. This is called “zero round trip” mode (0-RTT) and will result in even faster load times. CloudFlare is planning to support TLS 1.3 0-RTT in the coming weeks.

TLS 1.3 is huge step forward for web security and performance. It’s available to all CloudFlare customers, and enabled by default for all Free and Pro customers. You will find the toggle to enable/disable TLS 1.3 in the Crypto tab of the CloudFlare dashboard.

The TLS 1.3 specification is still being polished, but the IETF is very close to settling on a final version of the protocol. Major browser vendors Firefox and Chrome have implemented preliminary versions of TLS 1.3 in their developer releases (Firefox Nightly and Chrome Canary), and we’re updating our implementation to match the current version in these browsers until the specification is final. Expect a faster, safer web browsing experience as more browsers enable TLS 1.3 by default in the coming months.

How to enable TLS 1.3 in your browser

Firefox Nightly

• Install and run Firefox nightly: https://nightly.mozilla.org/

• Enter "about:config" in the address bar

• Set security.tls.version.max from 3 to 4

• Restart the browser

Chrome Canary

• Install and run Chrome Canary: https://www.google.com/chrome/browser/canary.html

• Enter "chrome://flags/" in the address bar

• Go to "Maximum TLS version enabled." and select "TLS 1.3"

• Restart the browser

We’ll explore how hash collisions have been used to forge digital signatures in the past. We’ll also discuss how certificate authorities can make this significantly harder for attackers in the future by including randomness in certificate serial numbers.

The Internet relies on trust. Whether it’s logging in to your bank or reading Reddit, HTTPS protects you by encrypting the data you exchange with a site and authenticating the site's identity with a digital certificate. Browsers visually display the added security of HTTPS as a padlock in the address bar.

HTTPS can prove a site’s authenticity to a browser when a site owns a digital certificate that asserts the owner’s identity and hostname. Certificates are small files digitally signed by trusted third parties known as Certificate Authorities (CAs). For browsers, digital signatures are the definitive source of trust. If your browser trusts the CA and the digital signature on the certificate is correct, then the browser trusts the certificate. This system of identity is known as the public key infrastructure (PKI), something we’ve covered in detail in a previous post.

This system falls apart if digital signatures can no longer be trusted. If someone can create a certificate for cloudflare.com with a signature from a trusted CA, they can use it to impersonate the cloudflare.com website to visitors (given they can modify DNS).

A digital signature is a number cryptographically tied to a message with public key. Every digital signature requires a public-private key pair and a hash function. The hash function is used to take the message and replace it with a unique digest, the private key is used to sign, and the public key to verify signatures.

For example, to create an RSA signature, you take a hash of the message and encrypt that hash with your private key. Anyone can verify that signature both belongs to you and is valid for the associated message. Take the public key, decrypt the hash and compare it with the hash of the message. If it's a match, the signature is correct. ECDSA is a more recent algorithm that gets the same job done.

There are several ways of obtaining a digitally signed certificate for a website. The standard way is by purchasing a certificate from a certificate authority like GlobalSign or Comodo. CAs follow a set of rules about certificate issuance, governed by CA/Browser Forum’s Baseline Requirements.

Another way to get a certificate is to steal a CA’s private key. In addition to being potentially illegal, it is also very hard to do: CA private keys are usually kept in dedicated secure machines called Hardware Security Modules (HSM) designed to protect against key extraction.

A third more interesting way to obtain a certificate is to create a certificate that has the same hash as an existing trusted certificate. The signature from the trusted certificate can be added to the untrusted certificate, making it appear trusted.

If you can find a message that has the same hash value as a signed message, then you can swap in your message and the signature will verify correctly. This can be used to trick anyone into thinking someone signed a message that they didn’t.

Cryptographic hash functions are designed to resist this sort of thing. They don’t always succeed.

Cryptographic hash functions are designed to satisfy three security properties:

• collision resistance

• second pre-image resistance

• pre-image resistance

Collision resistance here means there are no known algorithms faster than brute force to find two values that hash to the same value. This is the strongest security requirement, and usually the first one to be broken.

A hash function has second pre-image resistance when, given a value and its hash, it is computationally infeasible to find a second value that hashes to the same value. On the surface, this would seem like the security property that protects digital signatures on certificates. However, as we’ll explore in the next section, it’s still possible to forge certificates signed with a second pre-image resistant hash.

Pre-image resistance means that given a hash, it’s computationally infeasible for an attacker to find a value that hashes to it. If you can find a pre-image, you can easily find a second pre-image or a collision.

In the next section, we’ll describe what happened the last time we used a cryptographic hash function without collision resistance for digital signatures.

MD5 is an incredibly popular cryptographic hash function; it also happens to be completely broken with respect to collision resistance. MD5 is still widely used, just not for digital signatures.

The first collision in MD5, discovered in 2004 by a group of Chinese researchers (PDF), used a lot of math and about an hour of computation by a supercomputer. Today, computing an MD5 collision takes only seconds on a laptop. This was cleverly demonstrated by Nat McHugh, who used a chosen-prefix hash collision (more on this later) in MD5 to create two images with the same hash—in this case Barry White and James Brown (he later created a three-way collision with Jack Black).

Three images with the same MD5 hash:

You can verify this yourself via curl and md5:

$ curl -s https://blog.cloudflare.com/content/images/2015/08/white.jpg | md5
b69dd1fd1254868b6e0bb8ed9fe7ecad
$ curl -s https://blog.cloudflare.com/content/images/2015/08/brown.jpg | md5
b69dd1fd1254868b6e0bb8ed9fe7ecad
$ curl -s https://blog.cloudflare.com/content/images/2015/08/black.jpg | md5
b69dd1fd1254868b6e0bb8ed9fe7ecad

Despite being relatively trivial to find an MD5 collision, it’s still not known how to perform a second-preimage attack on MD5. For example, given a digitally signed certificate, nobody has been able to create a second certificate with the same hash. Despite this, researchers created a certificate with the same signature as a certificate trusted by browsers.

The technique they used, a chosen-prefix attack, was originally proposed by Marc Stevens in his Master’s Thesis. It can be used to create a forged certificate as long as you can get a certificate authority to issue a certificate that starts with predictable values.

If you can find a collision, you can take two different values and append data to each so they hash to the same value. In the original MD5 collision attack, the researchers computed two messages M1 and M2 such that H(M1) = H(M2). Stevens extended this research to find a way to make two known values P1 and P2 collide by appending bytes. With prefixes P1 and P2, he was able to demonstrate how to find S1 and S2 so that H(P1|S1) = H(P2|S2).

This was enough to allow an attacker to create two certificates with the same hash. Let’s look at the approximate structure of a certificate:

• Serial number

• Validity period

• Domain name

• Public key

• X.509 extensions

• Signature

If the attacker knows every value before the domain, then they can take

P1 = Serial number | Validity period | real domain name

and

P2 = Serial number | Validity period | forged domain name

and apply the attack to get S1 and S2 that fit into the public key section. If the serial number and validity period can be predicted, a collision can be found using the following steps:

1. Guess when the certificate will be issued;

2. Predict the serial number for certificates issued in that time period; and

3. Compute matching prefixes for several guesses covering the expected serial numbers and issuance dates

The attacker precomputes chosen-prefix collisions for the choices for each of these values, where one prefix has a domain name that is under the requester’s control (e.g. for attacker.com) and one for the target domain (e.g. google.com). The "collision bits" that cause the two certificates to collide end up aligning with first few bytes of the public key of the certificate.

Once the collisions are computed, the attacker has to convince a CA to issue a certificate with the correct serial number at the correct time for a verifiable domain and a public key that corresponds to the collision bits. If they're lucky, the certificate the CA returns will have the same hash as the malicious certificate. They can then transpose the valid signature onto the malicious certificate to make it trusted.

Colliding the domain name is the simplest type of chosen-prefix collision attack. It is also possible to prepare the collision in such a way that the RSA public key from the trusted certificate lines up with the X.509 extensions of the forged certificate. This is much more dangerous since it allows the forged certificate to set the "Is CA" bit. As long as the path length constraint of the signing CA is large enough, this forged CA would be able to issue trusted certificates for any domain.

In 2008, several researchers (including Marc Stevens and Alex Sotirov) used chosen prefix collision techniques to forge a certificate authority trusted by browsers. This proof of concept was presented at the Chaos Communication Congress in 2008 and required only a few days of computation.

In 2012, a piece of malware called Flame was discovered. Flame was able infect computers by hijacking Microsoft’s Windows Update mechanism. At the time, Windows Update validated updates by checking code signatures using certificates signed by Microsoft using a MD5-based signature. The authors of Flame used a forged Microsoft certificate. According to an analysis of this certificate, it was likely the chosen-prefix technique was used to create Flame’s forged certificate.

Forbes declared this the most worrisome security discovery of 2012 since it demonstrated it was feasible for attackers to forge any website’s certificate using an MD5 hash collision when the client trusts MD5-signed certificates.

SHA-1 is supposedly more secure than MD5 for use in digital signatures. The National Security Agency published SHA-1 (SHA stands for Secure Hash Algorithm) in 1995 as a standard for cryptographically secure hashing. Designed to be collision resistant up to 2⁸⁰ bits, SHA-1 has had a long and useful life, and a collision has not been published as of this blog post. Even though a collision has never been published, several theoretical attacks (the first in 2005, improved in 2012) indicate that SHA-1 is not as secure as its bit length implies. The latest research suggests that its collision resistance is at best 265 — within the realm of feasibility for some governments. In fact, researchers published a freestart collision (a precursor to a full collision) for SHA-1 earlier this year.

CC BY-SA 2.0

Academic cryptanalysts are like sharks. If there's blood in the water, they swarm. It took nine years to get from the first published weakness in MD5 (1996) to a hash collision (2005), and then another three years to forge a trusted digital signature (2008). They might be slow, but they're relentless.

Attacks always improve and computers get more powerful. It was nine years from first weakness to hash collision in MD5; it's been ten years for SHA-1. If history is any guide, a public collision for SHA-1 could be published at any moment, with chosen-prefix collisions arriving soon after.

One way to improve the security of digital signatures against a chosen-prefix attack is to make the prefix less predictable.

As described above, the chosen prefix attack requires the attacker to predict both the serial number and the validity period. Certificates used on the web have serial numbers up to 160 bits long. Requiring CAs to make the serial number unpredictable instead of sequential, it is possible to make the chosen-prefix attack significantly more expensive.

For example, if a CA ensures the serial number contains 20 bits of entropy, then the attacker will need to compute 220 chosen-prefixes in order to guess the serial number correctly.

This makes the attack over a million times more difficult.

Computing a SHA-1 collision might be feasible in 2016, and there's a chance that chosen-prefix attacks also become feasible. Nevertheless, choosing partially randomized serial can make certificate forgery significantly more difficult for attackers. Barring a breakthrough in hash collision techniques, it's unlikely we'll see a certificate collision for long time.

The SHA-1 hash function, widely used for everything from file integrity to digital signatures, is at the end of its useful life. Some browsers even show security warnings when websites use certificates signed using a SHA-1 based digital signature. A hash collision in SHA-1 is bad, but it’s not what matters for web security. Digital signature forgery is more problematic for trust on the Web. Requiring CAs to randomize serial numbers will significantly increase the cost of such forgeries, allowing potentially weak algorithms like SHA-1 to be useful for longer. This is why we make it mandatory for CAs to use serial numbers that include at least 20 bits of entropy in our proposal to the CA/B Forum for Legacy Verified (LV) SHA-1 certificates.

Portal uses open-source software and services to take inexpensive, commodity travel routers and turn them into powerful security devices. Since this is pretty far from CloudFlare's core business, it warrants a brief digression into why we support projects like this.

Computer security was for a very long time only of interest to hobbyists, academics, and obscure government agencies. Cryptography was an interesting offshoot of number theory, a foundational but very abstract part of mathematics, and many of the early infrastructure components of the Internet didn't include security at all -- there was an assumption that anyone who could gain access would be responsible and well-intentioned, a consequence of the academic origins; after all, why would they want to break or steal things which were freely available.

Before the "cambrian explosion" of commercial computer security, there was still a lot of great security research -- it was just done by academics and by individuals in the "security community", who were motivated by a desire to understand how things worked, and to make tools because they loved the technology and wanted to solve their own problems. Some of the most interesting and powerful security tools available today trace their origins to rather humble open-source, hobbyist, or academic beginnings -- PGP, Tor, OTR, various forms of electronic cash, and many others. Many of today's most respected people in computer security entered the field during this period, out of personal curiosity or academic interest.

While CloudFlare is an eager participant in the commercial security world (we're the easiest and fastest way to set up TLS for any website, and we provide edge security and performance to millions of sites, including some of the largest sites on the Internet -- both with free service and paid services in various tiers), we are also very aware of the broad and deep foundation of security tools and research on which we're built.

CloudFlare makes extensive use of open source software, such as the Nginx web server, community collections of Web Application Firewall (WAF) rules originally generated by OWASP, and powerful cryptographic algorithms developed in academia and implemented by open source efforts such as the OpenSSL Project.

Where possible, CloudFlare also contributes back to the community in those areas. We contribute bugfixes and new functionality back to open source packages, and we employ developers who in their spare time make additional contributions to open source software. CloudFlare's GitHub Open Source page is a great collection of many of our contributions to open source.

One of our biggest contributions to date has been CFSSL, CloudFlare's PKI toolkit. We're constantly hearing from various projects and companies how CFSSL has been helpful to them -- one of the most exciting being the Let's Encrypt community Certificate Authority project. Nick Sullivan has written in the CloudFlare blog announcing CFSSL, and exciting things are continuing to happen with that software.

CloudFlare, like many other companies in computer security, makes other contributions to the security community. One of the most interesting is that we, like some other companies, values having employees participate in the security community in a variety of ways. Encouraging side projects independent of work -- research, finding new vulnerabilities and responsibly disclosing them, creating new tools, participating in conferences or working groups, running tutorials, and being active in standards bodies -- sometimes doesn't have a direct connection to the company's products, but contributes to a vibrant security ecosystem. There are often unforeseen benefits of these collaborations -- learning about new tools, finding great engineers -- we're actively hiring for a variety of roles -- and many others.

Marc and I are grateful to CloudFlare for the time to work on this open source tool and to present it to the world, and we're looking forward to presenting at RSA.

During Thursday's webcast, Nick will discuss ways that ensure your server's software stays secure. In today's world, you may not know if the hardware you are running software on is secure or not. So, how can you ensure that, regardless of the hardware security, the software stays protected? Nick will discuss advanced techniques on how to protect your server software. These techniques include anti-reverse engineering methods, secure key management and designing a system for renewal.

To learn more about various ways to secure your server's software, join us at the upcoming webcast on Thursday, March 20th, 2014 at 11AM PDT (2PM EDT). If you have questions you want Nick to address, leave them in the comments below. Register here.

This blog post is dedicated to the memory of Dr. Scott Vanstone, popularizer of elliptic curve cryptography and inventor of the ECDSA algorithm. He passed away on March 2, 2014.

At CloudFlare we are constantly working on ways to make the Internet better. An important part of this is enabling our customers to serve their sites encrypted over SSL/TLS. There are some interesting technical challenges in serving sites over TLS at CloudFlare’s scale. The computational cost of the cryptography required on our servers is one of those challenges. Elliptic curve cryptography (ECC) is one of the more promising technologies in this area. ECC-enabled TLS is faster and more scalable on our servers and provides the same or better security than the default cryptography in use on the web.

In this blog post we will explore how one elliptic curve algorithm, the elliptic curve digital signature algorithm (ECDSA), can be used to improve performance on the Internet. The tl;dr is: CloudFlare now supports custom ECDSA certificates for our customers and that’s good for everybody using the Internet.

When you visit a site that starts with https:// instead of http://, your browser connects to that site over an encrypted connection. The browser also validates that the site is who it claims to be using public key cryptography and a digital certificate.

In public key cryptography each person has a pair of keys: a public key and a private key. These are typically numbers that are chosen to have a specific mathematical relationship. In RSA, the public key is a large number that is a product of two primes, plus a smaller number. The private key is a related number. In ECC, the public key is an equation for an elliptic curve and a point that lies on that curve. The private key is a number. See our previous blog post on elliptic curve cryptography for more details.

The private key can be used to create a digital signature for any piece of data using a digital signature algorithm. This typically involves taking a cryptographic hash of the data and operating on it mathematically using the private key. Anyone with the public key can check that this signature was created using the private key and the appropriate signature validation algorithm. A digital signature is a powerful tool because it allows you to publicly vouch for any message.

A website certificate usually contains two things:

• Identity information: Typically who owns the certificate and which domains the certificate is valid for.

• A public key: The public half of a key pair, the site owner controls and keeps secret the associated private key.

The certificate is digitally signed by a trusted certificate authority who validates the identity of the site owner.

Since the introduction of SSL by Netscape in 1994, certificates for web sites have typically used a public/private key pair based on the RSA algorithm. As the SSL specification evolved into TLS, support for different public key algorithms were added. One of the supported algorithms is ECDSA which is based on elliptic curves.

Despite the number of options available in TLS, almost all certificates used on the web today are RSA-based. Web sites have been slow to adopt new algorithms because they want to maintain support for legacy browsers that don’t support the new algorithms. Even as late as 2012, out of 13 million TLS certificates found in a scan of the internet, fewer than 50 use an ECDSA key pair.

Although ECDSA has not taken off on the web, it has become the digital signature scheme of choice for new cryptographic non-web applications.

Bitcoin is a good example of a system that relies on ECDSA for security. Every Bitcoin address is a cryptographic hash of an ECDSA public key. The ownership of the account is determined by who controls the ECDSA private key. To transfer an amount of Bitcoin to another person, you create a message that says something along the lines of “I give this Bitcoin to address X”, sign it with your private key and submit it to the Bitcoin system. The linchpin of the security and consistency of the Bitcoin system is the security of ECDSA private keys.

Elliptic curves and ECDSA in particular are also used in messaging and systems security. In Apple’s recent white paper on iOS security, they relayed how they use ECDSA extensively in the Apple ecosystem. Messages through iMessage are signed with ECDSA and iCloud keychain syncing relies on ECDSA. More and more technologies are using ECDSA for security, including end-to-end encrypted messaging services TextSecure and CryptoCat.

Why is ECDSA the algorithm of choice for new protocols when RSA is available and has been the gold standard for asymmetric cryptography since 1977? It boils down to the fact that we are better at breaking RSA than we are at breaking ECC.

As we described in a previous blog post, the security of a key depends on its size and its algorithm. Some algorithms are easier to break than others and require larger keys for the same level of security. Breaking an RSA key requires you to factor a large number. We are pretty good at factoring large numbers and getting better all the time. Breaking an ECDSA key requires you to solve the Elliptic Curve Discrete Logarithm Problem (ECDLP). The mathematical community has not made any major progress in improving algorithms to solve this problem since is was independently introduced by Koblitz and Miller in 1985.

This means that with ECDSA you can get the same level of security as RSA but with smaller keys. Smaller keys are better than larger keys for several reasons. Smaller keys have faster algorithms for generating signatures because the math involves smaller numbers. Smaller public keys mean smaller certificates and less data to pass around to establish a TLS connection. This means quicker connections and faster loading times on websites.

According to the ECRYPT II recommendations on key length, a 256-bit elliptic curve key provides as much protection as a 3,248-bit asymmetric key. Typical RSA keys in website certificates are 2048-bits. If we compare the portion of the TLS handshake that happens on the server for 256-bit ECDSA keys against the cryptographically much weaker 2048-bit RSA keys we get the following:

                        sign/s

256 bit ecdsa (nistp256) 9516.8 rsa 2048 bits 1001.8

(openssl 1.0.2 beta on x86_64 with enable-ec_nistp_64_gcc_128)

That table shows the number of ECDSA and RSA signatures possible per second. On our servers, using an ECDSA certificate reduces the cost of the private key operation by a factor of 9.5x, saving a lot of CPU cycles.

I mentioned earlier that fewer than fifty ECDSA certificate are being used on the web. You can now count https://blog.cloudflare.com among them. If you don't see a lock icon, click here for the HTTPS version of the site. Once you are viewing this site over HTTPS, take a look at the TLS information bar (click on the lock icon in your address bar). You should see the key exchange mechanism listed as ECDHE_ECDSA, which means the certificate is using ECDSA. If the HTTPS version site does not load, your browser probably does not support ECDSA.

This is an image taken from the Chrome browser under the green lock icon for this page under the connection tab:

This blog post is our first experiment using an SSL certificate based on elliptic curves. Our blog is being served by the standard CloudFlare service (yes, we eat our own dog food), and is the first site on CloudFlare that uses an ECDSA certificate. We are happy to annouce that we now support custom ECDSA certificates for all CloudFlare business customers.

In the near future we will enable code that will allow sites to have a fallback certificate so that visitors with old browsers without ECDSA support can still view their site over HTTPS. Because ECDSA is so much more efficient for our servers, supporting these certificates is an essential step for enabling SSL for free in 2014.

We can be relatively confident about the mathematical security of ECDSA (save for some questions about the choice of curve). The history of cryptography shows us that good cryptography has been repeatedly defeated not because of bad math, but because of bad implementations of good math.

One interesting quirk of the ECDSA algorithm is that every signature requires some random or unpredictable data as input. If the source of randomness is predictable to an attacker, then they can figure out the private key. Hackers have exploited this vulnerability in several high-profile incidents.

In 2010, a flaw in the way random numbers were used in ECDSA on Sony’s Playstation 3 resulted in a private key being leaked. More recently, some Android devices were found to be incorrectly generating random values, resulting in a massive theft of Bitcoins from devices running Bitcoin software.

There are other more esoteric attacks against specific ECDSA implementations. Last week, a paper was published by researchers from Australia and the UK describing an attack on OpenSSL’s implementation of ECDSA for curve secp256k1 (the one used by the Bitcoin protocol). Luckily, this attack is not a threat against busy remote servers.

The danger of key leakage via poor random data or side channel attacks is a concern but is manageable with proper preparation. At CloudFlare we ensure that the system random number generator has enough entropy. Even if there is a problem with the system PRNG, OpenSSL 1.0.2 has included a fix to reduce the chance of compromise. Cryptography is hard to implement correctly, especially in the context of a complex protocol like TLS as evidenced in some famous recent bug fixes. That said, the benefits seem to outweigh the risks in this case.

On a personal note, Dr. Vanstone was one of my professors at the University of Waterloo. He was passionate about mathematics and cryptography and he was one of the reasons I decided to pursue security engineering as a career. The book he co-authored, The Handbook of Applied Cryptography, is still one of the classics in the field.

From his memorial page at the Waterloo Daily Bulletin: "I had studied it enough to believe in it," Vanstone told Silicon Valley North in 2003. "It was the rest of the world that didn't believe in it." He will be missed.

Elliptic curve cryptography is a powerful technology that can enable faster and more secure cryptography across the Internet. The time has come for ECDSA to be widely deployed on the web, just as Dr. Vanstone hoped. We are taking the first steps towards that goal by enabling customers to use ECDSA certificates on their CloudFlare-enabled sites.

At CloudFlare, we are always looking for better ways to secure the data we’re entrusted with. This means hardening our system against outside threats such as hackers, but it also means protecting against insider threats. According to a recent Verizon report, insider threats account for around 14% of data breaches in 2013. While we perform background checks and carefully screen team members, we also implement technical barriers to protect the data with which we are entrusted.

One good information security practice is known as the “two-man rule.” It comes from military history, where a nuclear missile couldn’t be launched unless two people agreed and turned their launch keys simultaneously. This requirement was introduced in order to prevent one individual from accidentally (or intentionally) starting World War III.

To prevent the risk of rogue employees misusing sensitive data we built a service in Go to enforce the two-person rule. We call the service Red October after the famous scene from “The Hunt for Red October.” In line with our philosophy on security software, we are open sourcing the technology so you can use it in your own organization (here’s a link to the public Github repo). If you are interested in the nitty-gritty details, read on.

Red October is a cryptographically-secure implementation of the two-person rule to protect sensitive data. From a technical perspective, Red October is a software-based encryption and decryption server. The server can be used to encrypt a payload in such a way that no one individual can decrypt it. The encryption of the payload is cryptographically tied to the credentials of the authorized users.

Authorized persons can delegate their credentials to the server for a period of time. The server can decrypt any previously-encrypted payloads as long as the appropriate number of people have delegated their credentials to the server.

This architecture allows Red October to act as a convenient decryption service. Other systems, including CloudFlare’s build system, can use it for decryption and users can delegate their credentials to the server via a simple web interface. All communication with Red October is encrypted with TLS, ensuring that passwords are not sent in the clear.

Setting up a Red October server is simple; all it requires is a locally-readable path and an SSL key pair. After that, all control is handled remotely through a set of JSON-based APIs.

Red October is backed by a database of accounts stored on disk in a portable password vault. The server never stores the account password there, only a salted hash of the password for each account. For each user, the server creates an RSA key pair and encrypts the private key with a key derived from the password and a randomly generated salt using a secure derivation function.

Any administrator can encrypt any piece of data with the encrypt API. This request takes a list of users and the minimum number of users needed to decrypt it. The server returns a somewhat larger piece of data that contains an encrypted version of this data. The encrypted data can then be stored elsewhere.

This data can later be decrypted with the decrypt API, but only if enough people have delegated their credentials to the server. The delegation API lets a user grant permission to a server to use their credentials for a limited amount of time and a limited number of uses.

Red October was designed from cryptographic first principles, combining trusted and understood algorithms in known ways. CloudFlare is also opening the source of the server to allow others to analyze its design.

Red October is based on combinatorial techniques and trusted cryptographic primitives. We investigated using complicated secret primitives like Shamir's sharing scheme, but we found that a simpler combinatorial approach based on primitives from Go's standard library was preferable to implementing a mathematical algorithm from scratch. Red October uses 128-bit AES, 2048-bit RSA and scrypt as its cryptographic primitives.

Each user is assigned a unique, randomly-generated RSA key pair when creating an account on a Red October server. The private key is encrypted with a password key derived from the user’s password and salt using scrypt. The public key is stored unencrypted in the vault with the encrypted private key.

When asked to encrypt a piece of data, the server generates a random 128-bit AES key. This key is used to encrypt the data. For each user that is allowed to decrypt the data, a user-specific key encryption key is chosen. For each unique pair of users, the data key is doubly encrypted, once with the key encryption key of each user. The key encryption keys are then encrypted with the public RSA key associated with their account. The encrypted data, the set of doubly-encrypted data keys, and the RSA-encrypted key encryption keys are all bundled together and returned. The encrypted data is never stored on the server.

Delegating credentials to the server

When a user delegates their key to the server, they submit their username and password over TLS using the delegate JSON API. For each account, the password is verified against the salted hash. If the password is correct, a password key is derived from the password and used to decrypt the user’s RSA private key. This key is now “Live” for the length of time and number of decryptions chosen by the user.

Decrypting data

To decrypt a file, the server validates that the requesting user is an administrator and has the correct password. If two users of the list of valid users have delegated their keys, then decryption can occur. First the RSA private key is used to decrypt the key encryption key for these two users, then the key encryption keys are used to decrypt the doubly encrypted data key, which is then used to decrypt the data.

Some other key points:

1. Cryptographic security. The Red October server does not have the ability to decrypt user keys without their password. This prevents someone with access to the vault from decrypting data.

2. Password flexibility. Passwords can be changed without changing the encryption of a given file. Key encryption keys ensure that password changes are decoupled from data encryption keys.

The version of Red October we are releasing to GitHub is in beta. It is licensed under the 3-clause BSD license. We plan to continue to release our improvements to the open source community. Here is the project on GitHub: Red October.

Writing the server in Go allowed us to design the different components of this server in a modular way. Our hope is this modularity will make it easy for anyone to build in support for different authentication methods that are not based on passwords (for example, TLS client certificates, time-based one-time-passwords) and new core cryptographic primitives (for example, elliptic curve cryptography).

CloudFlare is always looking to improve the state of security on the Internet. It is important to us to share our advances with the world and contribute back to the community. See the CloudFlare GitHub page for the list of our open source projects and initiatives.

If you're not familiar with the cryptographic protocols involved you might be wondering why one part uses a 128-bit key and another a 2,048-bit key. And you'd be forgiven for wondering why a large key wasn't used throughout and whether a 128-bit key is weaker than a 2,048-bit key. This blog post will explain why a 128-bit symmetric key is, in fact, a bit more secure than a 2,048-bit asymmetric key; you have to look at both the type of encryption being used (symmetric or asymmetric) and the key length to understand the strength of the encryption.

My connection above used a symmetric cipher (RC4_128) with a 128-bitkey and an asymmetric cipher (ECDHE_RSA) with a 2,048-bit key.

You might also have seen other key lengths in use. For example, when I connect to the British Government portal gov.uk I get a TLS connection that uses AES_256_CBC (with a 256-bit key) set up using RSA with a 2,048-bit key. It's not uncommon to see RSA with a 1,024-bit key as well.

To understand these key lengths it's necessary to understand a little about the actual encryption schemes they are used with.

The RC4_128 and AES_256_CBC schemes mentioned above are symmetric cryptographic schemes. Symmetric simply means that the same key is used to encipher and decipher the encrypted web traffic. In one case, a 128-bit key is used, in another a 256-bit key.

Symmetric cryptography is the oldest form there is. When children use a Caesar Cipher (shifting each letter in the alphabet some fixed number of places) they are performing symmetric cryptography. In that case, the key is the number of places to shift letters and there are 26 possible keys (which is roughly like saying the Caesar Cipher has a roughly 5-bit key).

Here's a Caesar Shift with a key of 7 (each letter is moved up in the alphabet 7 places):

ISTHE BESTT HATCO RPORA LBOBB YSHAF TOECA NDOON SHORT NOTIC E PZAOL ILZAA OHAJV YWVYH SIVII FZOHM AVLJH UKVVU ZOVYA UVAPJ L

There are lots of ways to break the Caesar Cipher, but one way is to try out all 26 possible keys. That's really not that hard since there are only 26 possible solutions:

PZAOL ILZAA OHAJV YWVYH SIVII FZOHM AVLJH UKVVU ZOVYA UVAPJ L
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -

0: PZAOL ILZAA OHAJV YWVYH SIVII FZOHM AVLJH UKVVU ZOVYA UVAPJ L 1: OYZNK HKYZZ NGZIU XVUXG RHUHH EYNGL ZUKIG TJUUT YNUXZ TUZOI K 2: NXYMJ GJXYY MFYHT WUTWF QGTGG DXMFK YTJHF SITTS XMTWY STYNH J 3: MWXLI FIWXX LEXGS VTSVE PFSFF CWLEJ XSIGE RHSSR WLSVX RSXMG I 4: LVWKH EHVWW KDWFR USRUD OEREE BVKDI WRHFD QGRRQ VKRUW QRWLF H 5: KUVJG DGUVV JCVEQ TRQTC NDQDD AUJCH VQGEC PFQQP UJQTV PQVKE G 6: JTUIF CFTUU IBUDP SQPSB MCPCC ZTIBG UPFDB OEPPO TIPSU OPUJD F 7: ISTHE BESTT HATCO RPORA LBOBB YSHAF TOECA NDOON SHORT NOTIC E 8: HRSGD ADRSS GZSBN QONQZ KANAA XRGZE SNDBZ MCNNM RGNQS MNSHB D 9: GQRFC ZCQRR FYRAM PNMPY JZMZZ WQFYD RMCAY LBMML QFMPR LMRGA C 10: FPQEB YBPQQ EXQZL OMLOX IYLYY VPEXC QLBZX KALLK PELOQ KLQFZ B 11: EOPDA XAOPP DWPYK NLKNW HXKXX UODWB PKAYW JZKKJ ODKNP JKPEY A 12: DNOCZ WZNOO CVOXJ MKJMV GWJWW TNCVA OJZXV IYJJI NCJMO IJODX Z 13: CMNBY VYMNN BUNWI LJILU FVIVV SMBUZ NIYWU HXIIH MBILN HINCW Y 14: BLMAX UXLMM ATMVH KIHKT EUHUU RLATY MHXVT GWHHG LAHKM GHMBV X 15: AKLZW TWKLL ZSLUG JHGJS DTGTT QKZSX LGWUS FVGGF KZGJL FGLAU W 16: ZJKYV SVJKK YRKTF IGFIR CSFSS PJYRW KFVTR EUFFE JYFIK EFKZT V 17: YIJXU RUIJJ XQJSE HFEHQ BRERR OIXQV JEUSQ DTEED IXEHJ DEJYS U 18: XHIWT QTHII WPIRD GEDGP AQDQQ NHWPU IDTRP CSDDC HWDGI CDIXR T 19: WGHVS PSGHH VOHQC FDCFO ZPCPP MGVOT HCSQO BRCCB GVCFH BCHWQ S 20: VFGUR ORFGG UNGPB ECBEN YOBOO LFUNS GBRPN AQBBA FUBEG ABGVP R 21: UEFTQ NQEFF TMFOA DBADM XNANN KETMR FAQOM ZPAAZ ETADF ZAFUO Q 22: TDESP MPDEE SLENZ CAZCL WMZMM JDSLQ EZPNL YOZZY DSZCE YZETN P 23: SCDRO LOCDD RKDMY BZYBK VLYLL ICRKP DYOMK XNYYX CRYBD XYDSM O 24: RBCQN KNBCC QJCLX AYXAJ UKXKK HBQJO CXNLJ WMXXW BQXAC WXCRL N 25: QABPM JMABB PIBKW ZXWZI TJWJJ GAPIN BWMKI VLWWV APWZB VWBQK M

The goal of modern symmetric cryptography is to make this sort of'trying out all the possible keys' the only approach to breaking a symmetric cipher. Algorithms like RC4 and AES scramble data based on a key. The key itself is, ideally, randomly chosen from the set of all possible keys.

On a side note, there are now serious problems with RC4 and as better replacements come along (such as ciphersuites based on AES) CloudFlare will update the ciphersuites it uses to provide the best level of protection.

That said the basic idea is that the only way to break into a connection secured with a symmetric cipher is to try out all the keys. Which brings us to 128-bit and 256-bit keys.

A 128-bit key means there are 340,282,366,920,938,463,463,374,607,431,768,211,456 possible keys to try. A 256-bit key has the square of that many keys to try: a hugenumber.

To put that in context imagine trying to test all the keys for a 128-bit AES encryption using the special AES instructions added to the latest Intel microprocessors. These instructions are designed to be very fast and according to Intel's own data decrypting a block of AES encrypted data would take 5.6 cycles on Intel i7 Processor with 4 cores.

Put another way, that processor could try out one key on one block of data in about 1.7 nanoseconds. At that speed it would take it about 1.3 * 10^12 * the age of the universe to check all the keys (you'd probably only have to check half before finding the right one so divide that incredibly long time by two).

Since personal computers became available roughly 1 billion of them have been sold. Imagine that they all had the same top-of-the-line processor and were used to attack a 128-bit key. You'd manage to get the time down to 660 * the age of the universe.

Image (c) BBC TV

So, breaking 128-bit keys by brute force just isn't practical. And breaking 256-bit is even less possible. So, for symmetric ciphers, keys of these lengths make sense.

But that's not the case for asymmetric cryptography.

Asymmetric cryptography works by having two different keys, one for encryption and one for decryption. It's also often called 'public key cryptography' because it's possible to make one key public (allowing someone to encrypt a message) while keeping the other private (only the holder of the private key can decrypt the message encrypted with its related public key).

In order to have these special properties the public and private keys are related by some mathematical process. Aside: in the symmetric examples there's only one key and it's just any value of the right number of bits. This randomness of a symmetric key means it can be relatively short as we saw.

For example, in the popular RSA scheme used with SSL/TLS the public and private keys consist in part of the product of two large prime numbers. Making an RSA key starts with picking two random prime numbers. The security of RSA relies (in part) on the fact that it's easy to choose two random prime numbers, but it's very hard to discover what they are when just given the product of them.

Suppose there are two prime numbers picked at random called p0 and p1. Part of the RSA public (and private) key is called the modulus and it is just p0*p1. If an attacker can decompose (or factor) the modulus into p0 and p1 they can break RSA because they can work out the private key. Mathematicians believe that it is very hard to factor a product of two primes and the security of web transactions relies, in part, on that belief.

Typical RSA key sizes are 1,024 or 2,048 or 4,096 bits. That number is the number of bits in the modulus. For each there will be a pair of primes of roughly 512 bits or 1,024 bits or 2,048 bits depending on the key size picked. Those primes are chosen by some random process (highlighting once again the importance of random number generators).

But we still haven't answered the question of why these key sizes are so large. Just as in the symmetric key case, attacks on say 2,048-bit RSA are based on trying out all keys of a certain size, but unlike the symmetric key scheme not every 2,048-bit number is an RSA key (because it has to be the product of two primes).

So, although the key size is larger there are actually fewer possible RSA keys for any given number of bits that there are for the same symmetric key size. That's because there are only so many prime numbers of that size and below. The RSA scheme can only use pairs of prime numbers, whereas the symmetric schemes can use any number at all of the same size.

This diagram (called an Ulam Spiral) shows the numbers from 1 to 40,000 as black or white dots. The black dots are the primes

Image from Wikipedia

If you used a 256-bit RSA key (roughly consisting of two 128-bit prime numbers multiplied together) you'd quickly find that your encryption had been broken by someone using a fast home PC. There are only so many 128-bit prime numbers and there are fast ways of attacking the factorization problem (such as the General Number Field Sieve that actually make breaking RSA keys a little easier than trying out every single key).

Any time there's a pattern in a cryptographic key it represents a chink in the crytography's armor. For example, in a perfect world, people would pick completely random passwords. Because they don't there are patterns in the passwords and they can be guessed or broken without trying out every possible password.

RSA keys have a distinctive pattern: they are the product of two prime numbers. That provides the chink; today that chink is best exploited by the General Number Field Sieve. In the symmetric key case there are no such patterns: the keys are just large randomly-chosen numbers. (Of course, if you don't pick your symmetric key randomly you might actually be helping an attacker find a way to break your encrypted messages.)

A few years ago the 512-bit RSA key used to sign software for TIcalculators was broken by an individual using a PC that ran for 73 days using the open source msieve and ggnfs prorgrams.

So, asymmetric keys have to be much larger than symmetric keys because there are less of them for a given number of bits, and because there are patterns within the keys themselves.

The ECRYPT II recommendations on key length say that a 128-bit symmetric key provides the same strength of protection as a 3,248-bit asymmetric key. And that those key lengths provide long term protection of data encrypted with them.

The length of time a key is good for is also important. Over time computers get faster and techniques for breaking encryption schemes (particuarly techniques for breaking asymmetric encryption) get better. That 512-bit key used for TI calculators probably looked pretty safe when it was first chosen. And in 1999 a key of that length took a supercomputer to break.

We keep an eye on these reports when choosing ciphers and key lengths to secure our and our customers' communications.

Because of the importance of protecting our customers' communications CloudFlare has also opted to roll out forward secrecy for our SSL/TLS connections. That means that the public/private keys used for connections are generated freshly each time. That prevents bulk attacks where a single public/private key (such as the one used in simple RSA-based certificates) is broken revealing all of the symmetric keys used to secure HTTPS for a web site.

Returning to the HTTPS connection I made to CloudFlare at the start, the key negotiation was done using ECDHE_RSA. That's the ephemeral version of the Diffie-Hellman key exchange mechanism that uses elliptic curves and RSA for authentication. That's quite amouthful. It breaks down like this:

1. The public/private key pair used to this connection was ephemeral: it was only created for this connection. That's what gives 'forward secrecy'.

2. The actual public-key encryption scheme used was Elliptic Curve Diffie-Hellman. Elliptic Curve Cryptography uses a different branch of mathematics than RSA. Looking at the ECRYPT II report shows that a 128-bit symmetric key is as strong as a 3,248-bit asymmetric key; to get the equivalent strength from an Elliptic Curve Cryptographic scheme requires a key with 256-bits.

3. So, Google Chrome set up an ephemeral 256-bit Elliptic Curve Diffie Hellman public/private key pair and used it to agree on a 128-bit symmetric key for the rest of the communication.

4. To prove that the web site really was www.cloudflare.com the 2,048-bit RSA key was used along with the web site's certificate.

So, three different key lengths were used: 128-bit (with RC4), 256-bit (with ECDHE) and 2,048-bit (with RSA). All three key lengths provide similar levels of security.