Opened 3 months ago

Last modified 2 months ago

#27502 new defect

Prioritize .onion hosts in AltSvc?

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We now support AltSvc and Mahrud suggested we might want to prioritize .onion AltSvc hosts in Tor Browser. It's an interesting idea and I would need to think about it more to know if it's desirable. Mahrud also pointed out a web page that demonstrates AltSvc over .onion:

https://perfectoid.space/test.php

Refresh several times and it will turn green when .onion is being used.

Child Tickets

Change History (6)

comment:1 Changed 3 months ago by tom

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?

Why do we need to do that? Can't the website put the onion at the beginning and UAs (should) know not to connect to it because it's a reserved domain?

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?

comment:2 Changed 3 months ago by mahrud

Not quite. Even if there is only one .onion alt-svc presented, sometimes after a few requests the browser seems to ignore the alt-svc and connect directly. I haven't read the code, but my guess is that this happens because the .onion takes a bit longer to load the first time. If that's the case the solution would be to force the browser to prioritize the onion route even if the first request took longer.

On a tangential note: should the Circuit Display show the onion address used when connecting through an alt-svc? Currently it doesn't.

comment:3 Changed 3 months ago by traumschule

Is this about making a redirect to the onion a default? This could break functionality in some cases (for example to be logged in at the clearnet and the onion address with different profiles).
Users can already decide for themselves to use #26581.
Having an option in preferences with a link explaining the implications could be nice though.
comment:51:ticket:21952 points out that domains could use this feature to distinguish TB users from other browsers.

comment:4 in reply to:  2 Changed 3 months ago by tom

Not quite. Even if there is only one .onion alt-svc presented, sometimes after a few requests the browser seems to ignore the alt-svc and connect directly. I haven't read the code, but my guess is that this happens because the .onion takes a bit longer to load the first time. If that's the case the solution would be to force the browser to prioritize the onion route even if the first request took longer.

Ah that makes sense.

Is this about making a redirect to the onion a default?

No. There has been discussion about that in various forms, but this is not that.

comment:5 Changed 2 months ago 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.

Note: See TracTickets for help on using tickets.