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

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Mar 24 20:02:26 UTC 2020


#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.2
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team         |
Parent ID:  #30029                               |         Points:  20
 Reviewer:  mcs, sysrqb, antonela                |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by mcs):

 Replying to [comment:37 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.

 The torbutton patch looks good.

 We see one tiny issue with the tor-browser patch: there is a stray `"` in
 the log message that begins with `Found ruleset timestamp`.

 But we did experience a significant problem when using the newer HTTPS-E
 (​https://eff.org/files/https-everywhere-2020.3.16-eff.xpi). Using our own
 browser build on macOS, if we start clean by removing the `browser-
 extension-data/https-everywhere-eff at eff.org/` directory from the browser
 profile, then no rules are added to the `_onionMap` in
 `OnionAliasStore.jsm`. Although the ruleset is preset, logging shows that
 zero rules were installed:
 {{{
 OnionAlias: Checking for new rules
 OnionAlias: Found ruleset timestamp" 0, current is null
 OnionAlias: New rules found, updating
 OnionAlias: Loading 0 rules
 ...
 OnionAlias: Checking for new rules
 OnionAlias: Found ruleset timestamp" 1582940785, current is 0
 OnionAlias: New rules found, updating
 OnionAlias: Loading 0 rules
 ...
 OnionAlias: Checking for new rules
 OnionAlias: Found ruleset timestamp" 1582940785, current is 1582940785
 }}}

 At the end, since the timestamp is unchanged no attempt is made to add the
 rules to `_onionMap`. But I guess the first time a non-zero timestamp was
 returned the rules should have been present. HTTPS-E does have the rules;
 we can tell because we are redirected to the .onion (but the ugly .onion
 name is displayed in the URL bar, which it should not be).

 Maybe this is an HTTPS-E bug with the `get_simple_rules_ending_with` API
 or some kind of race, because if we start the browser a second time it
 does work correctly:
 {{{
 OnionAlias: Checking for new rules
 OnionAlias: Found ruleset timestamp" 1582940785, current is null
 OnionAlias: New rules found, updating
 OnionAlias: Loading 38 rules
 }}}

 A workaround might be to ignore the timestamp if no rules are returned by
 HTTPS-E (but Kathy and I did not try that).

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


More information about the tor-bugs mailing list