Day: September 24, 2014

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

[continued from part I]

Handshakes with PFS

Perfect-forward secrecy precludes decrypting past traffic which was collected passively earlier. But we still can pull off a real-time active attack with the help of our friend CloudFlare. Suppose we have man-in-the-middle capability, controlling the network around our victim. When the victim tries to connect to the CDN, we impersonate the site and start a bogus handshake. Given access to a decryption oracle as in #1, we could always downgrade the choice of ciphersuite to avoid PFS but that is not very elegant. Users might get suspicious why they are not seeing the higher-security option. (Not that any web browser actually surfaces the distinction to users.  While the address bar turns green for extended validation certificates— purely cosmetic, since they have little security benefit– there is no reassuring icon to mark the presence of PFS.)

Luckily we can carry out a forged SSL handshake with PFS intact by enlisting the help of CloudFlare. This time instead of asking our friendly CDN to decrypt an arbitrary ciphertext, we ask for assistance with signing an opaque message. CloudFlare will turn around and pass on this request to the origin site. Once again origin is oblivious to the fact that this request is for MITMing a user as opposed to a new legitimate connection. Unlike simple RSA decryption, this time the transcript getting signed (more accurately its hash) is different each time so there is not even a way for the careful origin implementation to distinguish.

One could object this approach is highly inefficient. Why not let the target connect directly to CloudFlare and ask them to store a transcript of decrypted traffic for later retrieval? Because that would reveal the target of surveillance. Network MITM combined with well-defined interaction with the CDN (“sign this hash”) avoids divulging such information.

Oblivious customers

It’s worth emphasizing again that in neither case does origin site do anything extra or different to enable interception. As far that customer is concerned, they are simply holding up their part of the CloudFlare “keyless SSL” bargain. There is no need to send national-security letters to secure  cooperation from the origin site. They can remain blissfully ignorant, publishing a squeaky clean transparency report where they can boast about never having received requests for customer data. That’s because such requests are routed to the CDN, who is then legally obligated to keep its own customers in the dark about what is going on. (In fact CloudFlare claims having received “between 0-249” NSLs in its own transparency report, which is not broken down by customers.)

This is why one of the touted benefits around revoking trust is moot. In principle the customer can instantly revoke access by refusing to decrypt for CloudFlare if the CDN is suddenly considered  untrusted. (Of course they could have achieved the same effect in the traditional setup by revoking the certificates given to the CDN, but that runs into the vagaries botched and half-baked revocation checking in various browsers.) Minor problem: there is no way to know if the CDN is operating as advertised or helping third-parties intercept private communications to origin. There is no accountability in this design.

NSL canaries?

This blogger is not asserting such things are happening routinely at CloudFlare. The point is that it can happen and in spite of best intentions, a CDN can not provide guarantees against such compelled assistance. Even the NSL canary in CloudFlare transparency report is fully consistent with offering such on-demand decryption assistance:

  • CloudFlare has never turned over our SSL keys or our customers SSL keys to anyone.
  • CloudFlare has never installed any law enforcement software or equipment anywhere on our network.
  • CloudFlare has never provided any law enforcement organization a feed of our customers’ content transiting our network.

Providing a controlled interface for law-enforcement to request decryption/signing does not violate the letter or spirit of any of these assertions. When origin site provides an API for CloudFlare to call and request decryption, surely that does not count as the origin site installing CloudFlare software or equipment on its network. By the same token, if CloudFlare were to provide an API for law-enforcement to call and request decryption (which must be proxied over to origin site for “keyless SSL”) it does not count as installing law-enforcement software. Neither does it count as providing a feed of content transiting the network– that  “content” is captured by government in encrypted form as part of its intelligence activities, and CloudFlare simply provides tactical assistance in decryption. There is of course the question of whether such canaries are meaningful to begin with. If it turns out that CloudFlare was in fact colluding with US government all along in violation of the above statements, would the FTC– a different part of that same government– go after CloudFlare for deceptive advertising?

Clarifying threat models

This is not to say keyless SSL has no benefits. Only having one location containing sensitive keys as opposed to two reduces attack surface. (This is true even if origin uses a different hostname than externally visible one to avoid having another key that can enable MITM attacks. The links between CDN-origin are highly concentrated targets for surveillance.) It protects the origin from mistakes and vulnerabilities on the part of the CDN that lead to disclosure of the private key– such as the Heartbleed scenario that affected CDNs in April. But there is a clear difference between incompetence and malice. Keyless SSL provides no defense against a CDN colluding with governments to enable surveillance while keeping its customers in the dark.

CP

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.