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

41–50 of 190 posts

Re: Announcing Keyless SSL

#41

Post by peterwwillis »

ch wrote: post #33
jgrahamc wrote: post #12

Earlier quoted context omitted.

Yes.

Won't this approach increase the cap-ex investment on the part of the customer, and the complexity to scaling? Do you require the customer to size their key services to some theoretical peak, or can you offload so much of the process that the customer just needs to make a one time investment? (Full disclosure. I work for a competitor, but not on problems like this).

The customer site now is responsible for providing key signing in a highly available fashion. It makes sense they would need to spend more (probably no more than for an hsm) to ensure the connection never goes down. If you can take down the connection from Cloudflare to the customer site, their website goes down.

Re: Announcing Keyless SSL

#42

Post by vidarh »

praseodym wrote: post #14

So CloudFlare won't get your private key, but will still get to see unencrypted plaintext for all traffic? Sounds like a huge improvement...

The big deal is that CloudFlare's ability to sign SSL sessions can be yanked with the flip of a switch, with no need to trust CloudFlare.

Of course you still need to trust CloudFlare to let them provide SSL functionality for you in the first place. But often the issue of "do I trust them today?" is separate from "will I still trust them tomorrow? and what happens if I don't?".

E.g. consider if I trust CloudFlare today, but want to be protected in the event that they fail and suffer intrusion. With this service, I could as an emergency just flip a switch (shut down the devices providing the key signing) and instantly disable CloudFlare's ability to accept SSL connections on my behalf, without having to trust that they manage to deal with the intrusion properly.

By allowing me to put less trust in them, I may trust them more, because the ability to counteract misplaced trust is much better.

Re: Announcing Keyless SSL

#43

Post by count »

ch wrote: post #33
jgrahamc wrote: post #12

Earlier quoted context omitted.

Yes.

Won't this approach increase the cap-ex investment on the part of the customer, and the complexity to scaling? Do you require the customer to size their key services to some theoretical peak, or can you offload so much of the process that the customer just needs to make a one time investment? (Full disclosure. I work for a competitor, but not on problems like this).

Key services are used to kickstart the SSL connection, not support it the whole way through (I believe?), so the 'load' is SIGNIFICANTLY less than terminating the entire connection for the whole session.

Re: Announcing Keyless SSL

#44

Post by jgrahamc »

ch wrote: post #33
jgrahamc wrote: post #12

Earlier quoted context omitted.

Yes.

Won't this approach increase the cap-ex investment on the part of the customer, and the complexity to scaling? Do you require the customer to size their key services to some theoretical peak, or can you offload so much of the process that the customer just needs to make a one time investment? (Full disclosure. I work for a competitor, but not on problems like this).

We don't expect there to be a cap-ex spend need here because we will be offloading most of the SSL processing to our servers (as well as offloading other parts of the web session).

Re: Announcing Keyless SSL

#45

Post by tokenizerrr »

xorcist wrote: post #36
nknighthb wrote: post #27

Earlier quoted context omitted.

It is a huge improvement. Nobody can impersonate the bank without the bank's cooperation. When cooperation ends, so does the ability to impersonate. This is not the case with any mechanism that requires you to hand over your keys. Not even issuing a revocation effectively terminates use of a compromised key.

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.

Re: Announcing Keyless SSL

#46

Post by marcosdumay »

sarciszewski wrote: post #24
praseodym wrote: post #21

Earlier quoted context omitted.

I don't really see the security improvement. Actually the key server would be an new attack vector, although one that could be firewalled pretty well.

Using CloudFlare implicitly requires trusting CloudFlare. With this, CloudFlare cannot impersonate you without your endpoint's active consent. As soon as you terminate the service that solves this puzzle for CF, they cannot impersonate you any longer. So, yes, it is better. Maybe not "great" if your threat model includes CF getting 0wned, but definitely better than giving over your RSA key. ;)

And that's why regulations make it almost impossible for banks to use CloudFare. But CloudFare sees that as a problem, and makes some effort to create a loophole.

You can't claim that this improves the bank clients' security. It's clearly worse than doing nothing.

Re: Announcing Keyless SSL

#48

Post by sp332 »

tokenizerrr wrote: post #35
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…

> 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 i…

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

Re: Announcing Keyless SSL

#49

Post by eastdakota »

Rapzid wrote: post #34
jgrahamc wrote: post #8

Earlier quoted context omitted.

There's a very technical blog post coming on this tomorrow, but that problem is addressed by session tickets and by the fact that most of the TLS handshake is occurring with a CloudFlare server typically nearer the web browser than before.

Do you guys have a "global" session ticket cache shared amongst endpoints? Or do you ensure the same user gets routed back to the same termination node? I'm quite curious about this.

Session Tickets are shared globally. Session IDs are shared intra-data center (so regionally). The former works with Chrome/Firefox. The latter with all other browsers.

Re: Announcing Keyless SSL

#50

Post by roc »

teddyh wrote: post #2

So the communication between Cloudflare and the actual SSL key holder is secured by… what? Another key? In that case, any compromise of Cloudflare’s key is the same as a compromise of the original SSL key (at least in the short term).

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

Post reply on HN