Opened 16 months ago

Last modified 13 hours ago

#28005 new defect

Officially support onions in HTTPS-Everywhere

Reported by: asn Owned by: legind
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Normal Keywords: tor-hs, https-everywhere, tor-ux, network-team-roadmap-november, TorBrowserTeam202001, network-team-roadmap-2020Q1
Cc: ilf, bee, fdsfgs@…, gaba, brade, mcs Actual Points:
Parent ID: #30029 Points: 20
Reviewer: Sponsor: Sponsor27-must

Description (last modified by asn)

The plan:

A major UX issue for onion services is their huge addresses. We want to fix this issue because an address with 56 random characters confuses people, it makes it harder to pass the address around, and it also makes it much harder to verify it.

There is a field of literature called "secure name systems" but none of the candidates are good enough for us right now. Hence, we present a hotfix that might offer a situational relief for users for the medium-term future, until we come up with something better, or while we experiment with more solutions. I suggest we keep this ticket focused to this idea, instead of debating why this and not that since we've already been doing this for far too long.

The plan is to use the HTTPS-Everywhere extension that we already have in Tor Browser, and encourage people to write their own rulesets for onions. We are talking about community-maintained rulesets and nothing that is officially maintained by The Tor Project or by HTTPS-Everywhere. This ticket is about making it easier for people to create, import and use this rulesets. We are talking about UI/UX improvements, writing blog posts and doing Q&A.

Here are some example of community rulesets we can imagine:

  • The SecureDrop ruleset: where securedrop makes a ruleset with their whole directory. People can download that to quickly visit securedrop destinations, by going to securedrop-nyt.tor.onion .
  • The Torproject ruleset: where torproject makes a ruleset with all their onions. We developers can use that to quickly visit Tor sites over onion, by going to tor-trac.tor.onion instead of remembering the onion.
  • The Bitcoin ruleset: where a "trusted" bitcoin entity publishes a ruleset with various cryptocurrency-related rules that allow people to quickly visit them.

This approach has both positives and negatives (I assure you this is the case with every "secure naming" project out there):

  • Positives: Good security if the ruleset is taken from a trusted source. No state keeping. Reachable engineering effort. No global names, hence no fear of name squatting. Easy to understand tradeoffs.
  • Negatives: Terrible security if the ruleset is evil. No global names: If you want people to use your shorten onion name, you need to persuade them to use your ruleset.

Here are some HTTPS-Everywhere issues we need to solve based on my Mexico notes:

  • Be able to stop update channels per-channel.
  • Need good UI to easily look and understand rules.
  • Need to implement file extension to install ruleset with one-click from web button.

Here are some issues we need to think about:

  • We need good user text to make sure that people don't shoot themselves in the foot too often by installing bad rulesets and whatnot (they already do it daily when they open onions from "search enginers" or reddit).
  • Which tld to use? If we use .tor we open ourselves to DNS leaks in normal browsers. If we use .tor.onion that might be confusing to people.
  • Are there any issues with SSL?

More resources:

Child Tickets

Attachments (1)

httpse-v3onions.png (66.6 KB) - added by antonela 16 months ago.

Download all attachments as: .zip

Change History (14)

Changed 16 months ago by antonela

Attachment: httpse-v3onions.png added

comment:1 Changed 10 months ago by asn

Sponsor: Sponsor27-must

comment:2 Changed 10 months ago by gk

Cc: ilf bee added

Closing #1670 and #19812 as duplicate of this ticket. I think the onion rulesets idea fits nicely with their requests.

comment:3 Changed 10 months ago by gk

Cc: fdsfgs@… added

comment:4 Changed 10 months ago by asn

Points: 20

comment:5 Changed 10 months ago by pili

Parent ID: #30029

comment:6 Changed 9 months ago by asn

Description: modified (diff)

comment:7 Changed 9 months ago by gaba

Cc: gaba added

comment:8 Changed 6 months ago by gaba

Keywords: network-team-roadmap-november added

comment:9 Changed 4 months ago by asn

Here are some notes from the plans we made in Stockholm in the meeting between
me, antonela, sysrqb, redshiftzero, geko and dgoulet:

Scope of work:

  • First iteration will include onion rules for securedrop websites (e.g. nytimes.securedrop.tor.onion -> nyttips4bmquxfzw.onion)
  • Need to add a toolbar button in the ffox UI to show that a redirect happened
  • Rewrite URL in URL bar (only show the human-readable url)
  • Add support for viewing rulesets (?)
  • See how update channels work and whether we should disable them or not.

Out of scope:

  • First iteration will not allow people to easily add their own rules

TLD scheme:

  • Three options for tld scheme:

a) nytimes.securedrop.onion (ambiguous and probably unsafe)
b) nytimes.securedrop.tor.onion (safe but bad UX)
c) nytimes.securedrop.tor (good UX but DNS leaks in other browsers)

We decided to ditch (a) from our options and do either (b) or (c). (b) is the
safest and we should probably roll with that (?).

FPF plan:

  • FPF will change their securedrop directory to include ".tor.onion" links for their various instances.


  • 3 months of work are enough

comment:10 Changed 9 days ago by sysrqb

Keywords: TorBrowserTeam202001 added

Putting this on the browser team's plate.

comment:11 Changed 39 hours ago by acat

Some thoughts after thinking a bit how to implement this.

Supporting local redirects from human-memorable addresses (.tor.onion -> .onion) can be done with https-everywhere extension as is, either by adding a 3rd-party update channel or by adding custom rulesets in debug mode (the latter is less usable I assume). With respect to update channels, it should not be difficult to modify https-everywhere to allow enabling/disabling automatic updates per channel and not globally as it is currently implemented, and this is something that might be interesting also for non Tor Browser https-everywhere users (although I don't think many people have more update channels than the default one).

Then we need to show the human-memorable URL in the urlbar, plus possibly some visual feedback indicating that there was some kind of local redirect (I guess the concrete UX solution still needs to be decided). This has to be implemented in Tor Browser, since AFAIK there is no way to achieve that using a WebExtension like https-everywhere only. There are several ways this can be implemented from the Tor Browser side, but at the end of the day we need some way to know whether for the current .onion page we have some .tor.onion human-memorable "alias" that the user trusts.

With the current implementation, it would be difficult from Tor Browser side to ask https-everywhere questions like: is there any .onion mapping for this .tor.onion domain the user just entered? So I think the simplest is to observe .tor.onion -> .onion redirects and assume that when this happens it's because the original .tor.onion is a human-memorable alias for the corresponding .onion that the user trusts. Observing http requests like that should be quite simple to do from Tor Browser side, and this implementation would work independently of https-everywhere: we just observe .tor.onion -> .onion redirects, but we don't need to know how or by whom these redirects were done.

A few questions/issues regarding showing short .tor.onion in urlbar:

  1. Whenever there is a .tor.onion -> .onion redirect, should we display the full original URL in the urlbar, or just replace the hostname for the human-memorable one in the final URL? For example, let's say we observe a redirect from http://nytimes.securedrop.tor.onion to https://www.nyttips4bmquxfzw.onion (upgrade to https + translate from .tor.onion + adding www). In this case I think it would not make much sense to show the original URL, but just display https://www.[nytimes.securedrop.tor.onion] (and if we follow the solution I mentioned, show https://www.nyttips4bmquxfzw.onion when user clicks on it).
  1. What should we do when user keeps navigating in subpages of some .onion, given the fact that the .tor.onion -> .onion is only observed in the first navigation? Should we show the human-memorable .tor.onion in the urlbar for that tab until the user navigates away from the underlying .onion? Do we also need to show .tor.onion for links opened in a new tab from there?
  1. Do we need to show .tor.onion when user navigates directly to a .onion page for which we have some .tor.onion "rule"? (mentioned by sysrqb in a IRC conversation)

If we were to implement 3) I think we would need to be able to ask https-everywhere for some kind of reverse lookup to obtain a .tor.onion for a given .onion hostname, so the current approach of just observing http redirects from Tor Browser would not work.

Note that if we had an explicit list of .tor.onion -> .onion pairs indicating this mapping (like a /etc/hosts file) we would not need to be looking for redirects to infer the .tor.onion -> .onion relationship, and doing a "reverse lookup" (finding a .tor.onion that corresponds to some .onion) would be trivial. I also think that designing a UI to view/edit .tor.onion rules/mappings would be much easier than doing one for https-everywhere rules, since https-everywhere rulesets are more powerful (and more complicated) than just .tor.onion -> .onion mappings. So, depending on what we want to support, especially if we want to do UI to view/edit rules, I would consider implementing the full feature in Tor Browser directly instead of partially using https-everywhere.

So I would suggest discussing/deciding about the Add support for viewing rulesets (?) feature, as I'm not sure how it could look like if we are going to do this with https-everywhere.


For now to move forward my plan is to implement some UI to replace .onion by .tor.onion in the urlbar, by observing request redirects as I mentioned before. I know the concrete UX still needs to be decided, but I'll try to implement the urlbar logic and I think most of this code will be needed independently of the final solution. I'll try to show .tor.onion in the urlbar whenever there is a redirect from .tor.onion and as long as the user does not navigate away from the real .onion. As I said, I think this would be easier if we had something like an explicit hosts-like .tor.onion -> .onion mapping instead of delegating this to https-everywhere, but we can still do a good job by observing redirects.

Then, it should be possible to test the feature by adding some custom update channel to https-everywhere that has .tor.onion mappings in it. For example:

Path Prefix:

JWK: {"kty":"RSA","e":"AQAB","n":"2IGvrYj_UwpO8EMNeEiitb8imzuJA-BGngLYtMkY72wx6aPhuWWvGs-Dlh4lHB4fi8rxfeb0N6ZwCyfCKBeHgfuTgbH14HB-ZSA47JHKEO4fSiay1jjhsGDzQlZDVdn_Wfyxi5je80pizMsOulHKEKzRx4HIcrXY1nf8iiOHEWaB0GX8H1pJjyIlqTxN9Pm5Q4h7kRLUoq3O9EE3o7q1dVeaxYM221WPqaSq9mawAhih4wo_79mb6JinG--s9F3jfqmnOvQk-xAoSTA-XNqTvO-7Mg_WajoA7Lnx1pJbGuvhqNOdodWOFxdMMNaPL8JXmPywl6zAqMESU1rXcaVKVdx1LpcmTyz8dGi3u_GTb6fo5GqXUgByvvRcOXA6DAFC7tbLEy1QinU0q4cRZJYf6s4QxgyRsCgxrcJ9kuDwDHviAm9Yn3eEFRbD2e3hRFfZyvkkLepEWywEfBGdBjQ_Kz9gkQTzmpVef1J-sSD6dnW5OEVEXAPO0sEdr5o-Ng9NSvDGZ3Sw-4AgFO6aynLnpvbVOYneppLF7MKwGVQv0tQ8XY3zBEsxidTIkvmpzKZp6QElpfCwbYnl9aQ9hQ3BmOPIhM2VunP47MPOgyAp4s2m3knwCWbPSR5Gm8agDwIGA1Va1eFAtS-YAYk8v-J20iTyuXrpWqrQmFjEnVLsav8"}

This should not take long, I would say at most 5 points. From there we could discuss about the .tor.onion urlbar replacement UX, and decide about the UI to view rules/mappings. Depending on that, we could still go for https-everywhere or implement everything in Tor Browser.

Last edited 39 hours ago by acat (previous) (diff)

comment:12 Changed 19 hours ago by mcs

Cc: brade mcs added

comment:13 Changed 13 hours ago by gaba

Keywords: network-team-roadmap-2020Q1 added

Move s27 must tickets into new roadmap.

Note: See TracTickets for help on using tickets.