CloudFlare and keyless SSL: far from NSL-proof (part I)


CloudFlare recently announced the availability of keyless SSL for serving SSL traffic without having direct access to cryptographic keys used to establish those SSL connections. This post takes a closer look at the implications of the architecture for security and compelled-interception by governments.

Content distribution networks

Quick recap: a content distribution network or CDN is a distributed service for making a website  available to users with higher availability, reduced latency and lower load on the website itself. This is accomplished by having CDN servers sit in front of the origin site, acting as a proxy by fielding requests from users. Since many of these requests involve the same piece of static content such as an image, the CDN can serve that content without ever having to turn around and interact with the origin site. Also CDN systems are typically located around the world on optimized network connections, with much faster paths to end-users than the typical service can afford to build out itself. Over time CDNs have expanded their offerings to everything from DDoS protection to image rescaling and optimizing sites for mobile browsers.

SSL problem

There is one hitch to using a CDN with SSL: CDN infrastructure must terminate the connection. For example MSFT’s Bing search engine uses Akamai. When users type “https://www.bing.com” into their browser, that request is in fact going to Akamai infrastructure rather than MSFT. But SSL uses digital certificates and associated secret keys for authentication. That means either the CDN obtains a new certificate on behalf of the customer (with CDN-generated keys and customer vouching for the CDN) or the customer provides their CDN with existing certificate/key.

Getting by without keys

“Keyless SSL” is a misnomer since it is unavoidable for the SSL/TLS protocol to rely on cryptographic keys for security. But the twist is that the CDN no longer has direct control of the private-key. Instead the specific parts of the SSL protocol that call for using the private-key are forwarded to the origin site who performs that particular operation (either decryption or signing depending on whether PFS is enabled.) Everything else involved in that request is still handled by the CDN. There is a slight regression in performance. Public-key cryptography operations in a SSL handshake are one of the more computationally demanding parts of the protocol. Origin site must be involved in handling each of these again, forfeiting one of the benefits of using CDN in the first place. What do we get in return?

Security improvement?

CloudFlare goes to great lengths to emphasize that this design guarantees they can not be compelled to reveal customer keys to law enforcement– because they do not have those keys. This is a legitimate concern. CDNs create a centralized, single point of failure for mass surveillance. A CDN might be the best friend for data-hungry intelligence agencies. Instead of having to issue multiple requests to tap into traffic for different websites, they can directly work with 1 CDN serving those customers to get access to all content going through the CDN, without the to decrypt any content going through. To what extend does that picture change? It turns out the answer is, not much.

First observation is that the ability to use a cryptographic key without restriction can be just as good as  having direct access to raw key-bits. Recall that CloudFlare can make requests to origin site and ask for arbitrary operations to be performed using the key. In other words the origin presents an “oracle” interface for performing arbitrary operations. In other contexts this is enough to inflict serious damage. Here is a parallel from the Bitcoin world: Bitcoin wallets are represented by cryptographic keys. Moving funds involves digitally signing transactions using that key. If you do not trust someone with all of your money, you would not give them access to your wallet keys. But would you be comfortable with a system where that same person can submit opaque messages to you for signing? Clearly this would not end well: they could craft a series of Bitcoin transactions to transfer all funds out of your wallet into a new one that they control. You would become an accessory to theft of your own funds by rubber-stamping these transactions with a cryptographic signature whenever asked. A different low-tech example is withholding your checkbook from an associate who is not trusted with spending authority, but being perfectly happy to give them a signed blank-check whenever asked. Strictly speaking the checkbook itself is “safe” but your associate can still empty out your account.

Law-enforcement perspective

Building on that first observation, we note that possession of private keys is sufficient but not necessary condition for intercepting communications. Putting ourselves in the position of a government trying to monitor a particular user, let’s consider how we can enlist ClouldFlare to achieve our objectives even when keyless SSL is employed.

Simple handshake

For simple RSA-based key exchange, suppose our intelligence agency has collected and stored some SSL traffic in the past. Now we want to go back and decrypt that connection. All we need to do is decrypt the client key-exchange SSL handshake message that appears near the beginning. This message contains the so-called “premaster secret” encrypted in the origin site’s RSA key. So we take that message and enlist the help of our friendly CDN to decrypt it. When keyless SSL is in effect, CloudFlare can not perform that decryption locally. But it can ask origin site to do so using the exact same API, interface etc, used to terminate SSL connections for legitimate use-cases. Given the premaster secret, we can then derive session keys used for the remainder of the connection for bulk data encryption, unraveling all of the contents. Meanwhile the origin site is none-the-wiser about what just went on. There is no indication anywhere that past traffic is being decrypted under coercion as opposed to a new SSL connection being negotiated with a legitimate user.** The operations are identical.

[continue to part II]

CP

** A diligent origin implementation could notice that it is being asked to decrypt a handshake message that has already been observed in the past. Such a collision is extremely unlikely to happen between messages chosen by different users.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s