[tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#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