Hacker News Reader

Comment by mhandley | Hacker News Reader

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. They can do this until Cloudfare notices and closes the security hole.

It's not clear that the difference is all that great in reality, as most of the damage will be done in the first 24 hours of either compromise.

View on HN

Since key revocation is fundamentally broken it's the difference between having a limited time period where you're exposed and being exposed until the cert actually expires.

"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.

> Currently, if someone compromises the Cloudfare servers, they gain the bank's private key

This is not strictly true, is it? My interpretation is that at best they get temporary access to a server that will sign for them using the key, but the bank can terminate their signing servers at any time and then safely resume using their key without having to revoke it, since it never left their server.

This does somewhat increase the attack surface, but it lets the bank keep control over their keys and is better than having their keys get compromised and thus having to revoke them.

That's how I read it too. You can gain control of a session, but the private key should remain safe. I could be wrong though.

Here, "currently" is the status quo, which is contrasted to "this solution". So "currently" means "without this solution".

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.

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.

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.

Reply on news.ycombinator.com