Now that CloudFlare offers potentially-insecure free SSL to all users, would a new HTTP header be useful?

Question

I'm not sure where to post this, so I figured I'd just post it here.

CloudFlare is now offering free SSL to all sites. There are two different types of SSL connections, however. There's "Flexible SSL" which runs HTTPS on the Client <=> CloudFlare connection, but regular HTTP on the CloudFlare <=> Server connection. While this is certainly better than nothing, it's misleading to the user who thinks that his or her data is entirely encrypted for as long as it's on the wire.

There's also "Full SSL" which is secure for the entire User <=> CloudFlare <=> Server connection.

Therefore, I propose a new HTTP header named something like X-Proxy-Security which could indicate to the user-agent how the proxy is handling secure connections. Its value could be something like end-to-end for full end-to-end encryption or client-to-proxy for connections that are only secure between the client and the proxy. The header ideally shouldn't contain any specific CloudFlare references since there are plenty of HTTP proxies like CDNs and services similar to CloudFlare.

If it were implemented, browsers wouldn't know how to handle it at first so nothing would change. However, browser extensions could be developed to relay the status to the user. Browsers could eventually implement some form of indicator similar to how they indicate mixed content or whatever currently.

Would this work? How would we push to implement it?

Answer 1

This is part of why you check who the SSL cert is from. If it isn't the site you are trying to access, get the hell out of dodge. If cloudssl is using a root certificate in an insecure way, such as generating certs for each site on demand, then people can simply reject the authorization of that root certificate. Problem solved.

A new http header for this is not helpful, is overkill and would still be open to abuse as nothing guarantees that someone would properly set it. The same level of detail could just as easily be included in the certificate itself without need for new headers.

Answer 2

Your header would only be marginally useful in this situation, and not at all useful in most other situations. Just for some examples:

If Cloudflare loaded the actual site over https, but it was on a self signed unverified cert, would it still get the end-to-end header?

If it was a self signed cert, but the fingerprint of the cert was manually verified by cloudflare as something that belongs to the site, does that get the end-to-end header?

unrelated to cloudflare, what about a SSL terminating load balancers? Technically that should be a 'client-to-proxy' header setting, but frankly why would you as a user care that your SSL was terminated on my load balancer that my server is plugged directly in to? Maybe if my SSL terminating load balancer was forwarding the rest of the connection over an insecure network, but then you have to define 'secure network'.. What if nginx is forwarding the connection via http over a vpn?

Theres just way too many different ways to configure a network, and none of them are things clients have much reason to care about.

I think what cloudflare is doing is fine here. Yes you should have them pull your site over a secure connection as well, but even when they don't its no different than any other SSL site.

If you look at say a forum or even stackoverflow, when you load it over SSL its sent to you over an encrypted link, but for all you know the content was pulled over an unencrypted connection to a database that holds all the content, the content of which could have been submitted to over http requests.