[tor-bugs] #28005 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Officially support onions in HTTPS-Everywhere

Mon Jan 20 19:48:53 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                           |
Parent ID:  #30029                               |         Points:  20
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (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).

   2. 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?

   3. 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.

 == Prototype

 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: https://people.torproject.org/~acat/mappingsmisc/rulesets/

   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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28005#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online