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

41–50 of 69 posts

Re: Keyless SSL: The Nitty Gritty Technical Details

#41

Post by icebraining »

ianlevesque wrote: post #36
icebraining wrote: post #32

Earlier quoted context omitted.

To serve SSL for your domain, Cloudflare needs a certificate for your domain issued by an accepted CA, which someone needs to buy. The only way for them to set that up would be to become a CA, get browsers to accept their master certificate and then issue their own certs for their clients.

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.

Re: Keyless SSL: The Nitty Gritty Technical Details

#42

Post by handsomeransoms »

buro9 wrote: post #22
vader1 wrote: post #15

Earlier quoted context omitted.

I'm not quite following how having just enough insights about the encrypted data to perform DDOS mitigation would be scarier than having full read- and write access to the cleartext. Thanks for the responses though, and definitely looking forward to those blogs.

You are implying something fundamental: that the encrypted traffic could be adequately analysed for insight without the need for decryption. Yet to do so would be to defeat SSL itself, or at least to declare it as insufficient to adequately protect secrets. What CloudFlare is doing isn't defeating SSL or any kind of attack on it. They are merely working around some prior limitations on requiring access to an organisa…

  > You are implying something fundamental: that the encrypted traffic could be adequately analysed for insight without the need for decryption.
  > Yet to do so would be to defeat SSL itself, or at least to declare it as insufficient to adequately protect secrets.
This is possible through HTTPS traffic analysis, see [0] and [1] for starters. Of course, it's much easier for Cloudflare to do analysis for DDoS protection if they have access to plaintext.

Whether this means that SSL is, as you say, "insufficient to adequately protect secrets" is an interesting discussion to have.

[0] http://arxiv.org/pdf/1403.0297.pdf

[1] http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-goo...

Re: Keyless SSL: The Nitty Gritty Technical Details

#43

Post by jessaustin »

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…

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 see much DOS potential there.

Re: Keyless SSL: The Nitty Gritty Technical Details

#44

Post by fathom108 »

justinsb wrote: post #3

To save people a long read, there's nothing particularly surprising in these details. The key is held by the origin; when a computation using the key is needed the origin is asked to perform it over a secure connection. They have improved support for session resumption in a distributed environment (which is even more important now that key computations are even slower), this is commonly done as closed-source, and Clo…

Oh well. Guess we'll have to wait for Homomorphic encryption:

http://en.wikipedia.org/wiki/Homomorphic_encryption

Re: Keyless SSL: The Nitty Gritty Technical Details

#45

Post by ehPReth »

kisielk wrote: post #39
ehPReth wrote: post #37

Sorry if I'm missing something, but shouldn't this be called "Keyless TLS" as CloudFlare uses TLS and not SSL for this program?

From the article: "This may seem confusing at first, but makes sense since TLS is just a minor update to SSL 3.0. Subsequent versions of TLS have followed this pattern. Since TLS is an evolution of the SSL protocol, people still use the terms TLS and SSL somewhat interchangeably."

Oops, must have missed that. Thanks! I'm personally a fan of using the new official name whenever possible but I understand the tradition/ingrained nature of SSL.

Re: Keyless SSL: The Nitty Gritty Technical Details

#46

Post by xorcist »

vader1 wrote: post #18
xorcist wrote: post #9

Earlier quoted context omitted.

They can manipulate traffic, but so can the bank's operations division. The fact that Cloudflare is a different organization makes contractual agreements much more important, but as long as they are in proper order the difference shouldn't be of importance to the end user.

The difference to the end user is that while the bank's operations division can only do this for a single website, Cloudflare can do so for 2 million of them.

That is indeed a difference, but perhaps not directly relevant to the bank's security.

For large scale traffic manipulation, Google is even better suited. They have arbitrary access to the DOM tree of over 10 million websites via Google Analytics, including several banks.

Re: Keyless SSL: The Nitty Gritty Technical Details

#47

Post by xorcist »

infogulch wrote: post #38
peterwwillis wrote: post #35

Earlier quoted context omitted.

You've hit on the most dangerous part of this whole scheme: increased attack surface. There is now a much higher likelihood of a successful attack taking down the site, due to the client needing to both open up and harden its keyserver on the internet (i'm presuming they don't have private connections between cloudflare and the customer site). And obviously if any hole is found in either the client's keyserver or the…

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…

No, the alternative in situations like these when you need the added security is to use an off the shelf HSM.

Re: Keyless SSL: The Nitty Gritty Technical Details

#48

Post by dsl »

jgrahamc wrote: post #5
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…

Because DDoS protection isn't just something you do at the network layer. It's important to be able to apply filtering at the "application" level.

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.

Re: Keyless SSL: The Nitty Gritty Technical Details

#49

Post by jgrahamc »

dsl wrote: post #48
jgrahamc wrote: post #5

Earlier quoted context omitted.

Because DDoS protection isn't just something you do at the network layer. It's important to be able to apply filtering at the "application" level.

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

Re: Keyless SSL: The Nitty Gritty Technical Details

#50

Post by peterwwillis »

jessaustin wrote: post #43
peterwwillis wrote: post #40

Earlier quoted context omitted.

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…

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 associated with various hosts under their domain and look at non-CloudFlare allocations. Or you could do a simple brute force search of DNS records (there's bound to be a DNS record for it so cloudflare can connect to it) and look for an interesting seeming host. Or you could look at the output of HTML for embedded hostnames in comments (pretty common for large sites). This is a very brief list of examples.

> Having learned the address of the private key server, how would an attacker proceed?

Once you have the keyserver address you can just DDoS it, and all of a sudden no new SSL handshakes can complete, meaning bye bye static content over SSL. The ISP'd have to null route all the DDoS traffic to the keyserver, which can take time. But that's just a network attack.

You can investigate further and attack the host/service. Maybe they forgot to whitelist the CloudFlare IPs and you have open access to the box via some random service, or the keyserver TLS port. Maybe you abuse BGP and find a way to spoof one of CloudFlare's IPs. Or maybe you social engineer somebody into adding a new address onto the stack of their IP whitelist. Or maybe it's "in the cloud" and you can attack the machine from the cloud provider's network.

Once you can connect, you can pick your poison with how you want to abuse or attack the machine, but there's almost no point when a plain-old DDoS will do.

All of these are the same attacks you'd use on any origin server for any CDN. The difference is that normally a CDN will keep serving cached static content if your origin goes down. With the keyserver down, you can't even serve cached static content, except for non-encrypted HTTP of course.

Post reply on HN