That is true. But it the user's main concern is the legs of network from their location out of a local untrusted network (such as communal wireless) or country, that is definitely better than nothing.
> XP still has 19% market share
I don't worry about the security of XP+IE users any more. Anyone still there has chosen against good advice to remain insecure. It is their choice when there are other options available (both browsers that support modern standards on XP, and alternate OSs), it is their choice to have the certificate warning and more iffy security when they hit a site that needs SNI.
> SSL can be difficult for website administrators to set up.
> For sites that require more advanced SSL configurations, CloudFlare supports custom certificates from any certificate authority, full end-to-end SSL with robust certificate checking...
Just, wow. TLS is NOT hard to setup for a website administrator. I think I just lost a ton of respect for CloudFlare. Granted, most threats would be between the client and CloudFlare anyway(that is to say, on the wrong side of the tracks), but still....
* "Flexible SSL" - encrypted from client to Cloudflare using Cloudflare's cert, unencrypted from Cloudflare to host.
* "Full SSL" - encrypted from client to Cloudflare using Cloudflare's cert, encrypted from Cloudflare to host using a different host self-signed cert.
* "Full SSL (strict)" - encrypted from client to Cloudflare using Cloudflare's cert, encrypted from Cloudflare to host using a different host CA-signed cert.
(http://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tech...)
* "Keyless SSL" - encrypted from client to Cloudflare using the customer host's cert. Cloudflare doesn't have the customer's cert private key. They contact the customer's host for a session key for each session, and use this to encrypt from the client to Cloudflare. They decrypt at Cloudflare, and re-encrypt for the trip to the customer's host.
With the first three, you can see in the browser that this is happening. The host will be identified as "cloudflare.com" in the certificate. With "Keyless SSL", which is basically MITM with active cooperation from the end host, it looks at the browser end like you're encrypted end to end, but you're not.
One assumes that all of these are being "lawfully intercepted".
That's the problem. If you only use SSL/TLS for security-critical pages where there's a login or a credit card, you don't need some massive cloud-based service to cache your stuff. Many sites still use "transferring to secure site for shopping cart checkout". That's fine. If you use SSL/TLS for everything, now you have a load problem on the secure infrastructure.
That's why "SSL Everywhere" is security theater. To have "security" on pages that don't need to be secure requires weakening security on the pages that do.
Nah, you can still have separate secure domains with EV certs for taking credit cards. That way your customer's browsing habits and product preferences are protected from snooping by their ISP, the page assets are still cached and DDOS protected, and the credit card data is still sent to a separate domain without an intermediary.
The only thing still to worry about is your caching provider sending maliciously modified content that bypasses your secure domain.
EDIT: just read your answer below, my comment is off-topic. Sorry.
It really is – you might just be living in a bubble of competence!
I've got years of experience as a developer and sysadmin, and I still sometimes struggle to get SSL working correctly on a site. Sure, getting and installing a cert is fine – but the mess of making sure that third-party services don't break, and that redirects aren't messed up, and that other virtual hosts don't break… it can be a time-consuming effort, and probably difficult for someone with less experience.
Cloudflare have been pretty transparent with the service they're offering, so I find it hard to see this as a bad thing.
Regarding setting up SSL I'm reminded of this: https://news.ycombinator.com/item?id=8471877
This is doubly annoying for checking blogs that require https and redirect http. I have no way to check their RSS feeds.
Multi-domain certs are used because IPv4 space is full and Windows XP doesn't support Server Name Indication, which allows a unique cert for different domains at the same IP address. So if you want SSL on a shared IP address, and need to support good old IE6 over IPv4, multi-domain certs are necessary. XP still has 19% market share on line, as of October 2014. Everything else has supported SNI since 2007 or so.
I have a paper on this:
http://john-nagle.github.io/certscan/whoamitalkingto04.pdf
This identifies all the major front-end services using shared SSL certificates. Cloudflare has 36,280 second level domains tied to "*.cloudflare.com". Incapsula, the DDOS protection service, has 1471. Once you're past the top 20 such services, no site has more than about 100. Once IE6 has died off, the CAs can stop issuing certs containing unrelated domains. But not yet.