Go to https://pinning-test.badssl.com/ and change the circuit for this site. The expected behavior would be to use a new circuit keyed to badssl.com. But what happens is that the catch-all circuit gets changed. Found in legacy/trac#22513 (moved).
This is not only certificate related the timeout error page exhibits the same problem.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Trac: Description: Go to https://pinning-test.badssl.com/ and change the circuit for this site. The expected behavior would be to use a new circuit keyed to badssl.com. But what happens is that the catch-all circuit gets changed. Found in legacy/trac#22513 (moved).
to
Go to https://pinning-test.badssl.com/ and change the circuit for this site. The expected behavior would be to use a new circuit keyed to badssl.com. But what happens is that the catch-all circuit gets changed. Found in legacy/trac#22513 (moved).
This is not only certificate related the timeout error page exhibits the same problem. Summary: Changing circuit for page with certificate error switches catch-all circuit instead to Changing circuit for page with error switches catch-all circuit instead
The usability of the website is not affected by that. Could you explain your reasoning behind the keyword change? (Reverting it back to the original one meanwhile)
Trac: Keywords: tbb-usability-website deleted, tbb-linkability added Status: new to needs_information
The usability of the website is not affected by that. Could you explain your reasoning behind the keyword change? (Reverting it back to the original one meanwhile)
Expanding on that: I think the option to change a circuit for a particular domain might indeed perceived as an easy way to reduce linkability (which it actually even is). So, if that's not working but the old circuit is still used as only the catch-all one gets rotated that's bad.
Changing circuit for page with error switches catch-all circuit instead
The page with error usually is about:*, so that's technically correct to switch its circuit (catch-all), but it's not what is expected. If some error page is caused by bad circuit, then it's necessary to change it, but it's impossible. Thus, tbb-usability-website.
TBB has no feature to remove linkability by switching circuits, everything is perfectly linkable by cookies.
Changing circuit for page with error switches catch-all circuit instead
The page with error usually is about:*, so that's technically correct to switch its circuit (catch-all), but it's not what is expected. If some error page is caused by bad circuit, then it's necessary to change it, but it's impossible. Thus, tbb-usability-website.
TBB has no feature to remove linkability by switching circuits, everything is perfectly linkable by cookies.
Switching circuits is part of the solution to the linkability problem which includes dealing with a bunch of different techniques (like cookies, DOM storage etc.).
That said thanks for you explanation. I think we can better tag this ticket with tbb-usability.
Switching circuits is part of the solution to the linkability problem which includes dealing with a bunch of different techniques (like cookies, DOM storage etc.).
It was. Before FPI. Now it is used and useful for the catch-all circuit only. But it's not a panacea, just a workaround.
That said thanks for you explanation. I think we can better tag this ticket with tbb-usability.
tbb-usability is used for minor things e.g. in GUI, something to think about by ux-team, but not for functionality loss.
torbutton uses gBrowser.contentPrincipal.originAttributes.firstPartyDomain to get the active firstPartyDomain to change circuit. This is set to about.ef2a7dd5-93bc-417f-a698-142c3116864f.mozilla for all about:* pages, including about:neterror and about:certerror which are the cases here. So, if I'm not wrong, changing the circuit when there is a network or ssl error currently changes the circuit for all about:* pages (not the catch-all circuit).
I did not find an obvious way to get the firstPartyDomain causing the error directly from gBrowser.*. Here is a patch that gets it from the url parameter that about:neterror and about:certerror has, which is the original url causing it: https://github.com/acatarineu/torbutton/commit/22538
Another possibility could be forcing a new circuit always when there are network or ssl errors, although I'm not sure if that's desirable.
torbutton uses gBrowser.contentPrincipal.originAttributes.firstPartyDomain to get the active firstPartyDomain to change circuit. This is set to about.ef2a7dd5-93bc-417f-a698-142c3116864f.mozilla for all about:* pages, including about:neterror and about:certerror which are the cases here. So, if I'm not wrong, changing the circuit when there is a network or ssl error currently changes the circuit for all about:* pages (not the catch-all circuit).
I did not find an obvious way to get the firstPartyDomain causing the error directly from gBrowser.*. Here is a patch that gets it from the url parameter that about:neterror and about:certerror has, which is the original url causing it: https://github.com/acatarineu/torbutton/commit/22538
Nice idea and I think that works for now at least. Some review comments:
We have been thinking about constification of code as much as possible (see: legacy/trac#26184 (moved)) but we are not there yet. Thus, please use let for now where you don't have fixed strings. (This means everywhere besides ABOUT_URI_FIRST_PARTY_DOMAIN).
Please put the const at the beginning of the file using a similar naming schema as the other consts we already have.
I think it's not needed to determine origin for every domain we are requesting but only for those that have the about-firstpartydomain. Thus, even if the code is slightly more complex please rewrite that to something like
+ if (isAboutFPD) {+ let knownErrors = ["about:neterror", "about:certerror"];+ let origin = gBrowser.contentPrincipal.origin || '';+ if (knownErrors.some(x => origin.startsWith(x))) {+ try {
Another possibility could be forcing a new circuit always when there are network or ssl errors, although I'm not sure if that's desirable.
Hm, there is the risk of burning a bunch of circuits that way which might not help if a website is poorly configured. So, I think I'd rather avoid that, at least for now.
I'd assume so. What would be helpful is figuring out whether we'd fix legacy/trac#22513 (moved) as well with your patch. If so, we should note this in the commit message and close that bug as well.
Trac: Keywords: TorBrowserTeam201904R deleted, TorBrowserTeam201904 added Status: needs_review to needs_revision
I'd assume so. What would be helpful is figuring out whether we'd fix legacy/trac#22513 (moved) as well with your patch. If so, we should note this in the commit message and close that bug as well.
After the patch, New Circuit for this site should fix those errors. Not handled automatically as the reporter was first suggesting, but I think this is enough to close it as fixed.