111–120 of 190 posts
And my patch for OpenSSL that does the same thing: https://gist.github.com/indutny/1bda1561254f2d133b18 , ping me on email if you want to find out how to use it in your setup.
Earlier quoted context omitted.
Please remember that CloudFlare is a sort of reverse proxy with some network protections and enhancements. If your infrastructure is unavailable, users won't get content anyway, SSL or not.
CloudFlare can serve cached responses in the event that your origin server is unavailable. This is particularly useful for static websites, but that's not the most common use case.
I guess technically the TLS-secured static content would now be at more risk than it was before, when the cached content would have been served. But existing session tickets would probably be honored, so only new clients would get rejected. Still, it's a tradeoff some people would probably be fine with.
Ehh... I'd say Keyless SSL implements the opposite of that principle: encryption terminates with CloudFlare but authentication terminates in some bank.
Earlier quoted context omitted.
Would it be enough to simply only allow connections from Cloudflare IP addresses?
As Google and Yahoo will tell you after they found out the US government broke into their dedicated lines between data centers... No. It must be encrypted at every transfer without exception.
So CloudFlare won't get your private key, but will still get to see unencrypted plaintext for all traffic? Sounds like a huge improvement...
Imagine an internet user who uses online banking with one of these banks; registered his domains with Namecheap; keeps some bitcoins at Coinbase; pseudonymously frequents Reddit; and posts anonymously at 4chan every now and then.
By merely passively eavesdropping on all traffic from and to your IP address, Cloudflare can build a profile that links your real world identity to all your Reddit posts you thought were anonymous; to the naughty threads you visited on 4chan; to the amount of money in your bank account; and to the domains and bitcoin addresses you own.
This is something that neither your ISP or any of those individual site owners could ever do, and which might even make the NSA a bit jealous. Now consider what Cloudflare could do on your behalf (and make it look like it was you) if, say, a disgruntled employee was actively out to get you.
I'm not at all saying that there is any reason to distrust Cloudflare, but is it not an enormous amount of power to place in the hands of one entity? Even more so than we do with parties like Google or Facebook, which get immensely more scrutinized over it?
And my patch for OpenSSL that does the same thing: https://gist.github.com/indutny/1bda1561254f2d133b18 , ping me on email if you want to find out how to use it in your setup.
No disrespect meant, but from a security perspective the idea of patching security-critical software with a patch from a stranger on the Internet is kind of crazy, isn't it?
Earlier quoted context omitted.
And that's why regulations make it almost impossible for banks to use CloudFare. But CloudFare sees that as a problem, and makes some effort to create a loophole. You can't claim that this improves the bank clients' security. It's clearly worse than doing nothing.
Think of it as a compromise: You can leverage CloudFlare's CDN to mitigate DDoS and other sorts of nasty attacks AND assure TLS is used with every connection, without giving up your RSA key. "It's clearly worse than doing nothing." It's not very clear to me. Please explain.
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.…
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 sequestering the key in a hardware device, that hardware device doing what Cloudflare is moving to the client location here. It's neat enough, but they seem to kind of exaggerating the innovation a bit.
How does this architecture address PFS? I'm guessing a future version would require the exchange of DH private key to make it work...
Although the diagrams in the blog post show the non-PFS RSA handshake, I'm sure the architecture already supports the PFS DH handshake too.