Announcing Keyless SSL • Hacker News Board

Re: Announcing Keyless SSL

#171

Post by pyre » Fri, Sep 19, 2014, 12:43 AM UTC

kansface wrote: post #170

lucb1e wrote: post #103

For those who want to understand how it works (it took me a minute, so I'll try to explain it simpler): In simplified terms, the server usually stores a public and private key, and sends the public key to the client. The client generates a random password, encrypts it with the server's public key, and sends it to the server. Only anyone with the private key can decrypt the message, and that should only be the server.…

Is this not subject to side channel attacks (for recovering the key)? Also, whats the point if you are letting a third party read all of your traffic at any rate?

For starters, you can move away from CloudFlare, and you don't need to worry about issuing a new key-pair (b/c CloudFlare, or a unscrupulous CloudFlare employee could use the old private key to impersonate your site).

Re: Announcing Keyless SSL

#172

Post by pyre » Fri, Sep 19, 2014, 12:52 AM UTC

lucb1e wrote: post #163

mikeleeorg wrote: post #156

Earlier quoted context omitted.

Thanks for explaining this. I would also love to read your opinion. Would you be willing to share it in a separate comment? (And hopefully it doesn't incur any downvotes and readers understand it is just an opinion.)

Sure. TL;DR: I think it's mostly useless. From an engineering perspective this is a creative way to circumvent management's requirements ("our encryption keys must be kept on premises"), but otherwise I don't see the value. Let's first see what the problem is with the old method, storing the private key on the Cloudflare server: 1. Cloudflare can read all traffic. 2. Cloudflare can read traffic they can intercept, ev…

There's also:

- If you discontinue using CloudFlare, you don't need to generate a new key-pair, and all of the issues associated with the infrastructure for revoking the current key-pair.

- There is also this: https://news.ycombinator.com/item?id=8336041 , which mentions protection against key-recovery due to Heartbleed-type bugs, which is true. If the SSL-stack is attacked, the attacker only has the same access that CloudFlare does. They can't recover the keys from the key server.

Re: Announcing Keyless SSL

#173

Post by Gigablah » Fri, Sep 19, 2014, 2:09 AM UTC

ilaksh wrote: post #153

jessaustin wrote: post #143

Earlier quoted context omitted.

GP comment is too generalized to be constructive. That is especially so in this discussion of a specific network security platform, which presumably has specific faults that may be discussed instead of generalities like "belief systems" and "human lives".

You're right, I'm sure none of my general concerns about completely false belief systems and human lives are worth being viewed by any readers in this thread. My comment also may be a little bit difficult to contextualize or disconcerting for readers. Best to keep downvoting it so that it disappears.

Passive-aggressiveness is not an effective persuasion technique.

Re: Announcing Keyless SSL

#174

Post by zobzu » Fri, Sep 19, 2014, 5:16 AM UTC

agwa wrote: post #94

zobzu wrote: post #85

Earlier quoted context omitted.

one of the issues with that is latency, i wonder how they work around that. or maybe they just dont care for latency

The handshake is probably not much slower than it would be if the web browser were connecting directly to the bank, since there is only one round trip with the key server per handshake, and the latency between Cloudflare and web browsers tends to be pretty low since Cloudflare has so many POPs.

yes, but over thousand of connections its significant. what was a millisecond or less becomes 20ms. so 20x slower. not sure how much impact this has in real life, but this is one of the issue with this design (also one of the reason is rarely implemented like this but with HSMs instead)

Re: Announcing Keyless SSL

#175

Post by buro9 » Fri, Sep 19, 2014, 6:29 AM UTC

willvarfar wrote: post #138

personZ wrote: post #119

Earlier quoted context omitted.

Now you don't want to hand over this private key to Cloudflare if you don't need to, because then they can read all traffic. Generally the key you would give them is for, and limited to, the resources that they cache/reverse proxy, so the same "read all traffic" concern exists. What Cloudflare did is essentially, as others have mentioned, PKCS11 over the internet. PKCS11 is an existing, very well proven technique of…

It is very obvious... In hindsight?

Sometimes the innovation is merely being able to rephrase the apparently impossible question into the one that has an obvious answer.

It's worth remembering, no-one else was offering this or doing this... no-one else had phrased the problem such that the answer (even though it was known) became apparent.

Re: Announcing Keyless SSL

#176

Post by Perseids » Fri, Sep 19, 2014, 6:40 AM UTC

ChuckMcM wrote: post #139

personZ wrote: post #119

Earlier quoted context omitted.

Now you don't want to hand over this private key to Cloudflare if you don't need to, because then they can read all traffic. Generally the key you would give them is for, and limited to, the resources that they cache/reverse proxy, so the same "read all traffic" concern exists. What Cloudflare did is essentially, as others have mentioned, PKCS11 over the internet. PKCS11 is an existing, very well proven technique of…

I think the exaggeration is because its a sales pitch, but it illustrates an important concept -- doing something "known" but in a generic way can be more valuable than having a proprietary solution. Of course someone could come up and offer a 'Cloudflare' box that just does key sequestration and sell that. And while I think banks and others will find this useful, its even more useful if I can do it from a far away p…

> When you create an SSL connection in Europe to a west coast server there are a number of round trips. If those can be avoided you can cut the latency of the transaction. That is a good thing too.

Note that this will at most cut the connection setup time by half, as your premaster secret (RSA) or handshake data (ephemeral DH) still has to cross the Atlantic and get back to you (and the TLS handshake has 2 roundtrips).

Furthermore, because of

> Generally the key you would give them is for, and limited to, the resources that they cache/reverse proxy,

all dynamic data still is supposed to come from your server. So the browser will have to wait for that, while everything from the European mirror is cached anyway.

Re: Announcing Keyless SSL

#177

Post by Perseids » Fri, Sep 19, 2014, 6:56 AM UTC

lucb1e wrote: post #163

mikeleeorg wrote: post #156

Earlier quoted context omitted.

Thanks for explaining this. I would also love to read your opinion. Would you be willing to share it in a separate comment? (And hopefully it doesn't incur any downvotes and readers understand it is just an opinion.)

Sure. TL;DR: I think it's mostly useless. From an engineering perspective this is a creative way to circumvent management's requirements ("our encryption keys must be kept on premises"), but otherwise I don't see the value. Let's first see what the problem is with the old method, storing the private key on the Cloudflare server: 1. Cloudflare can read all traffic. 2. Cloudflare can read traffic they can intercept, ev…

> Session reuse makes this somewhat less of a pain, as the keyserver need not be queried for repeated https connections.

If a DOS is actively attacking the bandwidth of the keyserver, none of the attacking connections will reuse old sessions, though.

Re: Announcing Keyless SSL

#178

Post by Perseids » Fri, Sep 19, 2014, 6:59 AM UTC

personZ wrote: post #119

lucb1e wrote: post #103

For those who want to understand how it works (it took me a minute, so I'll try to explain it simpler): In simplified terms, the server usually stores a public and private key, and sends the public key to the client. The client generates a random password, encrypts it with the server's public key, and sends it to the server. Only anyone with the private key can decrypt the message, and that should only be the server.…

Now you don't want to hand over this private key to Cloudflare if you don't need to, because then they can read all traffic. Generally the key you would give them is for, and limited to, the resources that they cache/reverse proxy, so the same "read all traffic" concern exists. What Cloudflare did is essentially, as others have mentioned, PKCS11 over the internet. PKCS11 is an existing, very well proven technique of…

> Generally the key you would give them is for, and limited to, the resources that they cache/reverse proxy

That got me wondering: Why don't attackers then only DOS the dynamic pages? Those that can't be migrated easily, like the login?

Re: Announcing Keyless SSL

#179

Post by rdl » Fri, Sep 19, 2014, 7:03 AM UTC

Perseids wrote: post #178

personZ wrote: post #119

Earlier quoted context omitted.

Now you don't want to hand over this private key to Cloudflare if you don't need to, because then they can read all traffic. Generally the key you would give them is for, and limited to, the resources that they cache/reverse proxy, so the same "read all traffic" concern exists. What Cloudflare did is essentially, as others have mentioned, PKCS11 over the internet. PKCS11 is an existing, very well proven technique of…

> Generally the key you would give them is for, and limited to, the resources that they cache/reverse proxy That got me wondering: Why don't attackers then only DOS the dynamic pages? Those that can't be migrated easily, like the login?

The dynamic pages still go through CloudFlare; there's a Web Application Firewall which can block abuse directed at a specific URL, pattern, etc. The cache is only one part of the DDoS mitigation.

(We've been working on a lot of great updates to the WAF for just this kind of thing)

Generally with CloudFlare people put as much of their site behind the CloudFlare proxy as possible, for origin-hiding and other reasons, even if we can't cache it (yet).

Re: Announcing Keyless SSL

#180

Post by lucb1e » Fri, Sep 19, 2014, 7:06 AM UTC

Perseids wrote: post #177

lucb1e wrote: post #163

Earlier quoted context omitted.

Sure. TL;DR: I think it's mostly useless. From an engineering perspective this is a creative way to circumvent management's requirements ("our encryption keys must be kept on premises"), but otherwise I don't see the value. Let's first see what the problem is with the old method, storing the private key on the Cloudflare server: 1. Cloudflare can read all traffic. 2. Cloudflare can read traffic they can intercept, ev…

> Session reuse makes this somewhat less of a pain, as the keyserver need not be queried for repeated https connections. If a DOS is actively attacking the bandwidth of the keyserver, none of the attacking connections will reuse old sessions, though.

True, but I meant for the performance for legitimate users.