I\'m not sure where to post this, so I figured I\'d just post it here. CloudFlar
ID: 658775 • Letter: I
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?
Explanation / Answer
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.