So banks and other cloudflare can keep their private keys local. And cloudflare has an encrypted channel to the their customer’s private key “server” for signing SSL requests at the appropriate point.
The customer keeps “control” of their keys, which is clearly good. Instead they expose a “key server” on a secure channel to cloudflare.
But, oh man, if you can hack cloudflare and figure out how to send requests to their customer’s private key servers, you can impersonate a lot of big customers. I’m not sure how the customers could easily detect that cloudflare had been hacked and decide to turn off their key servers.
Disclaimer: I work at CloudFlare as a systems engineer working on the
security side, but I didn’t work on the keyless project.
There’s some projects in the works (which comprise the bulk of what I
work on) to improve this situation. Keyless was the first step in a
series of initiatives.
Previously, we were keeping those keys on our servers (and still do for
most customers), so the threat of an adversarial MitM still exists in
that regard whether you’re using keyless or not. It does mean that if
such an MitM is detected, the private key doesn’t need to be revoked.
Hopefully this technology will percolate down into “regular” nginx so no one ever has a private key on a public facing web server. Keeping keys on a hardened box will be a win for everyone.
This change seems a lot like moving from keeping your PGP private key on your laptop to keeping it on a smartcard - if your laptop is compromised while your smartcard is attached (and your pin is cached by gpg-agent), for example, then an attacker can make use of those keys. Still, this is better than an attacker being able to duplicate your private key and make use of it from some other system at some other time. Not a panacea, but a fairly substantial improvement over the status quo.
It’s sort of similar, except that with a smartcard there are better side
channel attacks for recovering key material (i.e. via DPA). However, if
you’re restricting the threat model of this analogy to recovering key
material via memory or disk, this is fairly accurate. An attacker who
could scan memory would be able to retrieve a locally-stored PGP key on
decrypt; in a smartcard, the key never leaves the card, meaning there’s
no key material to be found in memory. If you were running keyless and
another Heartbleed-level bug was found that allowed recovery of
in-memory key material remotely, you wouldn’t lose your private key.
So banks and other cloudflare can keep their private keys local. And cloudflare has an encrypted channel to the their customer’s private key “server” for signing SSL requests at the appropriate point.
The customer keeps “control” of their keys, which is clearly good. Instead they expose a “key server” on a secure channel to cloudflare.
But, oh man, if you can hack cloudflare and figure out how to send requests to their customer’s private key servers, you can impersonate a lot of big customers. I’m not sure how the customers could easily detect that cloudflare had been hacked and decide to turn off their key servers.
Disclaimer: I work at CloudFlare as a systems engineer working on the security side, but I didn’t work on the keyless project.
There’s some projects in the works (which comprise the bulk of what I work on) to improve this situation. Keyless was the first step in a series of initiatives.
Previously, we were keeping those keys on our servers (and still do for most customers), so the threat of an adversarial MitM still exists in that regard whether you’re using keyless or not. It does mean that if such an MitM is detected, the private key doesn’t need to be revoked.
Yes. That’s certainly a great benefit.
This, and not having the SSL private key operations in memory on the public-facing machine, were two big reasons for us to build this.
Hopefully this technology will percolate down into “regular” nginx so no one ever has a private key on a public facing web server. Keeping keys on a hardened box will be a win for everyone.
This change seems a lot like moving from keeping your PGP private key on your laptop to keeping it on a smartcard - if your laptop is compromised while your smartcard is attached (and your pin is cached by gpg-agent), for example, then an attacker can make use of those keys. Still, this is better than an attacker being able to duplicate your private key and make use of it from some other system at some other time. Not a panacea, but a fairly substantial improvement over the status quo.
It’s sort of similar, except that with a smartcard there are better side channel attacks for recovering key material (i.e. via DPA). However, if you’re restricting the threat model of this analogy to recovering key material via memory or disk, this is fairly accurate. An attacker who could scan memory would be able to retrieve a locally-stored PGP key on decrypt; in a smartcard, the key never leaves the card, meaning there’s no key material to be found in memory. If you were running keyless and another Heartbleed-level bug was found that allowed recovery of in-memory key material remotely, you wouldn’t lose your private key.