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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

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

Comment (by sysrqb):

 acat and I were chatting about why the tor-browser patch uses a same-
 origin check (this check triggers a urlbar change when the user navigates
 from the current "aliased" site to a different .onion). However, we began
 thinking about how a same-origin check should be applied on .tor.onion
 domains. The same-origin check works because it uses the underlying
 `.onion` address for the current site and new site. Every .onion address
 is a separate origin, so the same-origin policy applies correctly. For the
 current patch, we should not need a same-origin policy for the .tor.onion
 aliases because they are only cosmetic. However, I expect in the future
 .tor.onion could be handled differently where a same-origin check should
 be evaluated correctly (as an example, maybe we populate the alt-svc cache
 mapping at startup instead of relying on https-everywhere rewriting).

 In any case, the current patch correctly adds `.tor.onion` as a new eTLD,
 however maybe it should go further and add `securedrop.tor.onion` as an
 eTLD because all sub-domains of `securedrop.tor.onion` are distinct
 origins. To make this explicit, currently
 `www.abc.net.au.securedrop.tor.onion` has (potentially) the same "origin"
 as `www.2600.com.securedrop.tor.onion` because they share the same eTLD
 (`.tor.onion`).

 Adding all new `*.tor.onion` scopes as new eTLDs doesn't scale very well
 (and it is a completely manual process and integrated in the browser at
 compile-time), so we should think about how we can improve this process,
 too. This also means that including arbitrary rulesets in the future could
 be a security risk (if/when `.tor.onion` is not simply a cosmetic UI
 layer). Currently, it is not a security risk.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28005#comment:43>
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