Of course using HTTPS is no guarantee that the site doesn't leak your data in any other way. But never before has it been this easy to create a false sense of security: give the impression that connections to your site are encrypted, while in reality it's plaintext for half of the route.
I think this will ultimately dilute the value of HTTPS as we know it, and can only hope that it will lead to the adoption of better alternatives.
I agree that this false sense of security is troubling. Many inexperienced site owners will think setting up Flexible SSL with Cloudflare is all they need to do. And it is unclear if the enduser has any way to see if the site they are connecting to is using Flexible or Full SSL.
However, in the announcement Cloudflare did say:
" Later today we'll be publishing a blog with instructions on how to do that at no cost. Once you've installed a certificate on your web server, you can enable the Full or Strict SSL modes which encrypt origin traffic and provide a higher level of security."
So this gives me a lot of hope that end to end encryption will proliferate.
What I dont understand is how they will be doing this at no cost. It looks like the certificates being issued automatically are to "xxxxxx.cloudflare.com", and not to the origin domain. Perhaps to get Full SSL you will have to enroll via Cloudflare's website to get a separate SSL that is for your site. This could then be verified the traditional way for Domain Validation certs.
Globalsign and Comodo seem to be the two providers for this.
> What I dont understand is how they will be doing this at no cost.
The same way that they're doing the first-mile encryption at no cost, by partnering with a CA that will sign certificates for free. StartSSL (http://www.startssl.com/) has been signing certs at no cost for years.
The marginal cost for a CA to sign an additional cert is negligible, particularly when there's no customer support involved (i.e. Cloudflare customers won't be calling Comodo or Globalsign's support numbers).
> It looks like the certificates being issued automatically are to "xxxxxx.cloudflare.com", and not to the origin domain.
Not having one in front of me, I can't say for sure, but they have to sign the cert for the origin domain or the browser wouldn't give you a padlock when you went to the origin domain. Certs may contain extended Subject Alternative Name fields that include other hostnames for which the cert should be considered valid. I'm guessing they're using something like this to add the origin domain alongside the xxxx.cloudflare.com domains. This is traditionally how you can have a single cert which works for both the root domain as well as the "www" version of the same (i.e. yourdomain.com and www.yourdomain.com use the exact same cert).
> Not having one in front of me, I can't say for sure, but they have to sign the cert for the origin domain or the browser wouldn't give you a padlock when you went to the origin domain.
Correct and under this scheme you wouldnt have a HTTPS connection with the origin site by default. The automatic configuration of Universal SSL is their "Flexible SSL" set up, where Cloudflare communicates with the origin server unsecured, but the connection between the client and Cloudflare is secured via a generic SSL issued to a subdomain at Cloudflare specific to each user account/domain.
If users tried to hit the site directly (such as when Cloudflare throws up those overload errors where you are able to circumvent their network) they would not get an encrypted connection.
If the customer then sets up a certificate on their own server then they will have a "Full SSL" connection, aka end-to-end encryption. The details on how this can be set up for free are forthcoming from Cloudflare.
There seems to be three ways of doing this: Their contact with Comodo/Globalsign also allows for more certificates issued directly to the origin domain; the origin domain will use a self-signed certificate which Cloudflare's network will trust (also will keep the origin domain reliant on Cloudflare to get trusted HTTPs); or they could be using StartSSL's free certs but given their partnership with Comodo/Globalsign this is unlikely.
Actually, that's a good model. It would have kept the memory (and code execution domain) of the application server independent from the memory of the SSL terminator during Heartbleed. If you terminate SSL on the same box as your app server you're putting many eggs into one basket.
Except that didn't really make much of a difference in the case of heartbleed. The information was still in memory decrypted, before it was encrypted by the front end, so an attacker could get the decrypted content, which may include users usernames/passwords and all that fun stuff.
Yes, you could get the data going to and from the clients, which is most of the important user data. The big problem is when your SSL/http/whatever is being terminated on the app server itself, exposing things like database access, SANs, etc.
No, it wouldn't expose those things. It would only expose things that OpenSSL itself had allocated/deallocated in that single process due to the way it was saving memory allocations for later re-use...
You're right. I meant in the case of a code execution exploit in the openssl layer, those things would be exposed if they were all on the same host/network.
I think this will ultimately dilute the value of HTTPS as we know it, and can only hope that it will lead to the adoption of better alternatives.