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

61–69 of 69 posts

Re: Keyless SSL: The Nitty Gritty Technical Details

#61

Post by peterwwillis »

infogulch wrote: post #51
peterwwillis wrote: post #50

Earlier quoted context omitted.

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

It's different in that now attackers can take down even cached sites. Before it was only dynamic content that was vulnerable. It's the difference between having your home page up and serving cached content, or your entire HTTPS site being down.

To give you an idea how this affects people in the real world, some websites will make thousands and even millions of dollars an hour in advertising revenue and paid services. They depend on CDNs to handle the traffic of that many users and make it seem like everything's moving smoothly even in the event of a temporary outage. If that site goes dark completely, they lose tons of revenue, and people get fired.

In another case, let's say a large financial institution, they might need to provide authoritative and highly sensitive information around the clock to organizations that basically control the flow of money around the world. Downtime isn't really an option. Without Keyless, this information stays up, cached. With Keyless, an outage can make this information disappear, with potentially far-reaching global financial repercussions.

To reiterate: if you don't use Keyless, your (HTTPS) static content stays up under an outage. If you do use Keyless, your (HTTPS) static content goes dark under an outage. (For https clients that don't have an existing valid session ticket on the CloudFlare server)

You can always use plain HTTP and avoid the outage, of course. But for large financial institutions that's probably not an option.

Also, please note that i'm really not trying to be inflammatory. I'm just pointing out that this is a new, additional point of failure and it can have real consequences for the content people provide over HTTPS.

Re: Keyless SSL: The Nitty Gritty Technical Details

#62

Post by snowwrestler »

peterwwillis wrote: post #40
infogulch wrote: post #38

Earlier quoted context omitted.

What? Increased attack surface? For the people that this matters, the alternative to this service is running your own https web server, where the server with the keys in its' memory is also running server apps that directly interface with the outside world, or at the very least a proxy through which all traffic is funneled. This system reduces the attack surface to the minimum possible: a single oracle that takes enc…

I'm talking about DDoS attack surface, not private key security attack surface. If you want DDoS protection, this scheme is less reliable than the alternative (having CloudFlare host the private keys). To get the most secure private key security, a system like this would be the least attack surface only if the keyserver is connecting to the http server . By having the http server connect to the keyserver you expose t…

If the http server is compromised you're screwed either way.

If the SSL key is on the http server when it get compromised, you've just lost your SSL key. Very bad!

If it's not, the http server could DDOS the key server. Less bad! Just change the key server address and point a new http server at it.

Re: Keyless SSL: The Nitty Gritty Technical Details

#63

Post by wsh »

bifel wrote: post #58
wsh wrote: post #55

Earlier quoted context omitted.

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?

The CA can revoke the certificate, but since revocation checking in browsers is neither universal nor reliable under attack, revocation isn't a completely effective way to recover from a compromised private key.

Re: Keyless SSL: The Nitty Gritty Technical Details

#64

Post by ctz »

xorcist wrote: post #56
ctz wrote: post #52

Earlier quoted context omitted.

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.

Yup, I know. My day job used to be writing firmware for nCipher/Thales HSMs :)

Re: Keyless SSL: The Nitty Gritty Technical Details

#65

Post by skuhn »

vader1 wrote: post #4

Interesting how they specifically refer to yesterday's discussion here on HN and over at Reddit, but don't go into the frequently mentioned complaint that despite not having access to the PK itself, Cloudflare can still intercept and modify all cleartext sent between the client and server, which for most intents and purposes means pretty much the same. Maybe not intentionally so, but it comes off as slightly misleadi…

This is something that I spent a lot of time on a few years ago.

Some of the HTTP accelerator servers I ran were in countries or sites that were more problematic than others, so it was desirable to not locate SSL keys on them. Instead of handling HTTP, the servers would become a TCP level proxy, and forward resp / req packets between a server with the SSL key and the client.

The biggest hurdle is that without being able to decrypt the incoming SSL, you can't know anything about the HTTP request -- including hostname or path. So you have to forward all of your received traffic to the same place, and you can only vary the destination based on the source IP that receives it.

IPs are limited. There is no way that Cloudflare could have even 1 IP for each of their customers in each of their sites around the world, it simply cannot be done.

There is lots of other common functionality that you lose (edge caching, cookie routing, etc.) but the inability to route at layer 7 is the big one.

Re: Keyless SSL: The Nitty Gritty Technical Details

#66

Post by infogulch »

peterwwillis wrote: post #61
infogulch wrote: post #51

Earlier quoted context omitted.

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…

It's different in that now attackers can take down even cached sites. Before it was only dynamic content that was vulnerable. It's the difference between having your home page up and serving cached content, or your entire HTTPS site being down . To give you an idea how this affects people in the real world, some websites will make thousands and even millions of dollars an hour in advertising revenue and paid services…

You make good points.

> It's the difference between having your home page up and serving cached content, or your entire HTTPS site being down.

To be fair, any clients with a valid session would see no difference between Keyless all the way down to plain HTTP (i.e. only static content). So the real difference between keyless and more typical setups is that new users can no longer see static content if the key server is down.

Given that the key server would see a vanishing fraction of the bandwidth and number of requests, in addition to its' extremely simplified and locked down API, I would guess that it's much more difficult to take down compared to a normal web server; you'd essentially have to take out the network equipment around it before it became overwhelmed itself. In addition, only a tiny fraction of legitimate packets would need to go through to be able to support a large number of clients. But perhaps I'm mistaken.

Now I'm curious how often this type of attack occurs, i.e. overwhelm the tunneled servers behind CloudFlare's back.

Re: Keyless SSL: The Nitty Gritty Technical Details

#67

Post by xorcist »

ctz wrote: post #64
xorcist wrote: post #56

Earlier quoted context omitted.

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.

Yup, I know. My day job used to be writing firmware for nCipher/Thales HSMs :)

Cool! We had those at a previous job. Good stuff.

Re: Keyless SSL: The Nitty Gritty Technical Details

#68

Post by ianlevesque »

icebraining wrote: post #41
ianlevesque wrote: post #36

Earlier quoted context omitted.

They actually do offer a service where they proxy your plain-text HTTP to end users as HTTPS and provide a certificate. It's extremely convenient.

Yes, but you still need to buy and give them a certificate, right? The question included "can offer SSL for free without buying certs", which is not possible, AFAIK.

No, they essentially add your domain to a list of domain names in their own certificate.

Re: Keyless SSL: The Nitty Gritty Technical Details

#69

Post by icebraining »

ianlevesque wrote: post #68
icebraining wrote: post #41

Earlier quoted context omitted.

Yes, but you still need to buy and give them a certificate, right? The question included "can offer SSL for free without buying certs", which is not possible, AFAIK.

No, they essentially add your domain to a list of domain names in their own certificate.

Really? And their CA allows that? That's amazing.
Post reply on HN