Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Keyless SSL

blog.cloudflare.com

Post reply on HN
Print view View original

101–110 of 190 posts

Re: Announcing Keyless SSL

#101

Post by rdl »

otterley wrote: post #86

Keyless SSL is basically an analogue of ssh-agent(1) for OpenSSL. It's a nice feature that you no longer have to trust CloudFlare with your private key, but there's a huge tradeoff: if your keyserver is unavailable (ironically, due to any of the things CloudFlare is supposed to protect you from or buffer you against -- DDoS, network/server issues, etc.), they can no longer authenticate requests served on your behalf…

True -- if the keyless server is down, we can't even complete the ssl handshake for new clients.

The keyserver is stateless, so you can have a bunch of keyservers (which don't need to be particularly near your own infrastructure) to deal with this, though.

There's also session caching (tickets or session id), so this only affects people who haven't connected to a cloudflare site recently.

It IS an issue, but it's not that hard to deal with.

Re: Announcing Keyless SSL

#102

Post by zmanian »

delinka wrote: post #60

Instead of keeping the key in a potentially vulnerable place, they're putting it in an oracle: pass ciphertext to the oracle, get plaintext back. I'm interested in the authentication between CloudFlare and the oracle. Cryptographic examples involving an oracle tend to refer to the oracle as a black box that just blindly accepts data, transforms it, and replies. Of course, then the oracle's content (a key, an algorith…

A nice thing about supporting a key oracle is that you keep the key material out of the process handling TLS. In the case of Heartbleed like bugs, this would protect against the loss of keys.

Re: Announcing Keyless SSL

#103

Post by lucb1e »

For 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. Up until now, you needed to.

What they did was take the private key and move it to a keyserver, owned by your bank or whomever. Every time the Cloudflare server receives a random password (which is encrypted with the public key) it just asks the keyserver "what does this encrypted message say?" After that it has the password to the connection and can read what the client (the browser) is sending, and write data back over the same encrypted connection. Without ever knowing what the private key was.

The connection from Cloudflare to your bank's webserver and keyserver can be encrypted in whatever way. It could be a fixed key for AES, it could be another long-lasting TLS connection (the overhead is mostly in the connection setup)... this isn't the interesting part and can be solved in a hundred fine ways.

Edit: Removed my opinion from this post. Any downvotes for my opinion would also push the explanation down (which I hope is useful to some). I mostly agree with the other comments anyway.

Re: Announcing Keyless SSL

#104

Post by yk »

So the problem is, how to get a cloud in the middle while keeping the green lock in the browser? Just yesterday I read Douglas Adam's phrase "technologies biggest success over itself."

Re: Announcing Keyless SSL

#105

Post by chetanahuja »

agwa wrote: post #90
chetanahuja wrote: post #88

Earlier quoted context omitted.

"Since key revocation is fundamentally broken" Do you mean SSL key revocation in general broken or in this proposed solution by cloudflare. If it's the former, would you care to elaborate how it's broken?

Why the former is broken: https://www.imperialviolet.org/2014/04/19/revchecking.html https://www.imperialviolet.org/2014/04/29/revocationagain.ht...

Ahh... now I remember reading/hearing about the OSCP ineffectiveness and stapling etc. a few weeks ago (after watching Ilya Grigorik's talk "is ssl fast already" or something like that). Thanks for the reminder.

Re: Announcing Keyless SSL

#106

Post by roc »

bkh wrote: post #75
roc wrote: post #50

Earlier quoted context omitted.

A notable difference is that a compromise of Cloudflare's key wouldn't [edit: might not] require the bank to notify the Federal Reserve. It may be pretty cynical to call that situation a "feature". But I'm sure it came up. And I'm sure they noticed. It certainly wouldn't be the first time "trivial functional difference" translated to "massive legal difference."

You should probably say "might not", because although we know a key compromise would require notification, you'd have to have an actual lawyer tell you if a compromise of CloudFlare would not. Unless the lawyers are on board with this as a solution to the notification problem, the whole solution doesn't do anything (legally).

It gets a little cumbersome to hedge casual conversation the way attorneys do, but sure, it would have been more accurate to have said:

"might not, under the current rules, which are always subject to change"

Re: Announcing Keyless SSL

#107

Post by eastdakota »

makomk wrote: post #97
seccess wrote: post #81

Earlier quoted context omitted.

This. SSL/TLS can ensure perfect forward secrecy when the private key is compromised, as long as the session information is ephemeral. With session tickets, compromise of the key used to create the tickets means every session created under that key can be compromised, regardless of whether the private key is lost. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for a great discussion of this.

As described, this scheme doesn't provide forward secrecy either. Anyone who can make requests to the key server can decrypt any past session made using the same SSL private key.

Actually, it does. I posted the RSA implementation, but Keyless supports ECDHE too. Tech details in tomorrow's post.

Re: Announcing Keyless SSL

#109

Post by xorcist »

tokenizerrr wrote: post #45
xorcist wrote: post #36

Earlier quoted context omitted.

There is no practical improvement here. What does it matter security-wise if the HSM module (which is what banks use) physically sits on Cloudflare premises or off Cloudflare premises? It's still connected to the same equipment. It does matter for a variety of other reasons, for example what security clearances are required to work there, but it does not matter much for security.

Now cloudflare employees will have no possible access to the private key, nor do intruders who break into the cloudflare servers. This keeps the bank in full control of who has access to the key, they can stop responding to signing requests at any time and then keep trusting the key on their own servers in the future.

Cloudflare employees will have no access to the key inside a HSM even if it colocated on their premises. That's why you use them.

Please summarize the differences between this protocol and PKCS instead of downvoting.

Re: Announcing Keyless SSL

#110

Post by tetrep »

makomk wrote: post #37
mhandley wrote: post #26

This seems to only slightly reduce the threat to the banks. Currently, if someone compromises the Cloudfare servers, they gain the bank's private key and can impersonate the bank until the bank revokes their keys. With this solution, if someone compromises the Cloudfare servers, they can impersonate the bank by relaying the decryption of the premaster secret through Cloudfare's compromised servers back to the bank. T…

Actually, thanks to session tickets, they can continue to impersonate the bank to existing users for potentially quite a while after Cloudflare lock them out.

how so? forward secrecy is public key crypto, the private key never leaves the oracle so all cloudfare needs to do is refuse requests made with the public key. ideally the oracle would block it as well, but having cloudfare do everything means minimal administration for their clients.
Post reply on HN