4 ms·

Damn... I might lose my account for deleting that comment (I promised the mods I wouldn't ever delete a comment that had a reply, since I did that way too exces

Damn... I might lose my account for deleting that comment (I promised the mods I wouldn't ever delete a comment that had a reply, since I did that way too excessively in the past). I deleted it because you'd already answered my question in a separate reply. Whoops. I hope they understand. Anyway, how can you generate HTTPS traffic without the private key? That seems to make no sense on a technical level. Really cool concept if that's possible.

jgrahamc 13y ago
I'll answer your question on HTTPS in a couple of months with a blog post and an open source implementation. Sorry to be cryptic but we are beta-testing right now with folks and I can't go into more detail even though I'm itching to flip the switch on Github that changes the repo from private to public.
- sillysaurus2 13y ago
  While this initially struck me as black magic, I think I've figured out how it's possible: I'm guessing that you somehow take advantage of perfect forward secrecy. PFS works by constantly "cycling" the encryption key in memory so that each packet is signed by the next iteration of the key, and the previous key is erased. Since SSL has support for PFS, I'm guessing it works like this: You have the website owner store the cert on their servers. Then you issue a request to the website owner, asking them to transmit their initial private key to you. (This would be the most vulnerable part of this new setup, but it could be done reasonably securely.) Once you receive their private key, you use it to generate HTTPS traffic on the website owner's behalf. And since you're using PFS, then it doesn't matter if anyone obtains that key: every packet you send will cause PFS to cycle the current key (generating a new one) and erase the previous key. Really clever! It's a little worrisome that CloudFlare will be issuing automated requests to website owners asking them for their initial private key (I'm absolutely certain you're going to do that, because otherwise your proposal is impossible) so I'll be curious to find out what steps you'll take to make it very difficult for an attacker to impersonate CloudFlare and request it, or MITM you and intercept it. But, this is wonderful progress. Ultimately, that will be the logical response: to MITM you and snag every private key the moment you request it. But at least it'd no longer be possible for a court to demand you give up a static, unchanging key, which is a huge step forward. Plus it might take an unreasonable amount of resources to set up such an MITM attack... but it may become a realistic concern once CloudFlare begins powering most of the internet (which seems likely). And I just want to say: thank you for working so hard on this problem!
  - nitrogen 13y ago
    If I understand PFS and your idea correctly, the master site wouldn't need to send its RSA or ECDSA private key to CloudFlare, just an ephemeral connection-specific key once it has been negotiated with the master. I haven't thought enough yet to know if that provides additional security, or whether it cancels out the benefit of CloudFlare's caching.

jgrahamc 13y ago

I'll answer your question on HTTPS in a couple of months with a blog post and an open source implementation. Sorry to be cryptic but we are beta-testing right now with folks and I can't go into more detail even though I'm itching to flip the switch on Github that changes the repo from private to public.

sillysaurus2 13y ago
While this initially struck me as black magic, I think I've figured out how it's possible: I'm guessing that you somehow take advantage of perfect forward secrecy. PFS works by constantly "cycling" the encryption key in memory so that each packet is signed by the next iteration of the key, and the previous key is erased. Since SSL has support for PFS, I'm guessing it works like this: You have the website owner store the cert on their servers. Then you issue a request to the website owner, asking them to transmit their initial private key to you. (This would be the most vulnerable part of this new setup, but it could be done reasonably securely.) Once you receive their private key, you use it to generate HTTPS traffic on the website owner's behalf. And since you're using PFS, then it doesn't matter if anyone obtains that key: every packet you send will cause PFS to cycle the current key (generating a new one) and erase the previous key. Really clever! It's a little worrisome that CloudFlare will be issuing automated requests to website owners asking them for their initial private key (I'm absolutely certain you're going to do that, because otherwise your proposal is impossible) so I'll be curious to find out what steps you'll take to make it very difficult for an attacker to impersonate CloudFlare and request it, or MITM you and intercept it. But, this is wonderful progress. Ultimately, that will be the logical response: to MITM you and snag every private key the moment you request it. But at least it'd no longer be possible for a court to demand you give up a static, unchanging key, which is a huge step forward. Plus it might take an unreasonable amount of resources to set up such an MITM attack... but it may become a realistic concern once CloudFlare begins powering most of the internet (which seems likely). And I just want to say: thank you for working so hard on this problem!
- nitrogen 13y ago
  If I understand PFS and your idea correctly, the master site wouldn't need to send its RSA or ECDSA private key to CloudFlare, just an ephemeral connection-specific key once it has been negotiated with the master. I haven't thought enough yet to know if that provides additional security, or whether it cancels out the benefit of CloudFlare's caching.