It's a "better than nothing" option, as there are a slightly higher number of actively exploited attack vectors that apply to the client to CDN connection than the CDN to origin server, such as "free" wifi that injects ads, malicious ISP DNS, and the like. But it's not actually secure, as the origin server to CDN connection could be tampered with, and just because there are fewer active attacks that would be likely to affect that connection right now, doesn't mean that someone won't come along later and hijack such a connection.

CloudFlare offers other TLS options that do include encryption and authentication between the origin server and CDN, but they do require that you set up a certificate on your server, so if all you're trying to do is enable TLS (and don't care about the CDN), just installing a cert on the origin server and using TLS is probably a simpler option that using CloudFlare.

It's great that shared web hosting providers and others are starting to make it easy to acquire and install a certificate, but that hasn't always been the case.

EDIT: We also provide an API that will provision a free certificate for your origin: https://blog.cloudflare.com/cloudflare-ca-encryption-origin/. The certificate is optimized for communication with our edge (essentially just as small a chain as possible, as we don't need the intermediate to walk to the root). Either that or use certbot from EFF/Let's Encrypt.

Troy Hunt (OP) discusses this at length in this post => CloudFlare, SSL and unhealthy security absolutism https://www.troyhunt.com/cloudflare-ssl-and-unhealthy-securi...

End users won't be configuring their own servers anyway. At best they'll get a cPanel (which using AutoSSL, can then support Let's Encrypt).

    location / {
     proxy_pass http://localhost:8082;
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header X-Forwarded-Port 443;
     proxy_set_header X-Forwarded-Proto $scheme;
   }    

Any host that still requires a dedicated IP for https is woefully out of date.

May be true in a perfect world but this is my web host (bluehost):

>> Note: Since SSL Certificates are Domain/IP specific, you must first Purchase a Dedicated IP before purchasing or having an SSL Certificate installed on your account. They will NOT work with a shared IP address.

I'm pretty sure a lot of other hosting services still go that route.

Bluehost US doesn't seem to, as you indicate - https://my.bluehost.com/cgi/help/473

I'm not sure whether they just don't support SNI yet, or whether they are artificially enforcing this restriction so that they don't have to deal with IE6 not working.

Edit:

A quick search seems to indicate that the only typical consumer facing system that doesn't support SNI is IE on Windows XP. It's pretty safe to have a catch-all bucket that informs such users to use a modern, security patches including browser or to upgrade to a different OS.

Eventually old clients have to be let go of, maintaining compatibility for them degrades everyone else's security.