Is that actually true, though (especially w.r.t. Forward Secrecy)? Don't both parties generate separate halves of a symmetric key independently, preventing any one party from forcing the use of a particular key on a new session?
CloudFlare has learned their lesson from past experiences and how makes the big media announcement one day with a smaller less publicized announcement later covering the technical details. This prevents reporters from stumbling across a HN thread tearing the "new internet saving technology" apart and reporting on weaknesses or flaws.
But it's already fairly obvious how it works. They essentially MITM with the keyserver to receive the SSL nonce. Of course, it's pretty silly to expect cloudflare to have some special mathematical revolution to solve the stated problem. In fact I figure if you could terminate SSL without an online private key, the encryption scheme is simply broken.
It is obvious, and they effectively implemented a custom approach for PKCS11/ssh-agent. Yet the narrative implies some brilliant period of insight and innovation, when really it kind of isn't.
Which is where the "silly" notion that they must have did something novel came from -- their narrative claims it.
Innovation means different things to different people. To you, it seems to mean a mathematical or algorithmic breakthrough. To me, it also means getting an existing idea or technology, and deploying it in a new, real-world context, solving the UX / scalability / security / policy issues that arise in the new context, and make it commercially viable.
The fact that Cloudflare is the first global-level CDN to implement this kind of keyless SSL termination to me is innovation, even though it's based on pulling PKCS11 at the IP level. It's solving a real-world problem in their context, which nobody has solved before, and customers pay for it.
The approach is pretty obvious, and I instantly knew where they were going as soon as I read the phrase "session signing, the only part of the SSL handshake that requires the private key", but still, it's novel to take this existing concept and generalize it to solve the "I don't want to give CloudFlare my private keys" problem. It'll be especially cool if they establish an open standard for the keyserver protocol.
One of the elements in SPDY is that responses to requests can be pushed by the server anticipating a request. But that's a relatively new development compared to when I figured out that this 'feature' is supported by just about every browser out there. And it's kind of logical, if you implement HTTP in the most straightforward way then the network stack will buffer the response until the next read, regardless of what the rest of the program is doing. So when the browser issues that read (either in a separate reader thread or in the same one if it is programmed single threaded write-then-read style) it immediately finds the answer to the request it just sent out.
Strictly speaking extra bytes sent past the end of the response to the current request (or before even any request has been sent) is a protocol violation but I'm really not complaining about this one, after all, that line in the spec does not actually specify the timing. We all just read between the lines to see what we expect to see: ping ... pong.
