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

31–40 of 190 posts

Re: Announcing Keyless SSL

#31

Post by Xylakant »

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…

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.

Re: Announcing Keyless SSL

#32

Post by Rapzid »

spacefight wrote: post #6
personZ wrote: post #4

After reading the beginning of the piece, I was expected something more...profound. Some deep mathematical breakthrough or something. Instead they separate the actual key signing, delegating it to the customer's device. That's nice and useful, but isn't quite what I was expecting.

Yes - and it's nowhere near "keyless" - it's just that the key is somewhere elseTM.

Maybe they should have said "keyless termination"? I can see that as they are still terminating the connection and they don't have the key.

Re: Announcing Keyless SSL

#33

Post by ch »

jgrahamc wrote: post #12
spacefight wrote: post #11

Earlier quoted context omitted.

Interesting. Multiple connections AND multiple servers?

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

Re: Announcing Keyless SSL

#34

Post by Rapzid »

jgrahamc wrote: post #8
kcbanner wrote: post #3

Interesting, but what about the latency issues of having to always contact the key server?

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.

Re: Announcing Keyless SSL

#35

Post by tokenizerrr »

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

Re: Announcing Keyless SSL

#36

Post by xorcist »

nknighthb wrote: post #27
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.

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.

Re: Announcing Keyless SSL

#37

Post by makomk »

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.

Re: Announcing Keyless SSL

#38

Post by xorcist »

The article is somewhat light on content. There are standard protocols for HSM use. What is the reason you didn't use these? There are clear risks involved with inventing your own security related protocols.

Re: Announcing Keyless SSL

#39

Post by jgrahamc »

xorcist wrote: post #38

The article is somewhat light on content. There are standard protocols for HSM use. What is the reason you didn't use these? There are clear risks involved with inventing your own security related protocols.

We have a really long technical blog post coming tomorrow. Agree that inventing protocols is dangerous so we got iSEC Partners/Matasano to evaluate.

Re: Announcing Keyless SSL

#40

Post by theintern »

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…

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.
Post reply on HN