[HTTPS-E Rulesets] Some networks use a Google-supported mechanism for downgrades

[Seth David Schoen]

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  <schoen at eff.org>
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