The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-03-31T18:26:08Zhttps://gitlab.torproject.org/tpo/community/support/-/issues/40065Delivery of letters from TorProject to Russian email services2022-03-31T18:26:08ZninaDelivery of letters from TorProject to Russian email servicesEmail services in Russian can downgrade and send into spam emails from emails from certain senders.
Can we check once in a period the delivery of emails from TorProject?
This issue is to test if frontdesk@tpo replies are being delivere...Email services in Russian can downgrade and send into spam emails from emails from certain senders.
Can we check once in a period the delivery of emails from TorProject?
This issue is to test if frontdesk@tpo replies are being delivered to popular mail services in Russia.
The most popular email services in Russia:
Mail.ru and yandex.ruSponsor 125: Rapid Response Fund for Russia censorship circumventionninaninahttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40625Clean up lektor-staging.tpo off of static mirrors2022-02-15T14:47:35ZJérôme Charaouilavamind@torproject.orgClean up lektor-staging.tpo off of static mirrors@emmapeel confirmed we can get rid of it, as it isn't in use anymore.@emmapeel confirmed we can get rid of it, as it isn't in use anymore.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804Tor Browser's new obfs4proxy client has compatibility issues with old obfs4pr...2022-11-22T13:00:04ZatariTor Browser's new obfs4proxy client has compatibility issues with old obfs4proxy bridges<!--
* Use this issue template for reporting a new bug.
-->
### Summary
When starting TB 11.0.6 on Linux with self-defined bridges at bootstrapping following messages show up in log multiple times:
[WARN] Proxy Client: unable to connec...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
When starting TB 11.0.6 on Linux with self-defined bridges at bootstrapping following messages show up in log multiple times:
[WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with [omitted] ID=[omitted] RSA_ID=[omitted] (“general SOCKS server failure”)
Bridges work after bootstrapping. Warnings irritate anyhow.
### Steps to reproduce:
Set some bridge-lines in TB config and restart the browser
### What is the current bug behavior?
Tor Logs show these warnings multiple times:
[WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with [omitted] ID=[omitted] RSA_ID=[omitted] (“general SOCKS server failure”)
### What is the expected behavior?
No warning like in the builds before
### Environment
Tor Browser 11.0.6 downloaded via auto-update | Linux Debian
Started with ~/tor-browser_en-US/Browser/start-tor-browser
### Relevant logs and/or screenshots
Multiple times:
[WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with [omitted] ID=[omitted] RSA_ID=[omitted] (“general SOCKS server failure”)https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40022Graphs for multiple relays that have the same fingerprint2022-04-13T11:40:42ZDavid Fifielddcf@torproject.orgGraphs for multiple relays that have the same fingerprintThis is a feature request for an unusual relay configuration.
The Snowflake bridge is getting more and more traffic, which caused the tor process to become a bottleneck. We removed the bottleneck by running 4 instances of tor on the hos...This is a feature request for an unusual relay configuration.
The Snowflake bridge is getting more and more traffic, which caused the tor process to become a bottleneck. We removed the bottleneck by running 4 instances of tor on the host, all having the same identity keys, with a load balancer in front of them. For details, see the [bridge installation guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide), the [tor-relays thread](https://forum.torproject.net/t/tor-relays-how-to-reduce-tor-cpu-load-on-a-single-bridge/1483), and tpo/anti-censorship/pluggable-transports/snowflake#40095. The short summary is that where we formerly there was one instance of tor:
|nickname|hashed fingerprint|
|---|---|
|flakey|5481936581E23D2D178105D44DB6915AB06BFB7F|
There are now 4 instances, all independently uploading descriptors:
|nickname|hashed fingerprint|
|---|---|
|flakey1|5481936581E23D2D178105D44DB6915AB06BFB7F|
|flakey2|5481936581E23D2D178105D44DB6915AB06BFB7F|
|flakey3|5481936581E23D2D178105D44DB6915AB06BFB7F|
|flakey4|5481936581E23D2D178105D44DB6915AB06BFB7F|
The problem is that multiple descriptors for the same fingerprint currently result in inaccurate metrics graphs, include [Relay Search](https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB6915AB06BFB7F) and [Bridge users by transport](https://metrics.torproject.org/userstats-bridge-transport.html?start=2021-11-09&end=2022-02-07&transport=snowflake). [What we think is happening](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40095#note_2774445) is that the analysis programs are, in effect, choosing one instance per day as a representative for the fingerprint. Since there are 4 instances, the numbers are are 1/4 as large as they should be. Also, during the load balancing upgrade, we were running a separate [staging server](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40095#note_2772325), so there were actually 8 instances running at time (4 used, 4 unused), which causes the graph to go to zero on some days. Like Roger says: "the metrics world will think it is a single bridge that keeps changing its mind about its past bandwidth use and other stats."
Take a look at the Relay Search graphs. The anomalies start on 2022-01-25, which is [this comment](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40095#note_2772325).
|bandwidth|clients|
|---|---|
|![written/read bytes per second](/uploads/89eeac4b3677c31b373c4ad1030dc8a7/flakey-rs-bw-6m-20220207.png)|![average number of connected clients](/uploads/c820a39c87455f7eaf4fc09afe6f3604/flakey-rs-clients-6m-20220207.png)|
If the graphs showed all instances together, rather than one instance at a time, they would look like this:
|bandwidth|clients|
|---|---|
|![Snowflake bandwidth, combined instances](/uploads/8a6ddb673c41375d376634e088965fc0/flakey-bw-combined.png)|![Snowflake clients, combined instances](/uploads/8e76c3ddab323081a0e554ea344cece7/flakey-clients-combined.png)|
I made the graphs by processing [bridge-extra-info](https://metrics.torproject.org/collector.html#type-bridge-extra-info) descriptors from Collector, in a multi-instance-aware way ([R and Python source code](/uploads/82ef8f7e9da50ac0973149101ac39285/flakey-extra-info-20220207.zip)), following the Reproducible Metrics guidelines for [Consumed bandwidth](https://metrics.torproject.org/reproducible-metrics.html#consumed-bandwidth) and [Bridge users](https://metrics.torproject.org/reproducible-metrics.html#bridge-users). The difference is that I use *fingerprint*+*nickname* as a bridge identifier, not just *fingerprint*. A later descriptor with the same fingerprint but a different nickname *adds* to the day's total, instead of replacing it. (I am not sure, but I think [here in BandwidthStatus.java](https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/blob/e88648b75c94a116467ae66c9059a1d03a5d3fc9/src/main/java/org/torproject/metrics/onionoo/docs/BandwidthStatus.java#L238-241) is where existing values are replaced in Onionoo.)
So I'm wondering if one of two things are possible:
1. Consider all the nicknames for a given fingerprint as being the *same* relay. Relay Search would show the sum of all their contributions.
2. Consider different fingerprints for a given fingerprint to be *different* relays. Relay search would have a separate page for every instance.Metrics OKR Q1 - Q2 2022HiroHirohttps://gitlab.torproject.org/tpo/tpa/status-site/-/issues/16Mark "V2 Onion Services deprecation" resolved as of 08-11-20212022-02-04T17:50:36ZdonutsMark "V2 Onion Services deprecation" resolved as of 08-11-2021Let's take down the V2 deprecation notice by marking it as resolved, and backdating its resolution to 08-11-2021 (Tor Browser 11's release date).Let's take down the V2 deprecation notice by marking it as resolved, and backdating its resolution to 08-11-2021 (Tor Browser 11's release date).https://gitlab.torproject.org/tpo/core/tor/-/issues/40546MetricsPort: new metric exposing time until online keys expire for relay oper...2023-05-24T14:45:52ZnusenuMetricsPort: new metric exposing time until online keys expire for relay operators using OfflineMasterKey### Summary
The number of tor relay operators using the OfflineMasterKey feature is increasing.
To reduce the risk of relay outages caused by not renewed online keys, it would be great to help relay operators with monitoring their key e...### Summary
The number of tor relay operators using the OfflineMasterKey feature is increasing.
To reduce the risk of relay outages caused by not renewed online keys, it would be great to help relay operators with monitoring their key expiry by exposing the timestamp when online keys expire and tor automatically shuts down in a prometheus metric.
This will allow relay operators to write alertmanager rules to notify them in time before their keys expire.
### What is the expected behavior?
When connecting to the MetricsPort of a tor relay running in OfflineMasterKey mode,
a metric will indicate the timestamp when online keys expire.
The metric could be named:
`tor_relay_signing_cert_expiry_timestamp`
and would have the same value as:
```
tor -f /path/to/torrc --key-expiration sign --format timestamp --quiet
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40536Feature request: add a vitor, like visudo or vidoas but for the tor configura...2022-06-17T17:43:22ZnyxnorFeature request: add a vitor, like visudo or vidoas but for the tor configuration files### Summary
[vidoas](https://github.com/slicer69/doas/blob/master/vidoas)
[visudo](https://github.com/sudo-project/sudo/blob/main/plugins/sudoers/visudo.c)
These programs allow the user to edit the configuration file for their program s...### Summary
[vidoas](https://github.com/slicer69/doas/blob/master/vidoas)
[visudo](https://github.com/sudo-project/sudo/blob/main/plugins/sudoers/visudo.c)
These programs allow the user to edit the configuration file for their program safely if they have readability and writability to it, normally only root, so you need to call them as root or with `sudo visudo` or `doas vidoas`.
They create a temporary file to be edited, they use environment variables to check for the editor of choice: visudo uses SUDO_EDITOR, VISUAL, EDITOR and vidoas uses VISUAL and EDITOR. Them, after exiting the editor, the temporary file is checked, if ok, delete the temporary file and exit and if not, prompt to edit again or abort the modifications, visudo adds the option to save the wrong configuration with but warn it is dangerous.
Can you guys greate a vitor? Vi for tor configuration files?
### What is the expected behavior?
To fail if the configuration is wrong and prompt to be edited again
### Extra
I created a vitor in shellscript but would be great if it is implemented in C for tor.
Updated version [here](https://github.com/nyxnor/vitor)
```sh
#!/usr/bin/env sh
## Copy tor config to temp, lock the original file, modify the temp,
## verify it is ok then save back to original place and remove other files
## Inspired by https://github.com/slicer69/doas/blob/master/vidoas
file_mode="644"
me="${0##*/}"
## colors
#nocolor="\033[0m"
#bold="\033[1m"
#nobold="\033[22m"
#underline="\033[4m"
#nounderline="\033[24m"
#red="\033[31m"
#green="\033[32m"
#yellow="\033[33m"
#blue="\033[34m"
#magenta="\033[35m"
#cyan="\033[36m"
## display error message with instructions to use the script correctly.
notice(){ printf %s"${me}: ${1}\n" 1>&2; }
error_msg(){ notice "${1}"; exit 1; }
usage(){ printf '%s\n' "Usage: ${me} [-f tor_conf] [-u tor_user]
Note:
${me} run ${me} as the root user with 'sudo' or 'doas'
-f tor_conf if 'tor_conf' is not set, default to /etc/tor/torrc
if the file doesn't exist, will create it after passing all tests.
-u tor_user if 'tor_user' is not set, the tor_conf must contain the \"User\" option
else it tor fails to validate the configuration"
exit 1
}
get_arg(){ case "${2}" in ""|-*) error_msg "Option '${1}' requires an argument.";; esac; }
[ -n "${1}" ] && [ -z "${2}" ] && tor_conf="${1}"
while :; do
case "${1}" in
-f) get_arg "${1}" "${2}"; tor_conf="${2}"; shift 2;;
-u) get_arg "${1}" "${2}"; tor_user="${2}"; shift 2;;
"") break;;
*) usage;;
esac
done
## get editor. First try environment variables [SUDO|DOAS]_EDITOR, if empty try VISUAL, if empty try EDITOR, if empty use Vi
eval PRIVILEGED_EDITOR='$'"$(printf %s"${su_cmd##*/}" | tr '[:lower:]' '[:upper:]')_EDITOR"
editor="${PRIVILEGED_EDITOR:-"${VISUAL:-"${EDITOR:-vi}"}"}"
## get interrupt signal
get_intr="$(stty -a | sed -n '/.*intr = / {s///;s/;.*$//;p;}')"
## get first argument, if empty, onionjuggler.conf variable, if empty, fallback to default torrc
file="${tor_conf:-"/etc/tor/torrc"}"
## remove last backlash if inserted by mistake
file="${file%*/}"
[ -n "${SUDO_USER}" ] && su_cmd="sudo"
[ -n "${DOAS_USER}" ] && su_cmd="doas"
{ [ -z "${su_cmd}" ] && [ "$(id -u)" -ne 0 ]; } && error_msg "Run ${me} as the root user with 'sudo' or 'doas'."
if [ -f "${file}" ]; then
tor_user_check="$(grep "^User" "${file}" | sed "s/^User //")"
if [ -n "${tor_user_check}" ] && [ -n "${tor_user}" ] && [ "${tor_user_check}" != "${tor_user}" ]; then
notice "The tor configuration file contains the user ${tor_user_check}, but you specified the tor user ${tor_user}."
error_msg "Are you running tor as the correct user?"
fi
if [ -z "${tor_user_check}" ] && [ -z "${tor_user}" ]; then
notice "\"User\" option is not set on the tor configuration file nor in the command line."
notice "Specify the tor user with:"
error_msg "$ ${me} -u tor_user"
fi
fi
## get just the directory
file_dir="${file%/*}"
[ ! -d "${file_dir}" ] && error_msg "${file_dir} is not a directory or doesnt exist."
[ ! -w "${file_dir}" ] && error_msg "${file_dir} is not writable by ${USER}."
[ ! -r "${file_dir}" ] && error_msg "${file_dir} is not readble by ${USER}."
## file is the first argument, replace '.' and '-' for '_'.
file_name="$(printf %s"${file##*/}" | tr "." "_" | tr "-" "_")"
file_name_tmp="$(printf %s"mkstemp(${file_dir}/${file_name}.XXXXXX)" | m4)"
chmod "${file_mode}" "${file_name_tmp}"
file_locked="${file}.lck"
## test if file is already in use.
ln "${file}" "${file_locked}" || error_msg "${file} is busy, try again later."
if [ -f "${file}" ]; then
[ ! -r "${file}" ] && error_msg "${file} is not readable."
[ ! -w "${file}" ] && error_msg "${file} is not writable."
cp -p "${file}" "${file_name_tmp}"
fi
check_tmp_tor_user(){
tor_user_check="$(grep "^User" "${file_name_tmp}" | sed "s/^User //")"
if [ -n "${tor_user_check}" ]; then
su_tor_cmd="${su_cmd}"
else
if [ -z "${tor_user}" ]; then
notice "You probably commented or deleted the \"User\" option, but you can only do that if you specify the tor user."
notice "If that is what you want interrupt with ${get_intr} and run:"
notice "$ ${me} -u tor_user"
else
su_tor_cmd="${su_cmd} -u ${tor_user}"
fi
fi
}
trap '' INT
trap 'rm -f ${file_name_tmp} ${file_locked}' EXIT
## open temporary file to be edited
"${editor}" "${file_name_tmp}" || true
check_tmp_tor_user
## while the config is not ok, loop to enter and continue to edit or signal to interrupt.
while ! ${su_tor_cmd} tor -f "${file_name_tmp}" --verify-config --hush; do
tor_check="$(${su_tor_cmd} tor -f "${file_name_tmp}" --verify-config --hush)"
printf '%s\n' "${tor_check}" | grep -q "Permission denied" && notice "Got permission denied to read tor directories, did you specify the tor user? If yes, maybe the directories do not have the right owner."
printf '%s\n' "${tor_check}" | grep -q "You are running Tor as root. You don't need to, and you probably shouldn't." && notice "Do not run tor as root if you did not set the \"User\" option."
notice "The temporary copy on ${file_name_tmp} is not a valid configuration."
notice "Options are:"
notice " (e)enter to edit again."
notice " e(x)it to cancel without saving changes."
while :; do
printf %s"${me}: Your choice: "
# shellcheck disable=SC2034
read -r status
[ "${status}" = "e" ] && break
[ "${status}" = "x" ] && exit
done
"${editor}" "${file_name_tmp}" || true
check_tmp_tor_user
done
! cmp -s "${file_name_tmp}" "${file}" && cp -p "${file_name_tmp}" "${file}" && notice "${file} updated." && exit 0
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40086Profile snowflake-server and attempt to reduce CPU and heap usage2023-03-10T22:01:48ZDavid Fifielddcf@torproject.orgProfile snowflake-server and attempt to reduce CPU and heap usageThe snowflake-server process on the bridge uses 4 to 8 times the CPU of the tor process. It would be nice to see if there are low-effort ways to reduce the CPU usage.
Cf. #40085, which increased the number of CPUs on the bridge server.The snowflake-server process on the bridge uses 4 to 8 times the CPU of the tor process. It would be nice to see if there are low-effort ways to reduce the CPU usage.
Cf. #40085, which increased the number of CPUs on the bridge server.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/79Use rotating time periods for when each bridge is available for distribution2022-03-24T10:30:02Zmeskiomeskio@torproject.orgUse rotating time periods for when each bridge is available for distributionFrom https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/12#note_2738534:
> I think the original idea was different in that *no matter how many email addresses or subnets you have*, you still can't learn the bridges we gave...From https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/12#note_2738534:
> I think the original idea was different in that *no matter how many email addresses or subnets you have*, you still can't learn the bridges we gave out yesterday. That is, the idea was to release a small subset of the total bridge population, and then divide that subset according to the resource-you're-proving constraint.
>
> It could be that this design only works well with a large enough bridge population. For example, let's say we take only 5% of our bridges to give out at a time, and we give them out for a 6 hour interval before moving to the next subset. Then it's 5 days before we get around to offering them again. Those numbers prove the concept ("when you show up and decide to start blocking, people still get several days of use out of the bridges they already have") but they aren't as exciting as an example with an even larger period. If we rotate each 24 hours, then we get a much bigger period of 20 days. And if there's some level of churn in that period, then we're also giving out our fresh bridges in a way that's spread-out into the future, forcing the attacker to sustain the attack (this aspect would work better if the rotation period was more like every hour, so you really do have to hit us every hour or you miss a whole batch).
>
> This general principle is part of what makes Salmon appealing too: "give out bridges to a group of people and then stop giving them out \[for a long while\] after that".
>
> If we want to mess around with variations on our bridge distribution strategies in order to get more intuition, that sounds great. If we want to wait and "do it right" with Salmon, so long as we know that the first few iterations won't actually be right and we'll be doing that to gain more intuition ;), that sounds great too.
We might want to use that for the telegram bot #77.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/web/newsletter/-/issues/25Deploy newsletter images to appropriate web mirror2022-01-31T22:45:20ZJérôme Charaouilavamind@torproject.orgDeploy newsletter images to appropriate web mirrorLooking at the latest newsletter email blast, we noticed that the image assets referred in the HTML message body are being served from `gitlab.torporject.org`. This is really not optimal since the [current load](https://gitlab.torproject...Looking at the latest newsletter email blast, we noticed that the image assets referred in the HTML message body are being served from `gitlab.torporject.org`. This is really not optimal since the [current load](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40479) is heavily taxing our existing GitLab infrastructure. We also noticed that during the blog migration, many assets for previous newsletter emails and the archived website copies were actually sourced from `blog.torproject.org`...
Would it be possible to consistently host images related to newsletters, both email and web editions, on the `newsletter.torproject.org` website? The nature of our static website hosting infrastructure makes it much more efficient to serve such content to the wide Internet.
/cc @gus @smithJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/docker-obfs4-bridge/-/issues/4Docker could not create bridge line2024-03-20T19:18:08ZGusDocker could not create bridge lineA relay operator reported on Tor Forum that running `docker exec CONTAINER_ID get-bridge-line` is returning this error:
```
user@dockerhost:~$ docker exec torbridge_obfs4-bridge_1 get-bridge-line
Could not create bridge line. Tor's log...A relay operator reported on Tor Forum that running `docker exec CONTAINER_ID get-bridge-line` is returning this error:
```
user@dockerhost:~$ docker exec torbridge_obfs4-bridge_1 get-bridge-line
Could not create bridge line. Tor's log format may have changed. This is a bug.
```
https://forum.torproject.net/t/help-censored-users-run-a-tor-bridge/704/17meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy/-/issues/3publish images for arm2022-05-16T14:33:30Zmeskiomeskio@torproject.orgpublish images for armSo raspberrypi users can run a proxy. We could copy the crossbuild setup from [docker-obfs4-bridge](https://gitlab.torproject.org/tpo/anti-censorship/docker-obfs4-bridge) or just build it natively and push it to docker hub.
Related to #2.So raspberrypi users can run a proxy. We could copy the crossbuild setup from [docker-obfs4-bridge](https://gitlab.torproject.org/tpo/anti-censorship/docker-obfs4-bridge) or just build it natively and push it to docker hub.
Related to #2.https://gitlab.torproject.org/tpo/web/team/-/issues/16Lektor projects may not want all packages in lego2022-08-02T21:48:22ZJérôme Charaouilavamind@torproject.orgLektor projects may not want all packages in legoThe way most of the Lektor website projects are built, with `packages` symlinked to `lego/packages` is not ideal. For example, the `i18n` plugin is present on projects which do not need it, and when the plugin [started to misbehave](tpo/...The way most of the Lektor website projects are built, with `packages` symlinked to `lego/packages` is not ideal. For example, the `i18n` plugin is present on projects which do not need it, and when the plugin [started to misbehave](tpo/tpa/team#40501), it affected all projects and not only the ones that need `i18n`.
If projects instead symlinked packages selectively from those in `lego/packages` we would avoid this, and gain the ability for projects to use their own plugins without affecting the other sites (eg. `index-pages` for the blog project).
Furthermore it would probably be wise to revisit just why exactly some packages are in there, such as `environs`.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40693Potential Wayland dependency2022-07-09T18:11:52ZMatthew FinkelPotential Wayland dependencyWe received a report that Tor Browser 11.0 now fails to start on a (Gentoo) Linux machine that does not have Wayland installed. Firefox 91.3.0esr does start.
`libxul.so: undefined symbol: gdk_wayland_display_get_wl_compositor`We received a report that Tor Browser 11.0 now fails to start on a (Gentoo) Linux machine that does not have Wayland installed. Firefox 91.3.0esr does start.
`libxul.so: undefined symbol: gdk_wayland_display_get_wl_compositor`Tor Browser 11.5boklmboklmhttps://gitlab.torproject.org/tpo/web/support/-/issues/263[HTTPS] Duplicate phrase2022-01-20T01:36:49Zchampionquizzerchampionquizzer@torproject.org[HTTPS] Duplicate phraseAs a user on [twitter](https://twitter.com/dejacrypto/status/1444273178549891076) pointed out, on https://support.torproject.org/https/https-1/, the phrase *"The/This visualization shows what information is visible to eavesdroppers with ...As a user on [twitter](https://twitter.com/dejacrypto/status/1444273178549891076) pointed out, on https://support.torproject.org/https/https-1/, the phrase *"The/This visualization shows what information is visible to eavesdroppers with and without Tor Browser and HTTPS encryption."* appears twice in subsequent lines.championquizzerchampionquizzer@torproject.orgchampionquizzerchampionquizzer@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40425improve the spam filter on the RT frontdesk2023-07-04T16:02:16Zchampionquizzerchampionquizzer@torproject.orgimprove the spam filter on the RT frontdeskOn frontdesk, we are consistently receiving nearly 1200-1300 spam tickets per month. Recently (since 17th September, 2021), we have started blocking certain recurring spammers on a user level, yet the statistics don't seem so promising. ...On frontdesk, we are consistently receiving nearly 1200-1300 spam tickets per month. Recently (since 17th September, 2021), we have started blocking certain recurring spammers on a user level, yet the statistics don't seem so promising. Since 18th September 00:00 UTC we have received 270 tickets in spam (and there's much more in the frontdesk queue which we haven't yet manually queued as spam). Would it be possible to do something on your end? :)
Thanks!improve mail servicesJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/community/support/-/issues/40036Recruit community moderators2021-10-28T18:39:33ZGabagaba@torproject.orgRecruit community moderatorsWe need to get a small group of volunteers to moderate the forum. This ticket will track the call for moderators.We need to get a small group of volunteers to moderate the forum. This ticket will track the call for moderators.Launch support's Forum and Blog migrationGusGus2021-09-30https://gitlab.torproject.org/tpo/core/tor/-/issues/40448dirauth: New flag that only allow relays to be in the middle position2023-02-07T10:24:56ZDavid Gouletdgoulet@torproject.orgdirauth: New flag that only allow relays to be in the middle positionThere was a time before proposal [272](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/272-valid-and-running-by-default.txt) where removing the `Valid` flag would make the relay to be only used in the middle position...There was a time before proposal [272](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/272-valid-and-running-by-default.txt) where removing the `Valid` flag would make the relay to be only used in the middle position as in not Guard nor Exit by clients.
This ticket is to propose that we add a new relay flag that authorities can vote on in order to restrict the "power positions" (Guard and Exit and HSDir) to be only middle and rendezvous.
The main reason this would be desirable is because the Health Team often deals with large set of relays showing up that are either missing proper configuration (ex: `MyFamily`) or have the proper configuration but for which our assessment is that we are unsure and need to validate some key things that can be dragged over weeks like contacting the operator(s) for instance.
And so, if we could have a way to put these relays in a less powerful position that is middle and rendezvous only, it would allow us to put them in a "provisional" state (or the Matrix train station ;) until we can properly assess risk. We believe it is a better trade off than instead rejecting them outright and risking to loose good contributors to this drastic practice.
Of course, we are aware that even a middle node can still pull off attacks but we still think this could be a useful option for the health team nevertheless.
This would require couple things:
- A spec proposal.
- A config option (torrc) to indicate which relays have that flag like: `AuthDirTrainStation` (not a final name...)
-----
Current plan:
* [x] Write a proposal for doing the calculation as part of directory voting.
* [x] Voting-side implementation
* [x] Consensus-side implementationTor: 0.4.7.x-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40536Proxy Refused if link from other app opens Android TBB2023-02-02T23:31:30ZcypherpunksProxy Refused if link from other app opens Android TBBTBB Android 10.0.18
LineageOS
Bug:
"Proxy Server Refused Connection" error in tab
Reproduction:
Close Tor Browser. From a different app, open a link such as in an app's "About" screen.** A dialog window might pop up asking which browse...TBB Android 10.0.18
LineageOS
Bug:
"Proxy Server Refused Connection" error in tab
Reproduction:
Close Tor Browser. From a different app, open a link such as in an app's "About" screen.** A dialog window might pop up asking which browser to use to open the link. Choose Tor Browser from the list**. Tor Browser's window opens and tries to open the URL. Full-tab error appears: "Proxy Server Refused Connection"
Workaround:
Open Tor Browser *before* opening links from other apps.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40054uTLS for broker negotiation2022-10-18T16:23:33Zmax-buTLS for broker negotiationThe connection from the snowflake client to the broker server currently uses go's `net/http.DefaultTransport`. That connection is optionally domain fronted, but the TLS handshake is easily fingerprintable as a go handshake, which might t...The connection from the snowflake client to the broker server currently uses go's `net/http.DefaultTransport`. That connection is optionally domain fronted, but the TLS handshake is easily fingerprintable as a go handshake, which might trigger additional scrutiny in regimes where that kind of TLS inspection is possible and actionable.
[This paper](https://sfrolov.io/papers/ndss19-frolov.pdf), though a bit out of date now (2019) references meek and even snowflake:
> Snowflake is under active development, and its authors were aware of potential TLS fingerprintability issues. Indeed,we find that Snowflake (built from git master branch on April17, 2018) generates a fingerprint that is close to, but not exactly the same as the default Golang TLS fingerprint. In particular,it diverges by including the NPN and ALPN extensions, and offers a different set of signature algorithms. As a result, this fingerprint is seen in fewer than 0.0008% of connections, making it susceptible to blocking.
The author of that paper, Sergey Frolov, maintains https://tlsfingerprint.io/ which is a list of the most popularly seen TLS fingerprints, and created https://github.com/refraction-networking/utls which is a library designed for creating TLS connections with various commonly witnessed TLS fingerprints.
There's a fork of that library, https://gitlab.com/yawning/utls which seems to be used in obfs4's `meeklite` implementation, and it looks like @dcf implemented a version of that in https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-client/utls.go which actually implements a `RoundTripper`. It seems as though actually using that library could be a relatively painless way to adopt utls for the broker negotiation.
@cohosh @meskio and I discussed a little bit whether there would be a good way to identify whether snowflake is actually being identified and/or blocked due to TLS fingerprinting in the broker connection. I suggested that it seemed possible that higher connection error rates in China vs other countries as well as other protocols (such as meek) performing better than snowflake in China _could_ be indicative of TLS fingerprinting blocking, though that's not particularly solid.
I'm sure @dcf would have much more context and information on this area and the relative usefulness of utls on the broker negotiation, but I thought I should throw this out there/open this issue in case it can be of some help.
Related:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40014 (DTLS)shelikhooshelikhoo