I don't like to sound hateful, but this is an obvious solution that any competent person knowing how TLS works would find. If someone tried to patent it, I suppose every smart card would be considered prior art. The only "novelty" is that the connection to the "smart card" is the network. Not to say that it's not useful, but the article describes it as some grand invention.
Announcing Keyless SSL
151–160 of 190 posts
Re: Announcing Keyless SSL
#152Earlier quoted context omitted.
It is very obvious... In hindsight?
Not sure why all the negative reactions here... Was anyone else doing or providing this type of "Keyless SSL" setup? You'd think if this was a known technique, the mentioned banks would already have been asking for it, implementing it, or doing it. Personally, I think CloudFlare is one of the few companies on here doing innovating stuff, and solving real issues. And if not - if they've pulled the wool over my eyes -…
Isolating the key for security/control purposes is a well known technique. It's what ssh-agent/putty paegent does, where you can even forward key usage over the network to different machines. It's what PKCS11 does to SSL/TLS, where generally the key is a hardware security module (CAs and banks don't have keys sitting on their public facing machines, but instead generally have dedicated hardware for it -- they are generally doing, at a different scale, what is described), though there have been various implementations and proposals over the years to do it over the network (e.g. https://svn.opendnssec.org/docs/p11proxy.png and pkcs11-proxy).
Why isn't it commonly done as Rackspace proposes? Well it's kind of an odd need for limited gain, but is effectively PKCS11 used in a different context. If they are solving a specific need for some of their clients then fantastic, but it's the narrative of the innovation that makes it a bit weird, and yielded a lot of the purportedly negative commentary.
Re: Announcing Keyless SSL
#153Earlier quoted context omitted.
Would be interested to hear from people who are burying my comment if they have any kind of explanation for why they are doing it, such as counterpoints to my statements. In case there is some insight that I might gain from them, since apparently there is a strong disagreement.
GP comment is too generalized to be constructive. That is especially so in this discussion of a specific network security platform, which presumably has specific faults that may be discussed instead of generalities like "belief systems" and "human lives".
Re: Announcing Keyless SSL
#154Earlier quoted context omitted.
Would be interested to hear from people who are burying my comment if they have any kind of explanation for why they are doing it, such as counterpoints to my statements. In case there is some insight that I might gain from them, since apparently there is a strong disagreement.
Almost every sentence of your comment contains non-obvious yet unsupported conclusions. I don't think a HN comment is the appropriate venue for your thinking; maybe a 20-page paper would be better.
Re: Announcing Keyless SSL
#155Earlier quoted context omitted.
Though Fedor isn't just some complete stranger online.
Maybe that's the part I was missing. There was no link to more information in his (her?) HN profile.
'His' apparently. I didn't know either, but apparently he was the first to crack Cloudfare's Heartbleed challenge:
http://blog.cloudflare.com/the-results-of-the-cloudflare-cha...
His LinkedIn / twitter for reference:
Re: Announcing Keyless SSL
#156For 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.…
(And hopefully it doesn't incur any downvotes and readers understand it is just an opinion.)
Re: Announcing Keyless SSL
#157And 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?
Re: Announcing Keyless SSL
#158Earlier quoted context omitted.
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.
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.
Re: Announcing Keyless SSL
#159Earlier quoted context omitted.
Breaking into a CloudFlare server does not get you this private key. CloudFlare does not keep this authentication key unencrypted on disk.
If you have access to a machine, why would you ever look for a key on disk instead of in memory?
Re: Announcing Keyless SSL
#160 Privilege Separated Key Handling added to relayd(8) and smtpd(8)
http://undeadly.org/cgi?action=article&sid=20140430155940 OpenSSL private key in separate process
https://www.agwa.name/blog/post/protecting_the_openssl_priva...