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

Keyless SSL: The Nitty Gritty Technical Details

blog.cloudflare.com

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Keyless SSL: The Nitty Gritty Technical Details

#51

Post by infogulch »

peterwwillis wrote: post #50
jessaustin wrote: post #43

Earlier quoted context omitted.

How would an attacker learn of the private key server? If that were easy, the very concept of CloudFlare would be undermined, which obviously is not the case. Having learned the address of the private key server, how would an attacker proceed? ISTM that all she could attempt would be to repeatedly try to set up the "secure tunnel" mentioned in TFA. At some point the private key server could just ignore those. I don't…

> How would an attacker learn of the private key server? If they're using CloudFlare and they're a large financial institution we'll just assume they're using this new service. Now we just need to find the location of the keyserver. There's a variety of ways to locate a server when you don't know where it is. The default is to scan the target's network. To find the network you can look at the ARIN info for addresses…

This is CloudFlare's entire core business model. CloudFlare is just a reverse proxy+cache. The original web server is still run by whatever company is using their services.

Fixed: "If they're using CloudFlare and they're a large [anything], we just need to find the location of the [origin webserver]."

This hasn't been a problem for any of their customers that do this so far (hint: all of them), adding a keyserver is no different.

Re: Keyless SSL: The Nitty Gritty Technical Details

#52

Post by ctz »

xorcist wrote: post #12

Interesting read. Still no information how it compares to other HSM implementations however, and why they didn't use the more well studied PKCS protocols in theirs. I would imagine the problem was more with existing implementations rather than some problems with HSMs per se, as they probably have much larger latency than you normally have so things like blocking reads start to matter.

I guess you mean PKCS#11, but that isn't a protocol. It's a C API. Trying to funnel it over a network would be both extremely complex, and non-standard.

Re: Keyless SSL: The Nitty Gritty Technical Details

#53

Post by dsl »

jgrahamc wrote: post #49
dsl wrote: post #48

Earlier quoted context omitted.

Actually thats pretty disingenuous. Most of the attacks CloudFlare prides itself on defending are amplification attacks (NTP and DNS specifically) not DoS attacks within the relevant protocols. Servers that simply forwarded 80 and 443 while dropping everything else sitting on really big pipes is really what people are paying you for today.

You are correct that we deal with amplification/reflection attacks all the time. But what you don't see are the HTTP-level attacks where we put in place filtering rules in our WAF to block them. You don't see them because we mostly don't write about them. These attacks are different from the NTP/DNS style (which fill pipes) because they use server resources on the origin web servers. We need to be able to defend agai…

Sure, there are probably a handful of custom rules that some customers get, but like I said... most of your customers are paying for something that drops NTP/DNS and forwards HTTP/HTTPS.

The standard WAF that all customers get scores pretty badly in independent tests: http://www.slideshare.net/zeroscience/cloudflare-vs-incapsul...

Re: Keyless SSL: The Nitty Gritty Technical Details

#54

Post by bifel »

I don't get it. What's the point in keeping the key secret from cloudflare whilst providing a key server signing everything it is asked to sign? Isn't this like "Sorry I don't trust you enough to provide you a key to my apartment. But if you need something, just ask the janitor, he'll open the door any time you want"?

Re: Keyless SSL: The Nitty Gritty Technical Details

#55

Post by wsh »

bifel wrote: post #54

I don't get it. What's the point in keeping the key secret from cloudflare whilst providing a key server signing everything it is asked to sign? Isn't this like "Sorry I don't trust you enough to provide you a key to my apartment. But if you need something, just ask the janitor, he'll open the door any time you want"?

If you no longer trust the person, it's easier to tell the janitor not to admit him than to rely on his returning the key (and any copies) or to change the lock on the apartment.

Re: Keyless SSL: The Nitty Gritty Technical Details

#56

Post by xorcist »

ctz wrote: post #52
xorcist wrote: post #12

Interesting read. Still no information how it compares to other HSM implementations however, and why they didn't use the more well studied PKCS protocols in theirs. I would imagine the problem was more with existing implementations rather than some problems with HSMs per se, as they probably have much larger latency than you normally have so things like blocking reads start to matter.

I guess you mean PKCS#11, but that isn't a protocol. It's a C API. Trying to funnel it over a network would be both extremely complex, and non-standard.

No, I was thinking of PKCS#7 which you can run over IP if you want. But it's a complicated set of standards and I'm not sure how they inter-relate. That's why I summarized them as PKCS-style protocols.

This is not some theoretical thing. You can buy these devices off the shelf. If you have worked with PKI you have seen them, or some variant thereof.

Re: Keyless SSL: The Nitty Gritty Technical Details

#57

Post by rdl »

dsl wrote: post #53
jgrahamc wrote: post #49

Earlier quoted context omitted.

You are correct that we deal with amplification/reflection attacks all the time. But what you don't see are the HTTP-level attacks where we put in place filtering rules in our WAF to block them. You don't see them because we mostly don't write about them. These attacks are different from the NTP/DNS style (which fill pipes) because they use server resources on the origin web servers. We need to be able to defend agai…

Sure, there are probably a handful of custom rules that some customers get, but like I said... most of your customers are paying for something that drops NTP/DNS and forwards HTTP/HTTPS. The standard WAF that all customers get scores pretty badly in independent tests: http://www.slideshare.net/zeroscience/cloudflare-vs-incapsul...

The WAF product has had a LOT of upgrades since that report, and has a huge update coming in Q4. That report is pretty out of date; I'd be happy to provide a test setup for Zeroscience to do a new analysis if they'd like, and am looking at how to do a continuous test/demo of the new WAF, because it's pretty interesting how it works.

When a source IP is shared (Tor exits, carrier NAT, etc.), trying to push as much into URL pattern vs source-IP filtering, for instance.

Re: Keyless SSL: The Nitty Gritty Technical Details

#58

Post by bifel »

wsh wrote: post #55
bifel wrote: post #54

I don't get it. What's the point in keeping the key secret from cloudflare whilst providing a key server signing everything it is asked to sign? Isn't this like "Sorry I don't trust you enough to provide you a key to my apartment. But if you need something, just ask the janitor, he'll open the door any time you want"?

If you no longer trust the person, it's easier to tell the janitor not to admit him than to rely on his returning the key (and any copies) or to change the lock on the apartment.

Is "changing the locks" (revoking the certificate) really so complicated that this "janitor-solution" is easier/cheaper/safer?

Re: Keyless SSL: The Nitty Gritty Technical Details

#59

Post by yalogin »

Why should all of these have a marketing spin to them? By that I mean a catchy name. Keyless SSL is very misleading. I guess after the stupendous success of the heartbleed bug marketing every one now wants a catchy name.

Having said that is it solving any security problems?

1. Companies don't have to give out their private key to Cloudflare but they still give them the encryption and hmac keys. So nothing really changed from a privacy or data protection point of view.

2. Now they opened up a new public API on the company's server for cloudflare to use the private key.

3. Is it simply to mitigate against another heartbleed kind of bug? Whats preventing the same bug to appear in the company's server?

Re: Keyless SSL: The Nitty Gritty Technical Details

#60

Post by snowwrestler »

bifel wrote: post #54

I don't get it. What's the point in keeping the key secret from cloudflare whilst providing a key server signing everything it is asked to sign? Isn't this like "Sorry I don't trust you enough to provide you a key to my apartment. But if you need something, just ask the janitor, he'll open the door any time you want"?

The more people who have a copy of a key, the more chances for a copy to be lost or stolen by a bad guy.
Post reply on HN