Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:13:09Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34305NoScript inconsistent behaviour in Firefox 77 (currently beta)2020-06-16T01:13:09ZAlex CatarineuNoScript inconsistent behaviour in Firefox 77 (currently beta)While working on fixing the testsuite (#27105) I ran into some inconsistent blocking behaviour of NoScript in a Tor Browser WIP build based on Firefox 77 beta.
Basically, the issue is that with Tor Browser `Safer` NoScript configuratio...While working on fixing the testsuite (#27105) I ran into some inconsistent blocking behaviour of NoScript in a Tor Browser WIP build based on Firefox 77 beta.
Basically, the issue is that with Tor Browser `Safer` NoScript configuration when visiting a `http:` page (containing a https: iframe) and then going to the `https:` version of the same page results in JavaScript being blocked, but it should not be. Manually reloading the `https:` page results in JavaScript being executed correctly.
After some effort, I managed to reproduce in current Firefox 77 beta directly, more specifically: `f2e0df68e569b43ca337535927ed63068ed01c664eea7e397378cae668f63d0a firefox-77.0b9.tar.bz2`. Tested with NoScript 11.0.26 and 11.0.25.
Steps to reproduce (in a fresh profile):
- Install NoScript addon.
- Go to NoScript options page (either via about:addons or via NoScript toolbar badge).
- Enable "script" option and "Cascade top document's restrictions to subdocuments" in the General + Default tab.
- Still in General, go to "UNTRUSTED" and enable "frame".
- Go to "Per-site permission" tab and add a new rule: "http:" and mark it as "untrusted" (basically, setting non-https pages as untrusted).
- Open a new tab and visit http://alltaken.xyz/https_iframe.html
- When loaded, open a new tab and visit https://alltaken.xyz/https_iframe.html
- Result: JavaScript is blocked, but it should not be. When the page is manually reloaded (press F5), the script is executed correctly, and the `JavaScriptEnabled` text is displayed.Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/34250Fix torbutton noscript-control race condition2020-06-16T01:13:07ZAlex CatarineuFix torbutton noscript-control race conditionWhile debugging some testsuite tests, I saw some race condition with the noscript initialization which prevents some tests from running correctly.
We currently listen for both `startup` and `pageshow` events [here](https://gitweb.torpro...While debugging some testsuite tests, I saw some race condition with the noscript initialization which prevents some tests from running correctly.
We currently listen for both `startup` and `pageshow` events [here](https://gitweb.torproject.org/torbutton.git/tree/modules/noscript-control.js?id=36f8182a25818548d62b7fbc6be4d2472773b820#n149), and in some tests, `pageshow` events are being received before `startup`, which results in the configuration message being lost and noscript being initialized with the default settings, blocking scripts.
This was originally introduced in #27427, which added checks for the event types precisely because of these issues. However, "pageshow" in specific situations also seems to trigger those.
In that ticket, "pageshow" was added `for a slightly more graceful failure mode in case Torbutton somehow misses NoScript startup`. However, I don't think that can really happen, and I suggest we just listen to `startup`.Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/33965Uplift 27604: Fix addon issues when moving TB directory2020-06-16T01:12:42ZAlex CatarineuUplift 27604: Fix addon issues when moving TB directoryThis is https://bugzilla.mozilla.org/show_bug.cgi?id=1429838, which did not get much attention by mozilla. But we can try attaching our patch and see if there's some progress.This is https://bugzilla.mozilla.org/show_bug.cgi?id=1429838, which did not get much attention by mozilla. But we can try attaching our patch and see if there's some progress.Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/33963Uplift test for 21321 (Add test for .onion whitelisting)2020-06-16T01:12:41ZAlex CatarineuUplift test for 21321 (Add test for .onion whitelisting)It's just making sure that `dom.securecontext.whitelist_onions` is set to `false`, which should not affect Firefox.It's just making sure that `dom.securecontext.whitelist_onions` is set to `false`, which should not affect Firefox.Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/33962Uplift patch for 5741 (dns leak protection)2020-06-16T01:12:41ZAlex CatarineuUplift patch for 5741 (dns leak protection)This should probably be under the `--enable-proxy-bypass-protection` flag.This should probably be under the `--enable-proxy-bypass-protection` flag.Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/33960Uplift patch for "32414: Make Services.search.addEngine obey FPI"2020-06-16T01:12:40ZAlex CatarineuUplift patch for "32414: Make Services.search.addEngine obey FPI"Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/33533Rebase Tor Browser esr68 patches on top of mozilla-central2020-06-16T19:13:45ZAlex CatarineuRebase Tor Browser esr68 patches on top of mozilla-centralAlex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/32414window.external.AddSearchProvider request goes through catch-all-circuit2020-06-16T01:09:26ZAlex Catarineuwindow.external.AddSearchProvider request goes through catch-all-circuitCalling `external.AddSearchProvider(someURL)` does a request that does not follow FPI and goes through the catch-all circuit.Calling `external.AddSearchProvider(someURL)` does a request that does not follow FPI and goes through the catch-all circuit.Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/32255Missing ORIGIN header breaks CORS in Tor Browser 9.02020-06-16T01:10:31ZTracMissing ORIGIN header breaks CORS in Tor Browser 9.0Looks like there is an issue on Tor Browser 9.0 which affects our CORS allowance setup, at least with the dependency django-cors-headers, because it fails to send the expected header ORIGIN in the OPTIONS preflight. It works fine using t...Looks like there is an issue on Tor Browser 9.0 which affects our CORS allowance setup, at least with the dependency django-cors-headers, because it fails to send the expected header ORIGIN in the OPTIONS preflight. It works fine using the latest 8 version. We've noticed this only happens when the CORS request source is a .onion address, otherwise it works as usual.
Example:
public.com XHR OPTIONS >> publicapi.com (ORIGIN HEADER INCLUDED, WORKS)
hidden.onion XHR OPTIONS >> publicapi.com (MISSING ORIGIN HEADER, BREAKS)
hidden.onion XHR OPTIONS >> hiddenapi.onion (MISSING ORIGIN HEADER, BREAKS)
**Trac**:
**Username**: complexparadoxAlex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/31918Rebase and squash mobile and desktop patches2020-06-16T19:16:33ZMatthew FinkelRebase and squash mobile and desktop patchesThe patches for `mobile/android` are separate from the patches for desktop. Some of these patches are similar, such as adding a mozconfig and overriding prefs. Now that Android is a first-class supported platform, we can squash some of t...The patches for `mobile/android` are separate from the patches for desktop. Some of these patches are similar, such as adding a mozconfig and overriding prefs. Now that Android is a first-class supported platform, we can squash some of these patches so we reduce the number of patches we need carry on top of Firefox.Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/30832Fix tor-browser tbb-tests2020-06-16T01:04:56ZAlex CatarineuFix tor-browser tbb-testsWith current rebased tor-browser ESR68 branch I can only run tbb-tests (with `run-tbb-tests` script) when `pref("network.file.path_blacklist", "/net")` is removed and `pref("extensions.torbutton.use_nontor_proxy", true);` is set, apart f...With current rebased tor-browser ESR68 branch I can only run tbb-tests (with `run-tbb-tests` script) when `pref("network.file.path_blacklist", "/net")` is removed and `pref("extensions.torbutton.use_nontor_proxy", true);` is set, apart from disabling tor-launcher. The second pref disables the domain isolator, which makes sense since it expects SOCKS5 proxies, but mochitests override that. For the other pref, not sure why `network.file.path_blacklist` needs to be unset (at least for Linux).
We could put these prefs in `testing/marionette/prefs/marionette.js` so that tests can be run (unless there is a simpler way to get the tests tor run that I'm missing).Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/30431tbb-testsuite: Fix the https-everywhere test2020-06-13T17:41:24Zboklmtbb-testsuite: Fix the https-everywhere testWe should fix the https-everywhere test.
The test is currently failing because http://httpbin.org/ does not get redirected during the test (although it is working outside the test suite).We should fix the https-everywhere test.
The test is currently failing because http://httpbin.org/ does not get redirected during the test (although it is working outside the test suite).Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/28745THE Torbutton clean-up2020-06-16T01:28:24ZGeorg KoppenTHE Torbutton clean-upThat is the parent ticket for all things Torbutton clean-up, now that we included it into `tor-browser`. It's not clear yet how we'll be restructuring it but it's clear that a lot of old cruft has to go. This will be done in child tickets.That is the parent ticket for all things Torbutton clean-up, now that we included it into `tor-browser`. It's not clear yet how we'll be restructuring it but it's clear that a lot of old cruft has to go. This will be done in child tickets.Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/27105Fix Tor Browser testsuite2020-06-16T01:13:09ZboklmFix Tor Browser testsuiteWe need to fix the Tor Browser testsuite to work with esr78 based Tor Browser.We need to fix the Tor Browser testsuite to work with esr78 based Tor Browser.Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/23719Make sure WebExtensions are spared from JIT disabling in higher security sett...2020-06-16T01:09:24ZcypherpunksMake sure WebExtensions are spared from JIT disabling in higher security settings (Medium-High)This could for example negatively affect HTTPS Everywhere's performance. I have however no data on whether JIT is disabled for WebExtensions in this case.This could for example negatively affect HTTPS Everywhere's performance. I have however no data on whether JIT is disabled for WebExtensions in this case.Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/22919Form tracking and OS fingerprinting (only Windows, but without Javascript)2020-06-16T01:08:34ZTracForm tracking and OS fingerprinting (only Windows, but without Javascript)I found out that TOR (/Firefox) is using a weak implementation of a (pseudo)random number generator. On form submission Firefox always sends an unique boundary delimiter together with the POST data. But this unique boundary string isn't ...I found out that TOR (/Firefox) is using a weak implementation of a (pseudo)random number generator. On form submission Firefox always sends an unique boundary delimiter together with the POST data. But this unique boundary string isn't so unique as it looks like.
For example, when you send a multipart form request the number is always the first time: 41184676334, 2nd time: 265001916915724, 3th time: 114782935826962, etc..
Try it yourself: build a multipart form and check the POST data:
```
<form action="/" method="post" enctype="multipart/form-data">
<input type="submit" value="Submit">
</form>
```
```
Content-Type: multipart/form-data; boundary=---------------------------41184676334
Content-Length: 63-----------------------------41184676334--
```
**Threats:**
'''1) OS fingerprinting for Windows
'''It looks like the implementation between Windows and Linux is different. Windows isn't seeding srand() calls. In this way we're 99% sure that boundary string with 41184676334, 265001916915724, 114782935826962 came from a Windows OS.
'''2) "track" form submissions between websites.
'''On website_A I submit a form mulitple times. Now, the owner of website_B is able to read the boundary string and can check how many times a user submitted a form on website_A.
'''3) "track" form interactions on other websites.
'''For example, I'm the owner of website_A, and website_B is a photo upload website. If the user goes from website_A to B and later he came back to my website, I'm able to know if the user uploaded a photo on the other website:
* website_A (boundary: 41184676334)
* website_B (??)
* website_A (boundary: 114782935826962)
As you can see only 265001916915724 is missing, so he did one action on the other website.
'''4) Fake boundaries for file uploads
'''It is possible to inject fake data in a file and let you browser think that you've uploaded 2 files. In this way it is possible to upload 2 files by uploading only one. Of course it also depends on server side validation, but for the browser this seems to be okay. Example on [Bugzilla](https://bugzilla.mozilla.org/show_bug.cgi?id=461204)
**Conclusion:**
Without Javascript we're able to know if an user is running on Windows and we're able to know how many times a user submitted a form (... on another website)
**Technical analysis:**
The [current implementation](https://dxr.mozilla.org/mozilla-central/source/dom/html/HTMLFormSubmission.cpp#430) of the boundary delimiter in Firefox:
```
mBoundary.AssignLiteral("---------------------------");
mBoundary.AppendInt(rand());
mBoundary.AppendInt(rand());
mBoundary.AppendInt(rand());
```
As you can see RAND() is called without seeding this function. Every time you'll (re)start TOR, the browser also resets the seed. Without a good seed the output is of rand is [always predictable](http://statweb.stanford.edu/~serban/116/random.txt). At least on Windows, I think Linux has a different implementation of PRNG.
A solution is to seed RAND() with the PID or something else that's not public (like dates or timestamps).
5 years ago there was also a discussion about this topic on Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=461204
**Trac**:
**Username**: basvdAlex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/21952Onion-location: increasing the use of onion services through automatic redire...2021-03-22T16:56:26ZLinda LeeOnion-location: increasing the use of onion services through automatic redirects and aliasing= Background =
People can't remember, or type in onion sites very easily. We should try to fix this somehow.
ilf is experimenting with automatically redirecting Tor users to .onion versions of websites that they visit (because they ...= Background =
People can't remember, or type in onion sites very easily. We should try to fix this somehow.
ilf is experimenting with automatically redirecting Tor users to .onion versions of websites that they visit (because they want more people to visit onion sites and they will do so if it is painless to them). But when users were redirected automatically to an onion site, they freaked out about it because they didn't know what happened, didn't know what onion sites were, and the "https" was dropped.
asn and dgoulet also were trying to find a solution to make onion sites more accessible to use. Specifically, onion addresses are quite long and random-ish, making them hard to remember and hard to type. There were many solutions discussed casually to try and resolve this, but none stood out as a clear winner.
= Discussion =
I like the idea of redirecting users to .onion sites automatically when they type in the websites non-onion address. This way, users don't need to remember anything else, need to type in anything long, or really even know what onion sites are.
My suggestion is to follow the https design pattern, and create a similar indicator for .onion sites.
![onion-address-idea.png,600px](uploads/onion-address-idea.png,600px)
The proposed solution would be this: when a user types in a website (pad.riseup.net), they would automatically be redirected to the onion site. When this happens, there would be an onion icon next to the address bar (replacing the https lock icon if there is one, or just being there an https lock icon would be if redirection from an http website), similar to that of the https lock icon. The address in the address bar can turned a different color or indicated in some way that this is an alias for the onion site.
From my observation, people don't mind automatically being redirected to https sites from http sites, but freak out when redirected from an http/https site to an onion site. I don't think that this is because people know what https is and find the idea comforting (although this can help). I speculate that they don't mind because they don't notice, and the reason why users freaked out at the redirect to onion sites is that they saw the website address visibly change in the address bar.
Also--
If we want to show users the address of the onion site, we can additionally have a feature to reveal the onion site when the user clicks in the address bar.
![onion-address-secondary-idea.png,600px](uploads/onion-address-secondary-idea.png,600px)
I don't know how I feel about this, since it may just be confusing, and just shock the user later. Users don't know that pad.riseup.net resolves to some numerical IP address, and that isn't displayed to users. So there could be an argument made for just indicating that the address is an alisas and not ever showing the .onion address, either. This will confuse way less of the general population.
= Considerations =
* how should the redirect behavior work?
* how can we implement this without tracking?
* should we allow users to turn off this redirecting behavior?
* should we hide the .onion address from the users more so than the proposal above?Alex CatarineuAlex Catarineu