[tor-bugs] #27502 [Applications/Tor Browser]: Prioritize .onion hosts in AltSvc?

[Tor Bug Tracker & Wiki]

#27502: Prioritize .onion hosts in AltSvc?
--------------------------------------+--------------------------------
 Reporter:  arthuredelstein           |          Owner:  sysrqb
     Type:  defect                    |         Status:  assigned
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  TorBrowserTeam202001      |  Actual Points:
Parent ID:  #30024                    |         Points:
 Reviewer:                            |        Sponsor:  Sponsor27-must
--------------------------------------+--------------------------------
Changes (by sysrqb):

 * cc: tbb-team (added)
 * keywords:   => TorBrowserTeam202001


Comment:

 Replying to [comment:5 btasker]:
 > > Is this saying that if a website says Alt-Svc: a.com, b.onion we
 should use b.onion before a.com? Doesn't Alt-Svc specify the priority to
 connect to be in the order provided?
 >
 > No, the RFC (7838) says that it's down to the user-agent to decide how
 to prioritise them - so TBB prioritising .onion would totally be valid.

 To be precise it says:
 {{{
    When multiple values are present, the order of the values reflects
    the server's preference (with the first value being the most
    preferred alternative).

    The value(s) advertised by Alt-Svc can be used by clients to open a
    new connection to an alternative service.
 }}}
 https://tools.ietf.org/html/rfc7838#page-8

 >
 > I support the idea of having TBB prioritise .onion domains:
 >
 > It lowers the barrier to entry, otherwise a site/server operator is
 going to need to try and identify exit nodes so that the can decide
 whether to _only_ include the .onion. That's not particularly hard to do,
 but is still more work than should actually be required.

 #32256

 >
 >
 > Chrome and Firefox already disregard any alternates that they cannot
 resolve/reach, so it's safe to just include the .onion in all responses.

 When/if Chrome supports h2 alt-svc, I assume Chrome will leak the onion
 address by DNS and then fail, because Chrome didn't respect RFC 7686 the
 last time I checked.

 >
 > But if TBB doesn't prioritise it, the browser might instead connect out
 to one of the other clearnet origins, using exit b/w and undermining the
 entire point of having the .onion in the header in the first place.
 >
 > As noted above, where things stand currently is that even if it is
 selected the onion may initially be slower to respond, leading to it
 getting de-prioritised.
 >
 >
 > > Or is the problem that UAs (Chrome? Edge? Safari?) are dumb and will
 spin trying to connect to the .onion so a website is forced to put them
 last?
 >
 > Purely for info as you've asked and I've skimmed the patch recently for
 other purposes:
 >
 > At time of writing, only Firefox has implemented support for Alt-Svc and
 HTTP/2.0 alternates. Chrome supports QUIC, but doesn't appear to have
 implemented anything further.
 >
 > As far as handling goes, when FF receives the header it triggers an
 asynchronous null request out to the specified alternates and assesses
 them (i.e. can they present the right cert etc). Any already queued
 requests continue to go to the original origin, and new requests will go
 to the selected alternate.

 As I understand it, Firefox only tests one alternate at a time. Firefox
 maintains a hashmap where the key is based on the origin, and it doesn't
 include any attributes of the alternative(s). Therefore, Firefox prefers
 the first alternate in the alt-svc list, but it validates subsequent alt-
 svc entries after the first entry is validated. This only happens on
 responses that arrive after the alt-svc validation completes (?).

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