4 ms·
Still, does CloudFlare ever receive user cookies, e.g. my Hacker News cookies? A single weak spot in your cert management security practices (or a demand from
by sillysaurus2 13y ago
Still, does CloudFlare ever receive user cookies, e.g. my Hacker News cookies? A single weak spot in your cert management security practices (or a demand from a government) would compromise all of those thousands of certificates. And if you receive user cookies, then it seems true that anyone who has those certificates can obtain all user data from any of those websites.
I'm confused how it's possible to let anyone sign up for CloudFlare for free within minutes, while also generating a certificate unique to their website, signed by a CA, because a signed CA SSL cert always costs money. For a website like CloudFlare, that would be a significant cost, wouldn't it?
EDIT: I wrote my reply before your edit that gave the answer (yes, CloudFlare has all user cookies from all websites). Sorry.
However:
it's interesting that you bring this up because we are shortly going to announce a new offering where even if the government tried to compel us to give up a private key we would literally be unable to do so.
This would be illegal. The US government has already asserted multiple times that it has the authority to compel any US website to give up any keys it demands. You will suffer the same fate as Lavabit: to be fined >$1k per day until you comply, with penalties increasing until you're unable to cover the cost. So what's your plan?
- jgrahamc 13y agoWe don't offer SSL on the free plan. SSL certificates are only available on our paid plans (https://www.cloudflare.com/plans https://www.cloudflare.com/plans). Yes, cookies enter CloudFlare's network. They have to, but they are not stored or logged in any way. In fact, the entire HTTP/HTTPS request is processed in RAM without any permanent storage and only for the life of the request (i.e. for the time it takes to forward it). http://blog.cloudflare.com/what-cloudflare-logs http://blog.cloudflare.com/what-cloudflare-logs
- deleted 13y ago[deleted]
- jgrahamc 13y agoWe won't have the private key, it will be retained by the web site owner and will not be present on our systems. In fact, we will never have seen the private key at all. And don't worry about pestering me about CloudFlare and security. These questions and problems are things that we think about every day. We (and I) worry about which ciphers to use for TLS connections, the best way to secure our internal secrets, 2FA, how we ensure that the code running on our machines is our code and on and on. http://blog.cloudflare.com/red-october-cloudflares-open-source-implementation-of-the-two-man-rule http://blog.cloudflare.com/red-october-cloudflares-open-sour...
- sillysaurus2 13y agoDamn... 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 agoI'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 agoWhile 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!
- jgrahamc 13y agoEDIT: I wrote my reply before your edit that gave the answer (yes, CloudFlare has all user cookies from all websites). Sorry. One nuance to what you've written: we don't 'have' the user cookies, they pass through us as the request is forwarded on. They are not stored, period. it's interesting that you bring this up because we are shortly going to announce a new offering where even if the government tried to compel us to give up a private key we would literally be unable to do so. This would be illegal. The US government has already asserted multiple times that it has the authority to compel any US website to give up any keys it demands. We can't be compelled to give up something we don't have.