[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