[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #28005 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Officially support onions in HTTPS-Everywhere
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs