Because DDoS protection isn't just something you do at the network layer. It's important to be able to apply filtering at the "application" level.
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.
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.
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.
Whether this means that SSL is, as you say, "insufficient to adequately protect secrets" is an interesting discussion to have.
[0] http://arxiv.org/pdf/1403.0297.pdf
[1] http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-goo...
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.
We need to be able to defend against both.
The standard WAF that all customers get scores pretty badly in independent tests: http://www.slideshare.net/zeroscience/cloudflare-vs-incapsul...
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.