[tor-bugs] #28005 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Officially support onions in HTTPS-Everywhere
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Jan 23 17:12:42 UTC 2020
#28005: Officially support onions in HTTPS-Everywhere
-------------------------------------------------+-------------------------
Reporter: asn | Owner: legind
Type: defect | Status: new
Priority: Medium | Milestone:
Component: HTTPS Everywhere/EFF-HTTPS | Version:
Everywhere |
Severity: Normal | Resolution:
Keywords: tor-hs, https-everywhere, tor-ux, | Actual Points:
network-team-roadmap-november, |
TorBrowserTeam202001, network-team-roadmap- |
2020Q1 |
Parent ID: #30029 | Points: 20
Reviewer: | Sponsor:
| Sponsor27-must
-------------------------------------------------+-------------------------
Comment (by acat):
I was not sure whether it was worth implementing this in Tor Browser
directly instead of using https-everywhere, so as suggested by asn I made
some list of pros/cons and time estimates for each option.
TLDR: I think it's ok to stick to https-everywhere.
== Features to be implemented
Listing (sub)features so that these can be referenced later.
1. Have some local knowledge of mappings from memorable *.tor.onion to
*.onion in Tor Browser.
2. Have a way to subscribe to sources of .tor.onion -> .onion mappings, in
a way that these can be automatically updated (update channels).
3. Automatically redirect known human-memorable *.tor.onion addresses to
the corresponding .onion.
4. Via "some UX solution", show the human-memorable .tor.onion in the
urlbar even though the actual location is a "long" .onion.
5. (Maybe) also do 3) when the user navigates to some .onion directly for
which we know some *.tor.onion ("reverse lookup").
6. (Maybe) allow users to view the local .tor.onion -> .onion mappings.
7. (Out of scope, but maybe later) allow users to edit the local
.tor.onion -> .onion mappings.
== Pros/cons of using https-everywhere
Pros:
- Update channels already implemented (feature 2).
- Automatic redirect already implemented (feature 3).
- Might be easier to get third-parties to maintain .tor.onion update
channels than if we implement our own update channel mechanism.
Cons:
- We might need to do a custom build of the extension if we can't get the
changes we need upstreamed to https-everywhere, and that would mean
dealing with [1].
- With the current rules format, it's not obvious how to extract reliable,
explicit .tor.onion -> .onion mappings (see [3] for an example of a
torproject.org ruleset extracted from [4]). I think a list of explicit
.tor.onion -> .onion mappings would be more desireable, as https-
everywhere can do arbitrary url rewrites, and depending on how a rule is
written it might not be obvious whether it's a .tor.onion -> .onion
mapping or something else.
- If for some reason one day https-everywhere is not maintained anymore,
we will probably have to reimplement it in Tor Browser anyway.
== Work needed
I'll list the concrete changes that would need to be done if we were to
implement it with https-everywhere, with Tor Browser, and finally the ones
that need to be done in any case in Tor Browser (common), with time
estimation.
=== HTTPS-Everywhere:
Initially I was considering trying to make https-everywhere support a new
kind of rules which would explicitly express a .tor.onion -> .onion
mapping. However, after thinking a while I think it's too unclear how much
time this change would take or if a possible PR would be accepted at all.
So, trying to be pragmatic here and suggesting to leave the rules as they
are now, and somehow implement a function in Tor Browser side that
receives a .tor.onion https-everywhere ruleset and returns a
(conservative) .tor.onion -> .onion mapping, so that we can do urlbar
.tor.onion rewriting and rules viewing in a simple way.
* 3 points: Implement message passing in https-everywhere similar to the
one we use for NoScript, so that from Tor Browser side we can receive
.tor.onion rulesets and features 4, 5, 6 and possibly 7 can be
implemented.
* 1 point: Implement message passing to be able to setup/control update
channels programatically from Tor Browser side (feature 1). This should
allow us to install an update channel without needing a custom build and
having to deal with [1], which I'm not sure how difficult would be.
=== Everything in Tor Browser:
* 5 points: Implement update channels feature.
* 2 points: Implement automatic redirects based on .tor.onion mappings.
=== Common items (need to be implemented in Tor Browser in any case):
* 2 points: UI to view .tor.onion -> .onion mappings (I'm assuming we
don't want this in https-everywhere).
* 3 points: Replacing .onion by human-memorable .tor.onion in urlbar.
According to these estimates, https-everywhere path would be 4 + 5 = 9
points, and doing everything in Tor Browser 7 + 5 = 12 points.
I think it's preferrable to keep the plan and implement it using https-
everywhere, and only switch to doing everything in Tor Browser if, at some
point, we are forced for technical reasons (which I hope will not be the
case).
----
[1] https://trac.torproject.org/projects/tor/ticket/10394
[2] https://github.com/EFForg/https-
everywhere/blob/83642b8e7024a7c4ddc8c6f062c2306882f7f3c0/chromium
/background-scripts/update.js
[3]
{{{
<ruleset name="TorProject Onion" default_off="See
https://trac.torproject.org/projects/tor/ticket/11567">
<target host="torproject.org" />
<target host="www.torproject.org" />
<target host="archive.torproject.org" />
<target host="media.torproject.org" />
<target host="trac.torproject.org" />
<rule from="^https?://trac\.torproject\.org/"
to="http://vwp5zrdfwmw4avcq.onion/" />
<rule from="^https?://media\.torproject\.org/"
to="http://p3igkncehackjtib.onion/" />
<rule from="^https?://archive\.torproject\.org/"
to="http://j6im4v42ur6dpic3.onion/" />
<rule from="^https?://(www\.)?torproject\.org/"
to="http://idnxcnkne4qt76tg.onion/" />
</ruleset>
}}}
[4] https://github.com/chris-barry/darkweb-everywhere
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28005#comment:14>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list