Opened 3 months ago

Last modified 3 months ago

#30599 new defect

Cloudflare alt-svc onions cause a different exit to be used at each request

Reported by: cypherpunks2 Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ux-team
Cc: Actual Points:
Parent ID: #30024 Points:
Reviewer: Sponsor: Sponsor27-must

Description

For some websites, such as zerobin.net which use Cloudflare's new onions, each request might cause a different exit to be used. This is bad both from a load perspective as well as a fingerprinting perspective.

Steps to reproduce: Go to zerobin.net and create a new paste with "allow discussion" enabled. Post several comments and observe that the visual hash of the IP often changes with each comment. Check the circuit display to verify.

Child Tickets

Change History (8)

comment:1 Changed 3 months ago by gk

Component: Core Tor/TorApplications/Tor Browser
Owner: set to tbb-team
Parent ID: #30024
Sponsor: Sponsor27-can

We might want to look at that during S27 as it may have impact on #27590 and #27502.

comment:2 Changed 3 months ago by cypherpunks

I think this is a pretty nasty issue, especially now that a lot of sites are doing this.

Another way to test this is to use the demo site https://perfectoid.space/test.php mentioned in #27502. Nearly every time it is reloaded, the entire circuit path changes. This is not unique to Cloudflare.

comment:3 Changed 3 months ago by teor

So this is a request for Tor Browser to prioritise "the same onion you used last time"?
This could get interesting: we don't want to leak preferred onions between URL bar domains.

comment:4 in reply to:  3 Changed 3 months ago by cypherpunks

Replying to teor:

So this is a request for Tor Browser to prioritise "the same onion you used last time"?
This could get interesting: we don't want to leak preferred onions between URL bar domains.

In the same way that the same exit is preferred for a given domain.

Building a new circuit for each and every request as is currently done in this situation is a waste of resources and a fingerprinting risk. There's no reason that one refresh uses one circuit and the next refresh 6 seconds later gives another.

comment:5 Changed 3 months ago by gk

Priority: MediumHigh

I read this bug got some interest and I agree that it shows an important bug (be it in tor itself or the browser part). We should get to it during our S27 work but if anyone has cycles to look at it now, that would be much appreciated.

comment:6 Changed 3 months ago by gk

Sponsor: Sponsor27-canSponsor27-must

So, I just tried to send something via a contact form for literally 30min and I failed due to various Cloudflare issues going on. I finally resorted to disable Alt-Svc in a different Tor Browser and that solved the problem for me. Further bumping prio.

comment:7 Changed 3 months ago by gk

I looked at this over the weekend and I think that's mostly an UI bug so far (see: comment:13:ticket:27590 for a similar observation). Once you load some thread, say, on zerobin.net what happens is that the Alt-Svc response header is processed and the mapping is created. A crucial part of that is validating it (see: AltSvcCache::UpdateAltServiceMapping) which means in the ​https:// case just establishing a connection to the alt-svc host. And the circuit display gets in turn updated with the client side rend circuit caused by that validation request. There is no actual content sent back and forth here as it takes the non-alt-svc route.

Then when you post a comment what happens is that the validated host is used for fetching the busy.gif file and posting the actual content:

2019-06-04 11:15:39.316750 UTC - [10627:Main Thread]: D/nsHttp AltSvcCache::GetAltServiceMapping 0x7f009435c038 key=https:zerobin.net:443:P:^privateBrowsingId=1&firstPartyDomain=zerobin.net existing=0x7f006be2c580 validated=1 ttl=86377
2019-06-04 11:15:39.316760 UTC - [10627:Main Thread]: D/nsHttp nsHttpChannel 0x7f006b320000 Alt Service Mapping Found https://cflarenuttlfuyn7imozr4atzvfbiw3ezgbdjdldmdx7srterayaozid.onion:443 [https:zerobin.net:443:P:^privateBrowsingId=1&firstPartyDomain=zerobin.net]
2019-06-04 11:15:39.316827 UTC - [10627:Main Thread]: D/nsHttp nsHttpChannel 0x7f006b320000 Using connection info from altsvc mapping

But now you get another set of those .onions as hosts in response headers. If they are not seen before the first (while validation is ongoing validation of other alt-svc hosts in headers seems to be skipped) gets validated again, causing another set of HS related circuits created and thus the circuit display is updated again. And so on with further posts.

It does not seem unreasonable to me to think about not updating the circuit display for validation requests as no part of the website got loaded over them. However, one could argue that showing everything *related* to the website load in the display is a thing we should do. We do it for other websites as well if there are requests caused but no content changes are done.

comment:8 Changed 3 months ago by pili

Keywords: ux-team added

Might need some input from UX Team

Note: See TracTickets for help on using tickets.