I received an HTTPS Everywhere bug report from some users who were traveling in the U.K. and found that they couldn't make HTTPS Google searches because their ISP was downgrading them, even with HTTPS Everywhere turned on. They wondered why the downgrade was succeeding, but eventually discovered that it's because Google was cooperating with it:
https://support.google.com/websearch/answer/186669?hl=en > To disable SSL search for your network, configure the DNS entry for > www.google.com (or any other Google country domains your users may > use) to be a CNAME for nosslsearch.google.com. > > We will not serve SSL search results for requests that we receive on > this virtual IP address (VIP). If we receive a search request over > port 443, the certificate handshake will complete successfully, but we > will then redirect the user to a non-SSL search experience. The first > time a user is redirected, they will be shown a notice that SSL has > been disabled by the network administrator. > > Utilizing the NoSSLSearch VIP will not affect other Google services > outside of Search. Logging into Google Apps and authenticating to > different services will continue to work (and will occur over SSL). That's what their ISP was doing. The users strongly objected to it and wished that HTTPS Everywhere had protected them against the downgrade. It seems like this is the basis of the difference between https://www.google.com/ and https://encrypted.google.com/ and the history of having different HTTPS Everywhere rules for the two sites. And I think we decided that using www.google.com was preferable in other ways most of the time -- but here it exposes uses to a Google-approved downgrade. Do we still have two separate rulesets that take the two separate approaches? This also seems like it could be, unusually, a candidate for a "second attempt rewrite" functionality, which responds to a server redirect by rewriting a URL again. That is, I think the users would have preferred logic like User attempts to go to http://www.google.com/ HTTPS Everywhere rewrites it to https://www.google.com/ ("first choice rewrite", "first attempt rewrite") If the HTTPS connection is successful, HTTPS Everywhere stops rewriting If the HTTPS connection is redirected back to http://www.google.com/, invoke a second-stage rewrite to https://encrypted.google.com/ ("second choice rewrite", "second attempt rewrite") The only use case I can think of for this right now is when a particular site sometimes downgrades users and sometimes doesn't -- which is effectively the case with Google Search here. -- Seth Schoen <[email protected]> Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107
