Opened 15 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: #30024 Points:
Reviewer: Sponsor: Sponsor27-must

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 (12)

comment:1 Changed 15 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 15 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 15 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 15 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 14 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.

comment:7 Changed 9 months ago by pili

Sponsor: Sponsor27

comment:8 Changed 8 months ago by gk

Sponsor: Sponsor27Sponsor27-must

Add Sponsor27-must items for Objective 2

comment:9 Changed 8 months ago by pili

Parent ID: #30024

comment:10 Changed 7 months ago by cypherpunks

I think this should be delayed until #30599 is dealt with.

comment:11 Changed 3 months ago by redshiftzero

Similarly, it would also be nice to prioritize v3 onions over v2 onions. For context, for SecureDrop we want to add Alt-Srv headers on our v2 onions to direct traffic to v3 onions.

comment:12 Changed 2 months ago by naif

GlobaLeaks project is definitively interesting in such implementation and willing to implement it in it's own minimalistic Twisted based HTTP1/2/3 support (rif. https://github.com/globaleaks/GlobaLeaks/issues/2687)

Note: See TracTickets for help on using tickets.