
HTTPS Everywhere Version 5: Sixteen New Languages and Thousands of New Rules - ghosh
https://www.eff.org/deeplinks/2015/03/https-everywhere-version-5-sixteen-new-languages-and-thousands-new-rules
======
Animats
All those "rules", centrally stored. _" HTTPS Everywhere tries each rule in
those rulesets against the full URL. If the Regular Expression, or regexp, in
one of those rules matches, HTTPS Everywhere rewrites the URL according the
the to attribute of the rule."_

Now there's an attack surface. If you can put a rewrite to a fake site into
the EFF's database, what happens?

~~~
extrapolate
Good point! It looks like all of the rules are here[1], so as long as there is
oversight by the EFF, their repo isn't compromised, someone doesn't put out a
fake build, etc., we should be safe.

Also it looks like[2] some rules are built in such a way that only the
protocol is changed and the domain is left as-is.

[1] [https://github.com/EFForg/https-
everywhere/tree/master/src/c...](https://github.com/EFForg/https-
everywhere/tree/master/src/chrome/content/rules)

[2] [https://github.com/EFForg/https-
everywhere/blob/master/src/c...](https://github.com/EFForg/https-
everywhere/blob/master/src/chrome/content/rules/Archive.org_Way_Back_Machine.xml#L18-L19)

~~~
schoen
HTTPS Everywhere has a few important precautions in place, and would welcome
suggestions or code contributions for others. One of these is reproducibility
of the package build, so you can check out the source tree, verify the signed
tag, and build the same byte-for-byte identical XPI file that is being
distributed from EFF's web site. (I just did this for the 5.0.1 XPI and the
files were the same, although my colleague who made that release notes that
there is a still-incompletely-documented dependency on the libsqlite3
version.)

There are also scripts that indicate whether rules redirect to non-HTTPS
targets and whether the rules contain non-ASCII characters (to avoid homoglyph
attacks, like <rule from="^https?://www\\.paypal\\.com/"
to="[https://www.pаypаl.cοm/">](https://www.pаypаl.cοm/">)).

Because of the challenges of parsing PCRE with backreferences, there are no
scripts that check whether the target domains are the same as the source
domains (and there have been a small number of rules that did intentionally
rewrite to a different domain). These do get read by human beings before being
included in the project, and traditionally new rules are included for months
in the development release before being migrated into the stable release, but
it would be a great thing if more human beings would check them, or help
develop scripts that do so in new ways.

One idea that we've talked about in the past is to divide rules into simple
and complex, and then single out only the complex rules for extra human
auditing. (Simple rules would be syntactically constrained not to rewrite
across domains.)

------
jgome
It bothers me that "HTTPS Everywhere" calls
[https://check.torproject.org](https://check.torproject.org) to check for tor:
[https://github.com/EFForg/https-
everywhere/blob/master/src/c...](https://github.com/EFForg/https-
everywhere/blob/master/src/components/ssl-observatory.js#L85) I don't want my
browsing calling random websites at any moment... whatever the reason for it.
Can this be made optional, please?

Also, slashdot (the desktop version) has problems with this browser extension
:(

Other than that, thank you very much for your great work, to everyone involved
in the project :)

~~~
middleclick
This is for the SSL Observatory, a feature you can turn off and about which
HTTPS Everywhere asks you at startup.

------
higherpurpose
> and support for "Block All HTTP Requests" in Chrome

Great, I've been waiting for that (they call it "HTTP Nowhere" in the
extension). Once it appears on the Firefox version, too, it should be
automatically enabled in Tor.

~~~
DINKDINK
If you're having a hard time finding the "Turn on HTTP Nowhere" option:

In a normal tab, left click the HTTPS Everywhere icon in the top right of the
browser and click the "Turn on HTTP Nowhere" checkbox.

~~~
Karunamon
Annoyingly, this results in an error rather than an attempt to redirect to the
https version of the same site.

~~~
cottonseed
HTTP Nowhere has an option to redirect.

~~~
Karunamon
Where? At least in the Chrome version, all you get is the single button
settings UI, and there's no redirect option. Toggling the experimental rules
has no effect.

------
Teapot
How about a 'Block all downgrade Redirects' feature. Many sites supports HTTPS
but forces a downgrade redirect, 301 or 302, to http.

~~~
JeremyBanks
How would that work? If the site is sending you a redirect, then they aren't
sending you the content.

------
tyho
I am suprised to see EFF using a tracking bug on that page:

[https://piwik.org/docs/tracking-api/](https://piwik.org/docs/tracking-api/)

~~~
mike_hearn
Why? Would you be surprised if they outsourced hosting to Amazon or uploaded
their Apache logs to some third party service?

Outsourcing of website analytics is hardly some major evil.

~~~
tyho
Yes, and yes. This IS the EFF we are talking about. I didn't say it was a
major evil, just that I was surprised that the EFF was using a tracking bug.

------
novaleaf
I had to disable Https Everywhere because it makes a lot of sites silently
fail in various ways. (loading ajax)

a bummer for sure, i like it in theory.

------
rt897
Doesn't firefox already has the block HTTPs feature?

------
amelius
Can't we just have encryption inside the TCP/IP stack?

~~~
diminoten
HTTPS is encryption inside the TCP/IP stack, just a few layers deeper. :)

~~~
amelius
Obviously, I meant below the application layer.

