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

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Oct 5 16:53:37 UTC 2018


#27502: Prioritize .onion hosts in AltSvc?
--------------------------------------+--------------------------
 Reporter:  arthuredelstein           |          Owner:  tbb-team
     Type:  defect                    |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:                            |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by 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.

 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.


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

 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.

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


More information about the tor-bugs mailing list