[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
Random Oracle 