[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere
#28005: Officially support onions in HTTPS-Everywhere
-------------------------------------------------+-------------------------
Reporter: asn | Owner: tbb-
| team
Type: defect | Status:
| needs_review
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: tor-hs, https-everywhere, network- | Actual Points: 18
team-roadmap-november, network-team-roadmap- |
2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID: #30029 | Points: 20
Reviewer: mcs, sysrqb, antonela | Sponsor:
| Sponsor27-must
-------------------------------------------------+-------------------------
Comment (by acat):
Thanks again for the review. Revised branches:
https://github.com/acatarineu/tor-browser/commit/28005+4,
https://github.com/acatarineu/torbutton/commit/28005+2.
Replying to [comment:35 mcs]:
> Is there a version of HTTPS-E available that supports the new
`get_simple_rules_ending_with` API? When we tested with HTTPS-E 2020.3.16
we saw some strange behavior, but if that is supposed to work we can try
again.
I originally tested by building a non-signed xpi with https-everywhere
master and installing it manually, but now installing the official
https://eff.org/files/https-everywhere-2020.3.16-eff.xpi is working fine
for me (after a browser restart).
> Related to
`browser/components/onionservices/HttpsEverywhereControl.jsm`:
> * Should we open a new ticket for the "lock the channel to prevent user
changes" issue? Is it a foot gun? I guess the idea is that we do not want
users to substitute their own URL, etc. with the SecureDrop ruleset. On
the other hand, I think users can add their own .tor.onion rules.
What I was thinking is to be able to setup the ruleset in a way that
behaves like the default EFF (Full) ruleset, so that it cannot be edited
via UI (perhaps just allow to disable? but that might require more work on
https-everywhere side). But yes, this does not protect against .tor.onion
mappings being overriden by other rulesets that a user may add. I think
it's a good to have change, but not strictly needed for now. I created
#33694 for this.
Replying to [comment:36 mcs]:
> One thing I forgot to mention: the SecureDrop ruleset maps
`www.nytimes.com.securedrop.tor.onion` to the NYT SecureDrop service. It
is inconvenient to require the `www.` prefix as well as `.com`. But I am
not sure what process was used to create the ruleset and how it will be
maintained by SecureDrop people going forward.
I think they wanted to keep exactly the same original domain: there are
cases without `www.` like `home.coworker.org.securedrop.tor.onion` or
`theintercept.com.securedrop.tor.onion`. By the way, I did not do a review
of all rulesets, but just noticed a weird case:
`img.huffingtonpost.com.securedrop.tor.onion`. Here the argument of
keeping the original domain would not hold, since `img.huffingtonpost.com`
webpage does not work, so perhaps it's a bug.
In any case, regarding `www.` prefix, I think we agree that it's
preferable not to have it, so perhaps we should contact asking whether it
would be possible to remove it - even if it does not match the original
domain.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28005#comment:37>
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