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?

  • Server-side HTTP proxies are hardly uncommon, although this is the first time a widely-used one offered free SSL to all users. Security is only as good as its weakest link, and it would certainly be nice to know if the data you're transmitting is ever being sent in the clear. – Dr. McKay Sep 29 '14 at 17:35
  • SSL added and removed here :) – CodesInChaos Sep 29 '14 at 18:15
  • 6
    If you want to signal something SSL related, the SSL handshake looks like a better place than an http header. – CodesInChaos Sep 29 '14 at 20:06
up vote 10 down vote accepted

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.

  • Well, there are plenty of legitimate uses for SSL proxying. CloudFlare is a legitimate company and they don't seem to have any ill intentions. The problem is that through their system people can configure sites that appear to be secure but in reality aren't. Their certificates are valid for the domains. Sure, you could check if the Server is cloudflare-nginx, but there are so many sites on CloudFlare now that you'd lose a good chunk of the Internet if you decided to just distrust all SSL/TLS CloudFlare connections. – Dr. McKay Sep 29 '14 at 18:06
  • As it stands now, connections appear to be entirely secure to the user. It can only get better by exposing a mechanism to inform the browser that the connection isn't secure from end-to-end. – Dr. McKay Sep 29 '14 at 18:08
  • 5
    @Dr.McKay - that's the thing though, the place to do that is in the certificate. If Cloudflare is putting up certificates that don't make the state of the connection clear, then they should be stripped of trust until they fix the problem, just like we'd strip any other major misbehaving CA of not behaving in a trustworthy manner. That is how the SSL system is designed to operated, we don't need some new solution to a problem that is already solved. – AJ Henderson Sep 29 '14 at 18:15
  • I see your point now. While a header would be able to convey information about the security of the connection, by then it would be too late since the cookies and authentication and such would already be sent. – Dr. McKay Sep 29 '14 at 18:18
  • But doing anything on the certificate level would be too inflexible to indicate whether the backend connection is plain, SSL Self-signed, or full proper SSL. (Those are the three options they give you.) – Riking Oct 17 '14 at 10:07

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.

  • 2
    +1. All the little padlock tells you is your communication with the server you are sending the data to is secure. People would be surprised to learn quite how often it's immediately decrypted before being sent to the server that actually consumes it, typically by a load balancer, or that load balancer uses TLS but then internally all the sysadmins are using their own self-signed certs. – Rushyo Apr 9 '15 at 14:49

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.