The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-03-13T17:04:49Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41655Text in the Try Onion Services popup could be clearer2024-03-13T17:04:49ZhenryText in the Try Onion Services popup could be clearerI feel like some of the text in the "Try Onion Services" popup is a bit misleading:
## Title
It is currently "*Try* Onion Services", but this is a setting a preference that will be applied indefinitely, rather than for a short time. So...I feel like some of the text in the "Try Onion Services" popup is a bit misleading:
## Title
It is currently "*Try* Onion Services", but this is a setting a preference that will be applied indefinitely, rather than for a short time. So it seems like it should be more like "Use Onion Services".
## Body
The first sentence is
> There is a more private and secure version of this site available over the Tor network via onion services.
Given the context of this being shown when you visit a HTTPS site, this seems to be telling the user that the current connection they have to the HTTPS site is less private and less secure than if they used the onion site. Moreover, there is no text in the "Learn more" link (https://tb-manual.torproject.org/onion-services/) to back this up. It only says
> All traffic between Tor users and onion services is end-to-end encrypted, so you do not need to worry about connecting over HTTPS
but we already have HTTPS-Only mode in the browser.
In contrast, the second sentence
> Onion services help website publishers and their visitors defeat surveillance and censorship.
is easily understood and backed up.
I feel like maybe this first sentence should be more of a light overview of what an onion service *is*, with the second sentence being the benefits, making it clear what is benefiting the tor browser user.
## Button label
At least for me, "Not Now" tends to mean "I will bother you again in the future until you select the other option", so it can imply the *popup* will shown again for the next onion-available site, even though the user will never see it again. I think this is *trying* to indicate that you can always set this preference in the "Privacy & Security" settings in the future, but that could just be part of the body text if it is important.
## Design estimate:
* Complexity: low (1 days)
* Think about:
* How would a new user understand this? Do a mini user journey.
* What are the different ways the copy / design can be misunderstood?
* Ask:
* What is this thing?
* How does it benefit me?
* What are you asking me to do?
* Uncertainty level: high (2)
* I don't do much copy, so it's a bit of a challenge for me.
* There could be lenghty back and forth between stakeholders discussing the copy.
* Total: 1-2 dayshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41620Improve the UX of the request a bridge dialog2024-03-05T18:48:23ZdonutsImprove the UX of the request a bridge dialogFollowing recent improvements to the built-in bridges (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41617) and provide a bridge dialogs (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552), w...Following recent improvements to the built-in bridges (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41617) and provide a bridge dialogs (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40552), we should also take a look at improving the UX of the request a bridge dialog. However it makes sense to wait on the outcome of https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/49 first, where the Anti-Censorship team will be considering a new CAPTCHA strategy.https://gitlab.torproject.org/tpo/core/arti/-/issues/767Want test cases from C Tor for hs time period calculations2023-10-10T16:14:55ZIan Jacksoniwj@torproject.orgWant test cases from C Tor for hs time period calculationsIn !987 we implemented the HS time period calculations. These are super complicated and confusing.
C Tor has a set of test cases in `src/test/test_hs_common.c` in `test_client_service_hsdir_set_sync` and nearby. We should try to copy ...In !987 we implemented the HS time period calculations. These are super complicated and confusing.
C Tor has a set of test cases in `src/test/test_hs_common.c` in `test_client_service_hsdir_set_sync` and nearby. We should try to copy all these into Arti as test vectors, to make sure we do precisely the same thing as C Tor.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/766Should cargo-audit become advisory in CI?2023-04-25T15:39:30ZNick MathewsonShould cargo-audit become advisory in CI?Twice in the last 24 hours, I have had a branch where CI was passing before start failing because a package _which was okay when I opened the branch_ became insecure before the branch was merged.
Maybe we should make this an advisory fa...Twice in the last 24 hours, I have had a branch where CI was passing before start failing because a package _which was okay when I opened the branch_ became insecure before the branch was merged.
Maybe we should make this an advisory failure, and not have it make the branch unmergeable? OTOH, if we ignore this warning, it could allow us to merge known-insecure crates.https://gitlab.torproject.org/tpo/core/arti/-/issues/764Review use of manual slicing operations2023-10-10T16:14:56ZIan Jacksoniwj@torproject.orgReview use of manual slicing operationsIdeally we would avoid, as much as possible, manual slicing operations on any kind of buffers. We should use abstractions which avoid mistaken lengths etc. We're pretty good with this for parsing/writing binary messages, but it mostly ...Ideally we would avoid, as much as possible, manual slicing operations on any kind of buffers. We should use abstractions which avoid mistaken lengths etc. We're pretty good with this for parsing/writing binary messages, but it mostly goes out of the window when we do cryptography.
This should be improved. The work involves reviewing existing code, designing new abstractions, and deploying them.
```
16:10 <+Diziet> [much context elided]
https://security-tracker.debian.org/tracker/CVE-2022-2097
16:10 <+Diziet> Nowadays I always read things like this wearing my RESF beanie.
16:10 <+Diziet> And I wondered, could we have a bug like this?
16:11 <+Diziet> And sadly the answer is yes, because our pattern for applying a
stream cipher is to apply it to &mut [u8]
16:12 <+Diziet> And we sometimes slice and dice buffers rather than using
Readers and things.
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40747android: fdsan SIGABRT tor_main_configuration_free2023-04-12T14:45:21Zsbsandroid: fdsan SIGABRT tor_main_configuration_free### Summary
When testing tor-0.4.7.13 on Android 13, I experienced a `SIGABRT` in `tor_main_configuration_free` caused by [fdsan](https://android.googlesource.com/platform/bionic/+/master/docs/fdsan.md). The reason why fdsan causes an a...### Summary
When testing tor-0.4.7.13 on Android 13, I experienced a `SIGABRT` in `tor_main_configuration_free` caused by [fdsan](https://android.googlesource.com/platform/bionic/+/master/docs/fdsan.md). The reason why fdsan causes an abort is that the owning control socket is closed twice. I noticed this crash as part of testing a release candidate of [OONI Probe Android](https://github.com/ooni/probe-android/) where we embed `libtor.a`.
The corresponding OONI Probe issue is: https://github.com/ooni/probe/issues/2405.
### Steps to reproduce
I do not have a very simple procedure to reproduce the issue that does not involve OONI Probe and its build system.
However, the underlying issue is independent of Android. The only reason why Android matters is that the fdsan notices the double close of the same file descriptor and hence triggers a crash (for Android API level >= 30).
Because of this, here are instructions to reproduce the underlying issue using GNU/Linux (I used Ubuntu 22.04):
1. clone tor
2. `git checkout tor-0.4.7.13`
3. `git apply tor.diff` where `tor.diff` is the following patch:
```diff
diff --git a/src/core/mainloop/connection.c b/src/core/mainloop/connection.c
index cf25213cb1..d690de3892 100644
--- a/src/core/mainloop/connection.c
+++ b/src/core/mainloop/connection.c
@@ -149,6 +149,8 @@
#include "core/or/congestion_control_flow.h"
+#include <stdio.h>
+
/**
* On Windows and Linux we cannot reliably bind() a socket to an
* address and port if: 1) There's already a socket bound to wildcard
@@ -949,6 +951,7 @@ connection_free_minimal(connection_t *conn)
if (SOCKET_OK(conn->s)) {
log_debug(LD_NET,"closing fd %d.",(int)conn->s);
+ fprintf(stderr, "SBSDEBUG: connection_free_minimal %lld\n", (long long)conn->s);
tor_close_socket(conn->s);
conn->s = TOR_INVALID_SOCKET;
}
diff --git a/src/feature/api/tor_api.c b/src/feature/api/tor_api.c
index 88e91ebfd5..fb49d92ad7 100644
--- a/src/feature/api/tor_api.c
+++ b/src/feature/api/tor_api.c
@@ -116,6 +116,11 @@ tor_main_configuration_setup_control_socket(tor_main_configuration_t *cfg)
cfg_add_owned_arg(cfg, "__OwningControllerFD");
cfg_add_owned_arg(cfg, buf);
+ fprintf(
+ stderr, "SBSDEBUG: tor_main_configuration_setup_control_socket %lld %lld\n",
+ (long long)fds[0], (long long)fds[1]
+ );
+
cfg->owning_controller_socket = fds[1];
return fds[0];
}
@@ -132,6 +137,10 @@ tor_main_configuration_free(tor_main_configuration_t *cfg)
raw_free(cfg->argv_owned);
}
if (SOCKET_OK(cfg->owning_controller_socket)) {
+ fprintf(
+ stderr, "SBSDEBUG: tor_main_configuration_free %lld\n",
+ (long long)cfg->owning_controller_socket
+ );
raw_closesocket(cfg->owning_controller_socket);
}
raw_free(cfg);
```
4. `./autogen.sh`
5. `./configure --disable-asciidoc`
6. `make`
7. `mkdir tmp`
8. `vi tmp/main.c` making sure it contains the following content:
```C
#include "../src/feature/api/tor_api.h"
#include <stdlib.h>
#include <unistd.h>
int main() {
tor_main_configuration_t *cfg = tor_main_configuration_new();
if (cfg == NULL) {
exit(1);
}
tor_control_socket_t sock = tor_main_configuration_setup_control_socket(cfg);
if (sock == INVALID_TOR_CONTROL_SOCKET) {
exit(2);
}
(void)close(sock); // close immediately (it's async on Android but it should not matter AFAICT)
(void)tor_run_main(cfg);
tor_main_configuration_free(cfg);
}
```
9. `gcc -Wall tmp/main.c -L. -ltor -levent -lcrypto -lssl -lz -lm`
10. `./a.out` which should produce this output:
```
SBSDEBUG: tor_main_configuration_setup_control_socket 4 5
Feb 02 17:18:07.330 [notice] Tor 0.4.7.13 (git-7c1601fb6edd780f) running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.2, Zlib 1.2.11, Liblzma N/A, Libzstd N/A and Glibc 2.35 as libc.
Feb 02 17:18:07.330 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
Feb 02 17:18:07.330 [notice] Configuration file "/usr/local/etc/tor/torrc" not present, using reasonable defaults.
Feb 02 17:18:07.331 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 02 17:18:07.331 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9050
Feb 02 17:18:07.000 [notice] Bootstrapped 0% (starting): Starting
Feb 02 17:18:07.000 [notice] Starting with guard context "default"
Feb 02 17:18:07.000 [notice] Owning controller connection has closed -- exiting now.
SBSDEBUG: connection_free_minimal 5
Feb 02 17:18:07.000 [notice] Catching signal TERM, exiting cleanly.
SBSDEBUG: connection_free_minimal 8
SBSDEBUG: tor_main_configuration_free 5
```
If you analyze the above output, you would see that the file descriptor `5` is closed twice. This output is almost identical to the output that I have seen in the Android logcat (more on that below). Also, I _think_ the way in which I am using the embedding API above (which mirrors our more complex implementation written in Go) is fine; if not, please educate me.
(If you want to reproduce the same problem I experience on Android, I can either explain how to compile and test OONI Probe for Android, or I can try to work on creating a simple Android PoC like the one above.)
### What is the current bug behavior?
We're in an embedding scenario where we eventually call `tor_run_main`, as mentioned in the previous section.
This is the sequence of APIs we call along with my best understanding of what happens inside `tor`:
We create a configuration using `tor_main_configuration_new`.
Calling `tor_main_configuration_setup_control_socket` creates a pair of sockets, returns `fds[0]` to us, and retains `fds[1]` inside `tor_main_configuration_t::owning_controller_socket`.
Calling `tor_run_main` calls (in a way that is not 100% clear to me) `options_act` that passes the `owning_controller_socket` to `control_connection_add_local_fd`. In turn, this function registers the file descriptor `fds[1]` as the control connection.
Eventually we `close` the `fds[0]` that was returned to us, which causes `tor` to stop its libevent loop.
When `tor_run_main` terminates, it calls `tor_cleanup`, which calls `tor_free_all`, which calls `connection_free_all`, which calls `connection_free_minimal` for each connection, including the owning file descriptor `fds[1]`.
After `tor_run_main`, we call `tor_main_configuration_free`. In turn, this function calls `raw_closesocket` on the `owning_controller_socket`, which is hence closed for the second time.
On Android with API level >= 30, the [fdsan](https://android.googlesource.com/platform/bionic/+/master/docs/fdsan.md) sanitizer notices the second close and _sometimes_ (roughly 50%) this fact causes the app to abort.
### What is the expected behavior?
I think tor should duplicate the file descriptor before registering it into the core event loop such that there is a single owner of each of the two duplicates. The `tor_main_configuration_free` function owns one of them and the core event loop owns the other one. This semantics shouldn't cause any issue with the fdsan sanitizer because it's designed to enforce it.
Alternatively, it should probably be documented to use API level < 30 (where the fdsan only warns). Or it should be documented that one should use the proper fdsan API to disable crashing on double close. (I do not remember seeing these warnings when I read how to use the embedding API and a quick `git grep fdsan` or `git grep "API level"` did not return anything, but it's still possible that I overlooked _some_ documentation about this issue.)
### Environment
- Which version of Tor are you using?
tor-0.4.7.13
- Which operating system are you using?
Android 13 (but I also provided a minimal example on GNU/Linux)
- Which installation method did you use?
We cross compile tor for Android using [our cross compilation scripts](https://github.com/ooni/probe-cli/tree/v3.17.0-alpha.1/internal/cmd/buildtool).
We obtain a static set of libraries and a `tor_api.h` that we link as part of building an AAR with [go mobile](https://github.com/golang/mobile).
We use the obtained AAR as a dependency for [OONI Probe Android](https://github.com/ooni/probe-android/).
The code that specifically invokes tor [is written in Go](https://github.com/ooni/probe-android/). The sequence of events in terms of the Tor embedding API is the one I described above in the "what is the current bug behavior?" section.
However, I have also provided a minimal example for GNU/Linux that shows the double-close issue.
### Relevant logs and/or screenshots
The following is an excerpt from the tombstone generated by the crashing app:
```
[notice] Catching signal TERM, exiting cleanly.
fdsan: attempted to close file descriptor 104, expected to be unowned, \
actually owned by unique_fd 0x70b7e5f19c
[...]
ABI: 'arm64'
Timestamp: 2023-02-02 11:39:31.181519664+0100
Cmdline: org.openobservatory.ooniprobe.experimental
pid: 16472, tid: 16593, name: AsyncTask #1 >>> org.openobservatory.ooniprobe.experimental <<<
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
[...]
backtrace:
#00 pc 0000000000055c48 .../lib64/bionic/libc.so (fdsan_error(char const*, ...)+556) (...)
#01 pc 0000000000055954 .../lib64/bionic/libc.so (android_fdsan_close_with_tag+732) (...)
#02 pc 00000000000560a8 .../lib64/bionic/libc.so (close+16) (...)
#03 pc 00000000012ad08c [...]/lib/arm64/libgojni.so (tor_main_configuration_free+128)
```
If I apply the patch that above I called `tor.diff` and run OONI Probe on Android, I see this in the logcat:
```
SBSDEBUG: tor_main_configuration_setup_control_socket 94 98 // <- fds[0] and fds[1]
[...]
[notice] Catching signal TERM, exiting cleanly.
SBSDEBUG: connection_free_minimal 141
SBSDEBUG: connection_free_minimal 98 // <- first close of fds[1]
SBSDEBUG: connection_free_minimal 116
SBSDEBUG: connection_free_minimal 152
SBSDEBUG: tor_main_configuration_free 98 // <- second close of fds[1]
```
### Possible fixes
The following patch makes the app work as intended (i.e., no crashes for several runs):
```diff
diff --git a/src/feature/api/tor_api.c b/src/feature/api/tor_api.c
index 88e91ebfd5..2773949264 100644
--- a/src/feature/api/tor_api.c
+++ b/src/feature/api/tor_api.c
@@ -131,9 +131,13 @@ tor_main_configuration_free(tor_main_configuration_t *cfg)
}
raw_free(cfg->argv_owned);
}
+ /* See https://github.com/ooni/probe/issues/2405 to understand
+ why we're not closing the controller socker here. */
+ /*
if (SOCKET_OK(cfg->owning_controller_socket)) {
raw_closesocket(cfg->owning_controller_socket);
}
+ */
raw_free(cfg);
}
```
That said, I think this patch is wrong because it leaks the file descriptor when `tor_run_main` returns prematurely (e.g., when the command line flags are wrong). Because of this, I think the more robust fix would be to duplicate the file descriptor before registering it into the libevent loop, as I explained above.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/754should upgrading *some* dependancies be considered a breaking change2023-04-25T15:37:54Ztrinity-1686ashould upgrading *some* dependancies be considered a breaking changeUpgrading some dependencies can break downstream integrator. In particular, going from `rusqlite` 0.27 to 0.28 prevented a seamless upgrade of onionmasq from arti-some-old-version to arti-1.1.0, because 0.27 and 0.28 can't live together ...Upgrading some dependencies can break downstream integrator. In particular, going from `rusqlite` 0.27 to 0.28 prevented a seamless upgrade of onionmasq from arti-some-old-version to arti-1.1.0, because 0.27 and 0.28 can't live together apparently.
(found while working on onionmasq.)https://gitlab.torproject.org/tpo/core/tor/-/issues/40746Conflicting logic about whether bridges need descriptors for fetching dir inf...2023-04-12T14:42:46ZRoger DingledineConflicting logic about whether bridges need descriptors for fetching dir info from themIf you start your Tor with a pile of configured bridges but nothing cached, your Tor will sample the configured bridges to pick its ordered list of primary entry guards, and launch descriptor fetches to each of them.
But if the descript...If you start your Tor with a pile of configured bridges but nothing cached, your Tor will sample the configured bridges to pick its ordered list of primary entry guards, and launch descriptor fetches to each of them.
But if the descriptor hasn't arrived yet, while trying to bootstrap dir info you get these confusing messages in your logs:
```
Jan 31 18:56:44.928 [notice] Ignoring directory request, since no bridge nodes are available yet.
```
Things do bootstrap eventually, but it takes longer than it should, and the pile of scary log messages is scary.
What's going on here?
The way the log message comes about is that directory_get_from_dirserver() calls
```
const node_t *node = guards_choose_dirguard(dir_purpose, &guard_state);
if (node && node->ri) {
[...]
} else {
[...]
log_notice(LD_DIR, "Ignoring directory request, since no bridge "
"nodes are available yet.");
}
```
i.e. guards_choose_dirguard had better return a bridge for which we have the descriptor, or we're going to log a complaint and abort the directory fetch attempt.
But in select_primary_guard_for_circuit(), we do
```
const int need_descriptor = (usage == GUARD_USAGE_TRAFFIC);
[...]
SMARTLIST_FOREACH_BEGIN(gs->primary_entry_guards, entry_guard_t *, guard) {
[...]
if (guard->is_reachable != GUARD_REACHABLE_NO) {
if (need_descriptor && !guard_has_descriptor(guard)) {
log_info(LD_GUARD, "Guard %s does not have a descriptor",
entry_guard_describe(guard));
continue;
}
```
That is, in select_primary_guard_for_circuit() we require that the bridge have a descriptor only for the GUARD_USAGE_TRAFFIC case, but then in directory_get_from_dirserver() we expect that the bridge will always have a descriptor, even in the GUARD_USAGE_DIRGUARD case.
In normal operation this bug isn't a big deal, because it is a race to finish fetching the descriptor before we happen to pick it for asking directory info. But with the #40578 fix, where we defer fetching the descriptor if we won't use the bridge for the GUARD_USAGE_TRAFFIC case, the bug becomes more obvious.
I believe the fix is simply to always need_descriptor in select_primary_guard_for_circuit() -- meaning when we're going to launch a directory fetch we always choose among our primary guards who have descriptors already.https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/135Refactor code from onbrisca to onbasca2024-01-24T11:55:05ZjugaRefactor code from onbrisca to onbascajugajugahttps://gitlab.torproject.org/tpo/core/arti/-/issues/738Write a proxy-plus-socketpair wrapper for DataStream2024-02-24T18:32:24ZNick MathewsonWrite a proxy-plus-socketpair wrapper for DataStreamIn order to provide FFI for the most general purposes, we'll need to provide real sockets. That implies a socketpair, one side of which we give to the application, and the other side of which is backed by a `DataStream`.
This is necessa...In order to provide FFI for the most general purposes, we'll need to provide real sockets. That implies a socketpair, one side of which we give to the application, and the other side of which is backed by a `DataStream`.
This is necessary for #737
See [`ExportedApiSketch.md`](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/doc/dev/ExportedApiSketch.md) for early thoughts.Arti: RPC Supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/737Prototype a basic FFI interface for experimentation2024-02-15T15:15:07ZNick MathewsonPrototype a basic FFI interface for experimentationWe should design and prototype a basic FFI interface for Arti. It doesn't need to be complete, but we need to start getting feedback now in order to usefully complete %"Arti: Feature parity with the C implementation".
See [`ExportedApi...We should design and prototype a basic FFI interface for Arti. It doesn't need to be complete, but we need to start getting feedback now in order to usefully complete %"Arti: Feature parity with the C implementation".
See [`ExportedApiSketch.md`](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/doc/dev/ExportedApiSketch.md) for early thoughts.Arti: RPC SupportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41582Tor Browser Android app context menu still has option to open "New Tab" (not ...2023-08-26T06:09:43ZDan BallardTor Browser Android app context menu still has option to open "New Tab" (not private). Crashes when invokedTor Browser Android app has a context menu item on the app on home screen's for "New Tab" (the non private version). This should not appear. Semi thankfully, when invoked, tor browser seems to crash and restart.
This menu item should be...Tor Browser Android app has a context menu item on the app on home screen's for "New Tab" (the non private version). This should not appear. Semi thankfully, when invoked, tor browser seems to crash and restart.
This menu item should be removedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40739[warn] Possible compression bomb; abandoning stream.2023-11-18T19:42:40Zcomputer_freak[warn] Possible compression bomb; abandoning stream.Relay with `Tor 0.4.7.13`:
```
[warn] Possible compression bomb; abandoning stream.
[warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 86.59.21.38:80).
```
obfs4 Bridge with ...Relay with `Tor 0.4.7.13`:
```
[warn] Possible compression bomb; abandoning stream.
[warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 86.59.21.38:80).
```
obfs4 Bridge with `Tor 0.4.7.13`:
```
[warn] Possible compression bomb; abandoning stream.
[warn] Error while uncompressing data: bad input?
[warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 95.214.53.221:443).
```
Relay with `Tor 0.4.8.0-alpha-dev`:
```
[warn] Possible compression bomb; abandoning stream.
[warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 199.58.81.140:80).
```
There are no more logs on `notice` log level.
A user at the [forum](https://forum.torproject.net/t/compression-bomb-in-tor-logs/6226) has the same problem.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41555HTTPS-only warning page (from Firefox) not suited for tor browser context2024-02-27T19:08:10ZhenryHTTPS-only warning page (from Firefox) not suited for tor browser contextCurrently, if you try and visit a HTTP website, like http.badssl.com, you get a warning page. But the text of the warning page comes from Firefox, and is not really suited for Tor Browser.
![screenshot of HTTPS-Only warning page](/uploa...Currently, if you try and visit a HTTP website, like http.badssl.com, you get a warning page. But the text of the warning page comes from Firefox, and is not really suited for Tor Browser.
![screenshot of HTTPS-Only warning page](/uploads/166669f773488064f40f4b3c3f33f151/Screenshot_from_2023-01-06_15-50-08.png)
Currently it says
> **HTTPS-Only Mode Alert**
>
> **Secure Site Not Available**
>
> You’ve enabled HTTPS-Only Mode for enhanced security, and a HTTPS version of http.badssl.com is not available.
The first part should probably be more like
> HTTPS-Only Mode is enabled in Tor Browser for enhanced security
since it is not a user choice to turn this on. Plus, the second part should probably be
> a HTTPS version of http.badssl.com was not found.
since the HTTPS version could be available on another circuit (or it may have been triggered by a timeout as in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41068).
In addition, the "Learn More…" link takes the user to https://support.mozilla.org/en-US/kb/https-only-prefs which includes a good explanation of HTTP vs HTTPS, but it has no Tor Browser or network context and gives instructions on how to turn on or off https-only mode.
Finally, we should probably let the user know that sometimes reloading the page with a new circuit can establish a HTTPS connection (e.g. if your current exit node is bad), and perhaps give them a button to do so.https://gitlab.torproject.org/tpo/core/arti/-/issues/717arti-based obfs4 quick reachability monitor2024-03-27T09:38:10ZRoger Dingledinearti-based obfs4 quick reachability monitorIn the "Better bridgestrap designs to quickly detect bridges going offline" section of https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035, I describe a tool we need that will notice when bridges go down ...In the "Better bridgestrap designs to quickly detect bridges going offline" section of https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40035, I describe a tool we need that will notice when bridges go down / get blocked. One goal is to notice quickly enough that we can use the reachability result in the "bridge subscription" approach (https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/42) where clients auto-ask for a replacement when one of their bridges goes down.
* [ ] Part one, a feature replacement for bridgestrap. That is, we need to take in a set of bridge lines to test (e.g. via an http post from rdsys, but we can do that interface however both sides like), launch connections to them, learn success or failure, and report it both in response to the request from rdsys and also write it out to a file like the ones here: https://collector.torproject.org/recent/bridgestrap/
* [ ] Part two, the new feature: we want to learn, for each bridge that we think is currently up, the moment that it goes down. The goal is that clients will start coming to rdsys asking for a replacement bridge when they think one of their bridges goes down, and we want rdsys to already have our 'ground truth' answer by the time the client makes that request. The naive approach would be to connect to each bridge every 10 seconds or something using the 'part one' approach from above. But I think the better option is to *hold open* connections to each bridge, and then notice when a connection breaks. We will still be subject to TCP issues where sometimes it takes a while to notice a broken connection, but this approach is a low-cost way to get results within a 60-ish second response time range.
Some details that make 'part two' more complicated than we might first think:
* We still need to launch new connections every so often too, to detect the case where the bridge stays up for existing connections but somehow gets firewalled for new ones. How often to launch those connections is a parameter we should explore, to find a good balance between being thorough vs limiting our overall connection volume.
* Can the obfs4proxy tool handle hundreds or thousands of client connections, or does something fail at that scale? I don't know the answer, but if we discover scaling issues, we should either debug and resolve them, or maybe we work around them and use them as motivation to switch to the "arti runs a rust obfs4 thread" model that we already want to get to eventually.
* If we simply make a connection to an obfs4 bridge and then try to hold it open, the bridge will expire and close that connection after a few minutes because it has no circuits on it. So we need to come up with a suitable trick for convincing the bridge to not expire the connection. Is making a one-hop circuit and leaving it open enough, or does it get expired after a while? How about if you put a dir stream on it? Worst case we can make a two-hop circuit, but it would be unfortunate if that's our best option: if we pick a new second hop each time, we undermine our bridge enumeration defenses (strategy 2 on https://blog.torproject.org/research-problems-ten-ways-discover-tor-bridges/), whereas if we pick one relay to use every time (e.g. Serge), everything fails if that relay goes away for a bit.
The eventual deployment vision is that (a) we run this tool in a safe uncensored location, where the goal is to get ground truth about upness; if it scales well we run one to test every bridge, or if needed we run a farm of them where each instance handles its fair share of the bridges, and then (b) we run one of these tools inside each censored area, where it does tests on demand and we only give it an address to test if our uncensored location says it's up but a threshold of clients have come to us saying it's down in their location.https://gitlab.torproject.org/tpo/core/tor/-/issues/40735[WARN] Tried connecting to router ... identity keys were not as expected2023-11-14T16:59:05Zcypherpunks[WARN] Tried connecting to router ... identity keys were not as expectedBackground: Tor Browser 12.0, Tor 4.7.12, Windows 7, vanilla bridges.
Repeatedly getting the following log line.
```
[WARN] Tried connecting to router at *address* ID=<none> RSA_ID=*FP1*, but RSA + ed25519 identity keys were not as exp...Background: Tor Browser 12.0, Tor 4.7.12, Windows 7, vanilla bridges.
Repeatedly getting the following log line.
```
[WARN] Tried connecting to router at *address* ID=<none> RSA_ID=*FP1*, but RSA + ed25519 identity keys were not as expected: wanted *FP1* + no ed25519 key but got *FP2* + *edFP*.
```
Ideas of what happened:
* MITM
* Bridge operator reinstalled it in-between me getting the bridge and now.
What is wrong:
* Bridge should be marked as unreachable: either it is not used already and connections are doomed to spend resources for nothing, or it should not be used as something is clearly wrong with it
* There should be a way to distinguish first idea from second - my best guess is building a tunneled directory connection to bridge authority and asking "Is there a bridge *FP2* and does it listen on *address*?"https://gitlab.torproject.org/tpo/core/arti/-/issues/711Use cargo-semver-checks or such to enforce stability in high-level APIs2023-05-31T18:41:09ZNick MathewsonUse cargo-semver-checks or such to enforce stability in high-level APIsThe `arti-client` crate depends on, and exposes, APIs from a bunch of other crates. As such, it is tricky to make sure that we haven't made any changes that **unintentionally** break compatibility with past versions of `arti-client`.
We...The `arti-client` crate depends on, and exposes, APIs from a bunch of other crates. As such, it is tricky to make sure that we haven't made any changes that **unintentionally** break compatibility with past versions of `arti-client`.
We should open other tickets (eg #710, #712) to limit the risk of breaking changes. But it would also be good to use what tooling we can to detect breaking changes, possibly as part of CI. We could, for example, enforce that there is a breaking semver change iff there is a BREAKING comment in semver.md.
The current front-runner seems to be [`cargo-semver-checks`](https://crates.io/crates/cargo-semver-checks), which claims to have no false positives (only false negatives). I haven't been able to figure out out to make it work, but hey, who knows.Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/core/arti/-/issues/707have a way to get underlying file descriptors2023-01-18T14:07:23Ztrinity-1686ahave a way to get underlying file descriptorsCurrently the TCP/UDP types returned by a Runtime are opaque: there is no way to access the underlying file descriptor.
Access to that file descriptor is a requirement to implement transparent proxy (part of #72), and I suspect it woul...Currently the TCP/UDP types returned by a Runtime are opaque: there is no way to access the underlying file descriptor.
Access to that file descriptor is a requirement to implement transparent proxy (part of #72), and I suspect it would make onionmasq#23 easier (right now I think they'll have to implement their own TcpProvider, not wrapping arti default, to be able to get that).
It'll be kind of an issue with regard to crossplarformness: Windows has no FD, it has file handles which are mostly the same, but I guess different in some ways. Also some runtimes might not have backing fds for whatever reason, so returning a fd should probably be optionalArti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/web/manual/-/issues/137Add section about crypto warning popup2022-12-17T15:19:26ZdonutsAdd section about crypto warning popupSee https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41363 for the most recent work happening on this component, and https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40899#note_2863965 for discussion...See https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41363 for the most recent work happening on this component, and https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40899#note_2863965 for discussion about the support URL.
tl;dr we have a `Learn more` link in the wingpanel that currently points to support-dot, which presumably was a temporary measure until dedicated content could be created.https://gitlab.torproject.org/tpo/tpa/prometheus-alerts/-/issues/9Add alerts for network health relays2024-03-27T09:45:19ZGeorg KoppenAdd alerts for network health relaysWe have some relays and their metrics scraped via Prometheus (namely akka, ukko, d2d4, and Najdorf). We should work on alerts so we can avoid stumbling into some or all of the metrics not being exposed anymore in our dashboards due to $i...We have some relays and their metrics scraped via Prometheus (namely akka, ukko, d2d4, and Najdorf). We should work on alerts so we can avoid stumbling into some or all of the metrics not being exposed anymore in our dashboards due to $issue (as witnessed in tpo/network-health/team#281).
/cc @hiro, @dgouletGeorg KoppenGeorg Koppen