See: Secure session capability using public-key cryptography without access to the private key. https://www.google.com/patents/US8782774
[deleted]
Announcing Keyless SSL
131–140 of 190 posts
Re: Announcing Keyless SSL
#132Earlier quoted context omitted.
"Tomorrow, we'll publish a full post on the nitty, gritty techical details of how, what has come to be called Keyless SSL™, works."
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.
But it's already fairly obvious how it works.
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.
Re: Announcing Keyless SSL
#133Earlier quoted context omitted.
CloudFlare can serve cached responses in the event that your origin server is unavailable. This is particularly useful for static websites, but that's not the most common use case.
If your origin server can be found on the internet, it can be DDoS'd/attacked, and your (dynamic) site will go down. This is true of all CDNs. The way to avoid this is to either have the CDN host your app servers or provide a private connection from your origin to the CDN. I guess technically the TLS-secured static content would now be at more risk than it was before, when the cached content would have been served. B…
[deleted]
Re: Announcing Keyless SSL
#134See: Secure session capability using public-key cryptography without access to the private key. https://www.google.com/patents/US8782774
And here's a similar patent from Akamai (via @cloudpundit) http://www.google.com/patents/US20130156189
Re: Announcing Keyless SSL
#135Earlier quoted context omitted.
As Google and Yahoo will tell you after they found out the US government broke into their dedicated lines between data centers... No. It must be encrypted at every transfer without exception.
There's a huge difference between passively tapping a fiber optic cable and infiltrating a network to inject malicious traffic. All we've ever seen evidence of is NSA's passive tapping of Google & others.
We know the NSA targets routers. They have rootkits and remote exploits for them. They can do packet injection or anything else with the traffic passing through routers they take over.
Re: Announcing Keyless SSL
#136And my patch for OpenSSL that does the same thing: https://gist.github.com/indutny/1bda1561254f2d133b18 , ping me on email if you want to find out how to use it in your setup.
No disrespect meant, but from a security perspective the idea of patching security-critical software with a patch from a stranger on the Internet is kind of crazy, isn't it?
Though Fedor isn't just some complete stranger online.
Re: Announcing Keyless SSL
#137See: Secure session capability using public-key cryptography without access to the private key. https://www.google.com/patents/US8782774
And here's a similar patent from Akamai (via @cloudpundit) http://www.google.com/patents/US20130156189
Looks like the Akamai patent for basically the exact same process, filed 2012-12-14, priority date 2011-12-16 is still being examined... yet the CloudFlare patent filed 2013-03-07 was granted 2014-07-14.
That's a really fast turnaround for CloudFlare, and not sure how the Akamai filing isn't prior art. Actually, the Akamai filing is referenced in the CloudFlare patent.
Re: Announcing Keyless SSL
#138For those who want to understand how it works (it took me a minute, so I'll try to explain it simpler): In simplified terms, the server usually stores a public and private key, and sends the public key to the client. The client generates a random password, encrypts it with the server's public key, and sends it to the server. Only anyone with the private key can decrypt the message, and that should only be the server.…
Now you don't want to hand over this private key to Cloudflare if you don't need to, because then they can read all traffic. Generally the key you would give them is for, and limited to, the resources that they cache/reverse proxy, so the same "read all traffic" concern exists. What Cloudflare did is essentially, as others have mentioned, PKCS11 over the internet. PKCS11 is an existing, very well proven technique of…
It is very obvious... In hindsight?
Re: Announcing Keyless SSL
#139For those who want to understand how it works (it took me a minute, so I'll try to explain it simpler): In simplified terms, the server usually stores a public and private key, and sends the public key to the client. The client generates a random password, encrypts it with the server's public key, and sends it to the server. Only anyone with the private key can decrypt the message, and that should only be the server.…
Now you don't want to hand over this private key to Cloudflare if you don't need to, because then they can read all traffic. Generally the key you would give them is for, and limited to, the resources that they cache/reverse proxy, so the same "read all traffic" concern exists. What Cloudflare did is essentially, as others have mentioned, PKCS11 over the internet. PKCS11 is an existing, very well proven technique of…
I think the exaggeration is because its a sales pitch, but it illustrates an important concept -- doing something "known" but in a generic way can be more valuable than having a proprietary solution. Of course someone could come up and offer a 'Cloudflare' box that just does key sequestration and sell that.
And while I think banks and others will find this useful, its even more useful if I can do it from a far away place. When you create an SSL connection in Europe to a west coast server there are a number of round trips. If those can be avoided you can cut the latency of the transaction. That is a good thing too.
Re: Announcing Keyless SSL
#140While this is a cool feature, I wouldn't say the improvement is more than marginal: all potentially sensitive customer data is still available to Cloudflare in plain text. And after all, with a Business plan you can already use your own ("custom") SSL certificate which you can then revoke at any time. Why not offer a "pass through" mode where the proxying is done on the network layer rather than the application layer…
Well, for the use case given, with "Keyless SSL", if Cloudflare is compromised, then the bank doesn't need to report the incident to the Federal Reserve. But yes, users' plaintexts would still be compromised. "Security theatre" indeed.
It seems harsh to call it theatre, and I expect all cloud services will adopt it.
It means people can use a cloud service without giving them private keys. This seems much better than giving them keys.
I too was hoping there would be some clever math to make it so some part of the conversation between client and back end was an encrypted tunnel that cloudfare can route but not read. This doesn't seem to be the case.
But all the same, however small a step, its not theatre.