Interesting how they specifically refer to yesterday's discussion here on HN and over at Reddit, but don't go into the frequently mentioned complaint that despite not having access to the PK itself, Cloudflare can still intercept and modify all cleartext sent between the client and server, which for most intents and purposes means pretty much the same. Maybe not intentionally so, but it comes off as slightly misleading, because many people I spoke to who briefly skimmed the original announcement thought "keyless SSL" would mean this is no longer the case.
Let me ask again: why not offer a setup where Cloudflare only acts on the network layer instead of on the application layer and proxies the still-encrypted HTTPS packets to the destination server? This would mean a customer could not use Cloudflare's caching (CDN) features, but still enjoy their DDOS protection without them being able to see all my customer's private details. If I were the CISO at one of the world's largest banks, that is exactly what I would want.
The problem that Keyless SSL is solving is the need for a client to hand over their SSL keys to Cloudflare in order to use Cloudflare's services.
It eliminates the risk that the key will be stolen from Cloudflare and used by the Bad Guys to set up a fake website to steal everyone's credentials.
You might not perceive how big the benefit of this is but you're not the target market. I used to handle the SSL encryption keys (and server security) for the online trading systems of a global investment bank. In my opinion, not having to hand over the SSL keys removes a significant obstacle to banks using Cloudflare's services.
Yes, Cloudflare will still be able to read and, in theory alter, the data flowing between the end-user and the client (I would not be surprised if a future enhancement to this mechanism enabled some kind of hashing/signing of the HTTP requests/responses, such that any attempt by Cloudflare to alter the content would be obvious) but that is an entirely different risk than the risk of your SSL keys being stolen.
CDNs are used to deliver static, highly cacheable content, like assets, images, media content, stuff that will be delivered to many users.
It is very rare that a website serves this type of content under the same domain as the dynamic content (think cdn1.whatnot.com, assets-myapp.com).
In fact for applications with a lot of assets this is a must because of domain sharding and to avoid the overhead of sending the cookies on every single request. Since you need a different domain, you can (you don't have to) use a different certificate, so it's not a strech to use a different private key.
Then there are the applications where security is more important than latency - online banking, payment gateways, tax filing.
Those applications don't have too much cache-able content so they simply won't benefit from CDNs.
I also don't see how is this faster. Sure, CloudFlare Keyless SSL is faster than serving the content yourself, but sending that packet over the internet
is always going to be slower than not. So now I have a slower (compared to the CDN having my key), more complicated option that requires me to run an additional keyserver and doesn't provide me additional security. The only upside of this seems to be good PR.
Depending how sensitive the content is, in fact if I could I would choose to deliver it over plain HTTP and sign it somehow. That would be best of both worlds.
Edit: I admit I totally missed the point about DDoS protection.
I think you may be missing that one of CloudFlare's key features is DDoS protection (and in fact it was a DDoS that initially caused the banks to approach them), including at the application layer. That functionality cannot be fulfilled without CloudFlare having access to the content of the communications, nor can any of their other application-layer security functions.
I understand that there are many different types of DDOS attacks, and that for some of them having access to the content on the application level makes your job of mitigating them a lot easier.
But even without that, would comparing the encrypted traffic patterns for an individual client to other client's patterns (or to that client's traffic to one of the other 2 million Cloudflare websites); and analyzing the encrypted traffic as in [1] not still give you a wealth of information to use? It might have made for a much more rewarding two years of development: even if such a setup would be slightly less effective at mitigating DDOS', it would be infinitely better in terms of privacy and trust.
In some ways what you propose sounds even scarier, i.e. figure out the best way to look inside SSL encrypted data without having the key.
But in terms of privacy and trust, CloudFlare is already in the position of terminating SSL connections and establishing new ones to origin web servers. We take the protection of that data and the associated keys very seriously. There will be more announcements over the coming weeks and months about how we secure things.
I'm not quite following how having just enough insights about the encrypted data to perform DDOS mitigation would be scarier than having full read- and write access to the cleartext. Thanks for the responses though, and definitely looking forward to those blogs.
You are implying something fundamental: that the encrypted traffic could be adequately analysed for insight without the need for decryption.
Yet to do so would be to defeat SSL itself, or at least to declare it as insufficient to adequately protect secrets.
What CloudFlare is doing isn't defeating SSL or any kind of attack on it. They are merely working around some prior limitations on requiring access to an organisation's private key.
As a proxy that is charged with DDoS protection (and other types of protection and performance improvements), they are being asked to terminate and work on the unencrypted data to a very strict set of complience by the end organisations, but they need to do this in a way that does not involve possessing or having access to the private key.
Their solution works extremely well given the multiple constraints (technological and legal) that they have.
> You are implying something fundamental: that the encrypted traffic could be adequately analysed for insight without the need for decryption.
> Yet to do so would be to defeat SSL itself, or at least to declare it as insufficient to adequately protect secrets.
This is possible through HTTPS traffic analysis, see [0] and [1] for starters. Of course, it's much easier for Cloudflare to do analysis for DDoS protection if they have access to plaintext.
Whether this means that SSL is, as you say, "insufficient to adequately protect secrets" is an interesting discussion to have.
Actually thats pretty disingenuous. Most of the attacks CloudFlare prides itself on defending are amplification attacks (NTP and DNS specifically) not DoS attacks within the relevant protocols. Servers that simply forwarded 80 and 443 while dropping everything else sitting on really big pipes is really what people are paying you for today.
You are correct that we deal with amplification/reflection attacks all the time.
But what you don't see are the HTTP-level attacks where we put in place filtering rules in our WAF to block them. You don't see them because we mostly don't write about them. These attacks are different from the NTP/DNS style (which fill pipes) because they use server resources on the origin web servers.
Sure, there are probably a handful of custom rules that some customers get, but like I said... most of your customers are paying for something that drops NTP/DNS and forwards HTTP/HTTPS.
The WAF product has had a LOT of upgrades since that report, and has a huge update coming in Q4. That report is pretty out of date; I'd be happy to provide a test setup for Zeroscience to do a new analysis if they'd like, and am looking at how to do a continuous test/demo of the new WAF, because it's pretty interesting how it works.
When a source IP is shared (Tor exits, carrier NAT, etc.), trying to push as much into URL pattern vs source-IP filtering, for instance.
They can manipulate traffic, but so can the bank's operations division. The fact that Cloudflare is a different organization makes contractual agreements much more important, but as long as they are in proper order the difference shouldn't be of importance to the end user.
The difference to the end user is that while the bank's operations division can only do this for a single website, Cloudflare can do so for 2 million of them.
That is indeed a difference, but perhaps not directly relevant to the bank's security.
For large scale traffic manipulation, Google is even better suited. They have arbitrary access to the DOM tree of over 10 million websites via Google Analytics, including several banks.
Well for that matter so is the assurance that only you can purchase a valid SSL certificate for a domain you own. At some point, you gotta trust some people!
This is something that I spent a lot of time on a few years ago.
Some of the HTTP accelerator servers I ran were in countries or sites that were more problematic than others, so it was desirable to not locate SSL keys on them. Instead of handling HTTP, the servers would become a TCP level proxy, and forward resp / req packets between a server with the SSL key and the client.
The biggest hurdle is that without being able to decrypt the incoming SSL, you can't know anything about the HTTP request -- including hostname or path. So you have to forward all of your received traffic to the same place, and you can only vary the destination based on the source IP that receives it.
IPs are limited. There is no way that Cloudflare could have even 1 IP for each of their customers in each of their sites around the world, it simply cannot be done.
There is lots of other common functionality that you lose (edge caching, cookie routing, etc.) but the inability to route at layer 7 is the big one.
Let me ask again: why not offer a setup where Cloudflare only acts on the network layer instead of on the application layer and proxies the still-encrypted HTTPS packets to the destination server? This would mean a customer could not use Cloudflare's caching (CDN) features, but still enjoy their DDOS protection without them being able to see all my customer's private details. If I were the CISO at one of the world's largest banks, that is exactly what I would want.