Content delivery network and Web security company Cloudflare has made a name for itself by fending off denial-of-service attacks against its customers large and small. Today, it's launching a new service aimed at winning over the most paranoid of corporate customers. The service is a first step toward doing for network security what Amazon Web Services and other public cloud services have done for application services—replacing on-premises hardware with virtualized services spread across the Internet.
Called Keyless SSL, the new service allows organizations to use Cloudflare’s network of 28 data centers around the world to defend against distributed denial of service attacks on their websites without having to turn over private encryption keys. Keyless SSL breaks the encryption “handshake” at the beginning of a Transport Layer Security (TLS) Web session, passing part of the data back to the organization’s data center for encryption. It then negotiates the session with the returned data and acts as a gateway for authenticated sessions—while still being able to screen out malicious traffic such as denial of service attacks.
In an interview with Ars, Cloudflare CEO Matthew Prince said that the technology behind Keyless SSL could help security-minded organizations embrace other cloud services while keeping a tighter rein on them. “If you decide you’re going to use cloud services today, how you set policy across all of these is impossible," he said. "Now that we can do this, fast forward a year, and we can do things like data loss prevention, intrusion detection… all these things are just bytes in the stream, and we’re already looking at them.”
All of that puts Cloudflare on a path to, as Prince put it, do to Cisco and other network hardware suppliers what AWS and other cloud services have done to Hewlett-Packard and Dell-type server vendors. The technology could also help extend Internet services to areas of the world that lack the sort of trustworthy data centers that Cloudflare and other cloud providers operate from, as it keeps their most precious secrets locked away back at the core of their networks.
Changing the locks
The development of Keyless SSL began about two years ago, on the heels of a series of massive denial of service attacks against major financial institutions alleged to have been launched from Iran. “We got a series of fairly frantic calls from those banks saying they needed help with this problem,” Prince said. “We met with JP Morgan Chase, Goldman Sachs… pretty much everyone in that community. They described to us a challenge that put them between a rock and a hard place. They had spent billions on hardware in data center to control access to their network. But it didn’t matter—no matter how intelligent the boxes they bought were, they were falling over because the attacks were so large. There was no way spending more money on premium equipment could solve it.”
At the same time, the banks weren’t able to use existing content delivery networks and other cloud technology to protect themselves either because of the regulatory environment. “They said, ‘We can’t trust our SSL keys with a third party, because if they lose one of those keys, it’s an event we have to report to the Federal Reserve,’” Prince said. “Somebody has to explain to (JP Morgan Chase CEO) Jamie Dimon what an SSL key is, and then he has to call the Fed. It’s a [chief information security officer]’s worst nightmare.”
Prince and his team had nothing to offer the banks at the time. “These guys need us, but there’s no vault we can ever build that they’ll trust us with their SSL keys,” he said. So Cloudflare system engineers Piotr Sikora and Nick Sullivan started working on ways to allow the banks to hold onto their private keys. The answer was to change what happens with the SSL handshake itself.
“In a handshake, what happens is that a client connects to the server, starting with a ‘hello’ message,” Sullivan told Ars. “The message lists which version of TLS and which cipher suites it supports on the client. The server has a list, and it picks the most favorable one. With that, it sends the site’s public certificate to the client.” The hello messages from server and client also include an exchange of numbers—4-byte numbers that are based on the system time of client and server and 28-byte randomly generated numbers, all combined into a 32-byte number—and a session ID number.
The next step is where Cloudflare’s changes to the handshake start to take hold. At this point, the client Web browser sends a “Pre-Master Secret”—a combination of the two shared random numbers encrypted using the server’s public key. Normally, the Web server would use the two exchanged numbers and encrypt them using the server’s private key and the client’s public key. The server and the client both use the exchanged numbers to create a shared secret—a Master Secret—to generate session encryption keys. For Internet Explorer and Safari, the session associated with these keys is identified by a relatively short-lived session ID. The Chrome and Firefox browsers, however, support a “session ticket”—a token that can be stored on both ends to identify a session for a faster re-negotiation of secure connections if they’re interrupted.
Normally, this would mean the server establishing the session would have to have access to the organization’s private key. But in Cloudflare’s “keyless” system, the numbers are passed back to an application sitting in the data center of the organization that owns the site over a virtual private network connection for decryption. The client, Cloudflare's service, and the backend server all then have the same session key.
Once that’s complete, the Cloudflare data center is able to manage the session with the client, caching the session key and using it to encrypt cached, static content from the organization's website back to the client. Requests for dynamic data are passed through to the back-end servers on the organization's server, and responses are passed through (encrypted) to the client Web browser.
Cloudflare’s data centers can spread out requests for a single session across all the servers in each data center through Cloudflare’s key store, an in-memory database of hashed session IDs and tickets. For connections that use session tickets, the information on sessions can be spread wider. “The special thing that we did is that the session ticket key is shared between all the servers,” Sikora told Ars. Session tickets, which are less than 1 kilobyte in size, are replicated across all of Cloudflare’s data centers using a replication service called Kyoto Tycoon—allowing a session to be picked up again by a client hours or days after disconnecting from any location (based, of course, on what the organization’s authentication policies are). “We cache up to four days of master secrets,” Sikora said. “That’s 96 hours for some clients who want some longer caching of sessions.”
Up and running
Prince said that Cloudflare already has a “handful of beta customers, which include some of the top 10 financial institutions,” up and running on Keyless SSL. So far, he said, there’s nothing about the service that has added a substantial load on Cloudflare’s networks or increased its infrastructure costs. “We see no reason that for a lot of our customers, that we can’t support it with existing infrastructure,” he said.
The service is aimed at organizations that want greater control over their encryption keys, but Prince said that he was surprised that many smaller customers are happy to have Cloudflare manage their keys for them. “It was a little bit of a surprise for us,” he admitted. “Smaller customers have said that they trust us more to maintain [their] key than they trust themselves.”
Prince also said that Keyless SSL would help Cloudflare expand its number of data centers much faster by using the technology internally. “We’re already in 28 of the 32 buildings that matter as central exchange points of the Internet, where you need things like retinal scans to get in,” he explained. “If we want to expand more, the places where we go next, just for physical security, don’t look like an Equinix facility in San Jose. For us to get comfortable to work in China, Africa, or Russia, we don’t want to put our customer’s data out in places where we don’t have that kind of security.”
But by using Keyless SSL, Cloudflare will be able to put servers in less secure data centers without leaving keys at risk. Since everything is in memory, everything in a remote data center disappears when the servers are rebooted. The master encryption keys are never put at risk.
Listing image by CloudFlare
reader comments
29