Hacker News Reader

Comment by spacefight | Hacker News Reader

Same thought here. And what if that connection breaks? Another single point of failure?

Multiple connections between CloudFlare and the Keyless SSL Server running at the customer site. Connections are reused, pipelined, load balanced etc.

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

The customer site now is responsible for providing key signing in a highly available fashion. It makes sense they would need to spend more (probably no more than for an hsm) to ensure the connection never goes down. If you can take down the connection from Cloudflare to the customer site, their website goes down.

I would also observe that given the constraint that the customer doesn't want to actually give out their private key (and nobody should be willing to give it out, really...), this is the minimal possible maintenance burden they could possibly incur. Yes, the customer has to do something, but we already take that as a given when we say we won't hand out the private key. If the customer wants to have the responsibility, being able to reduce that cost to the bare mathematical minimum is a big deal.

Key services are used to kickstart the SSL connection, not support it the whole way through (I believe?), so the 'load' is SIGNIFICANTLY less than terminating the entire connection for the whole session.

We don't expect there to be a cap-ex spend need here because we will be offloading most of the SSL processing to our servers (as well as offloading other parts of the web session).

Reply on news.ycombinator.com