Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2022-04-05T15:26:33Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31804Authentication for proxy--bridge connections2022-04-05T15:26:33ZCecylia BocovichAuthentication for proxy--bridge connectionsAn DDoS attack surface was brought up in discussion on IRC yesterday (and has been talked about to some extent before).
To summarize the issue:
The Snowflake bridge accepts websocket connections from any other endpoint (this is in part ...An DDoS attack surface was brought up in discussion on IRC yesterday (and has been talked about to some extent before).
To summarize the issue:
The Snowflake bridge accepts websocket connections from any other endpoint (this is in part necessary because anyone can be a proxy and we want as many proxies as possible and the more ephemeral they are, the harder it is for a censor to block all of them)
This means that an malicious party with the ability to distribute malicious javascript can have unsuspecting clients execute javascript that makes a websocket connection to the bridge and use the Tor network to upgrade their websocket connection to a plain TCP connection.
This basically allows someone to use Tor in order to perform DDoS attacks on TCP services, using malicious javascript as the attack vector. While the effectiveness of this attack probably wouldn't be that good (all the attack traffic would be congested through the single Snowflake bridge), it could provide a way for a censor to more easily DDoS Snowflake itself.
We could provide some kind of authentication step involving the bridge, broker, and snowflake proxy.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31661Run multiple snowflake bridges and optimize for least latency most throughput...2022-07-25T17:59:44ZcypherpunksRun multiple snowflake bridges and optimize for least latency most throughput by GeoIP based route selectionAfter the publication of this [article](https://gigazine.net/news/20190812-tor-snowflake/) hundreds of Japanese people started installing the Snowflake WebExt (yay!), but despite having an Internet service that's orders of magnitudes bet...After the publication of this [article](https://gigazine.net/news/20190812-tor-snowflake/) hundreds of Japanese people started installing the Snowflake WebExt (yay!), but despite having an Internet service that's orders of magnitudes better than the average American household, the distance between then and the `nl` snowflake bridge seriously impacts the throughput, so much that some snowflake proxies from Japan - despite having more than 20MB/s upload/download - can't offer a download speed bigger than 150KiB/s. What if there were for instance 5 snowflake bridges in different geographical locations in the world and the broker associated with each snowflake proxy the nearest snowflake bridge and sent this information to the user (based on GeoIP, of course, not perfect but better than the status quo)?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31085Make an Android extension or app for people to be a snowflake (AMO or proxy-go)2023-07-13T14:59:01ZcypherpunksMake an Android extension or app for people to be a snowflake (AMO or proxy-go)https://addons.mozilla.org/en-US/android/https://addons.mozilla.org/en-US/android/Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30498Proxy-go is receiving a lot of client timeouts2023-08-01T23:44:35ZCecylia BocovichProxy-go is receiving a lot of client timeoutsSome proxy-go instances are experiencing what seems like an unusually high number of client timeout errors.Some proxy-go instances are experiencing what seems like an unusually high number of client timeout errors.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29863Add disk space monitoring for snowflake infrastructure2023-07-31T02:23:24ZCecylia BocovichAdd disk space monitoring for snowflake infrastructureWe've run out of disk space at both the snowflake bridge (legacy/trac#26661, legacy/trac#28390) and the broker (legacy/trac#29861), which has caused snowflake to stop working. We've set up rotating and compressed logs but it would be nic...We've run out of disk space at both the snowflake bridge (legacy/trac#26661, legacy/trac#28390) and the broker (legacy/trac#29861), which has caused snowflake to stop working. We've set up rotating and compressed logs but it would be nice to have some disk space monitoring to alert us if/when this happens again
Also, as discussed on IRC, we should eventually move the broker to a TPA machine.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29260Should Snowflake proxies have a way to identify themselves to the broker2022-07-25T17:59:44ZAlexander Færøyahf@torproject.orgShould Snowflake proxies have a way to identify themselves to the brokerWould it make sense for us to have an identity key (or something similar) for Snowflake proxies to allow them to identify themselves to the broker service.
This would allow us to later build reputation systems for the proxies and distri...Would it make sense for us to have an identity key (or something similar) for Snowflake proxies to allow them to identify themselves to the broker service.
This would allow us to later build reputation systems for the proxies and distribute snowflake proxies in a smart way based of stability/uptime. The downside from a privacy perspective is that the broker can follow the Snowflake proxies' movements on the internet, which means we might want to make it optional.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/26092Split broker into components2024-02-14T14:59:36ZDavid Fifielddcf@torproject.orgSplit broker into componentsThis is my idea for breaking the broker into a few parts, instead of being a monolithic executable. The rationale is:
* With additional rendezvous methods (legacy/trac#25594, legacy/trac#25874), it will be nice to have a separate proces...This is my idea for breaking the broker into a few parts, instead of being a monolithic executable. The rationale is:
* With additional rendezvous methods (legacy/trac#25594, legacy/trac#25874), it will be nice to have a separate process per method, which can be restarted independently of the others and only has to manage its own listener.
* With encrypted registrations (legacy/trac#22945), it will be nice if the process holding the private key is not the same process that exposes a lot of attack surface in the form of HTTP servers, DNS servers, etc.
I propose having the broker in three components:
1. The core broker database process, which matches client registrations with proxies. Only listens on localhost. Only handles plaintext.
2. A decryption and signing oracle process. This is the only component that has access to the private key. Listens only on localhost. Receives encrypted registrations from the rendezvous processes, decrypts them, and passes them on to the core broker process.
3. Registration method processes. These are the only components that listen externally. They take encrypted client registrations over HTTPS, DNS, or whatever, and pass them to the decryption oracle which passes them to the broker. Gets back signed proxy answers and passes them back to the client. There doesn't have to be strictly one process per registration method; for example the HTTPS POST and [ticket:25985 AMP Cache] are similar enough that they can be handled together.
It might be better (simpler) to have components 1 and 2 in the same process--the broker logic is pretty simple so there's not much added risk in having it with private key.
We used a similar architecture in flash proxy; see [facilitator-design.txt](https://gitweb.torproject.org/flashproxy.git/tree/facilitator/doc/facilitator-design.txt?id=0c5ea1b04c4725fccc5a98a25bede5c419e07fcd):
1. facilitator (later renamed fp-facilitator)
2. facilitator-reg-daemon (later renamed fp-reg-decryptd)
3. facilitator.cgi for HTTP and facilitator-email-poller for SMTP (later renamed fp-registrar.cgi and fp-registrar-email)Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25874DNS-based rendezvous for Snowflake2023-05-18T15:09:57ZDavid Fifielddcf@torproject.orgDNS-based rendezvous for SnowflakeFrom tpo/anti-censorship/pluggable-transports/snowflake#25594:
An idea to use DNS over HTTPS:
https://groups.google.com/forum/#!topic/traffic-obf/ZQohlnIEWM4
> The circumvention idea is to take any existing DNS tunneling scheme and send ...From tpo/anti-censorship/pluggable-transports/snowflake#25594:
An idea to use DNS over HTTPS:
https://groups.google.com/forum/#!topic/traffic-obf/ZQohlnIEWM4
> The circumvention idea is to take any existing DNS tunneling scheme and send it through DNS over HTTPS. To be a bit more specific: you send recursive DNS queries (encoding your upstream traffic) to the DNS-over-HTTPS server, which then forwards the queries to another specialized server that decodes them and proxies the data they contain.
>
> Even if not a general-purpose transport, DNS-over-HTTPS could be an ideal rendezvous mechanism for a system like Snowflake or Moat. One where you only need to send/receive a small amount of very hard-to-block data in order to bootstrap a connection.
The way I see it, there are two parts of this:
1. Using DNS as an underlying transport: the client sends a DNS request containing its encoded offer; the broker sends back a DNS response containing an encoded proxy answer.
2. Sending via DNS-over-HTTPS in order to avoid blocking of the DNS messages themselves.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25681Defend against flooding of the broker by low bandwidth snowflakes2024-02-14T14:59:36ZcypherpunksDefend against flooding of the broker by low bandwidth snowflakesAn adversary may attempt to flood the broker by thousands of low bandwidth snowflakes, as a result users will have a higher chance of happening on them thereby deteriorating their experience.
Maybe there should be some way to ensure tha...An adversary may attempt to flood the broker by thousands of low bandwidth snowflakes, as a result users will have a higher chance of happening on them thereby deteriorating their experience.
Maybe there should be some way to ensure that their bandwidth is higher than some level before they can be distributed by the broker.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25598Let the broker inform proxies how often to poll2022-07-25T17:59:44ZDavid Fifielddcf@torproject.orgLet the broker inform proxies how often to pollCurrently, proxies poll the broker at a static rate of once every 5–10 seconds. If we're anticipating thousands of proxies, we don't need them to poll so frequently.
The broker could instead tell each proxy how long to wait before polli...Currently, proxies poll the broker at a static rate of once every 5–10 seconds. If we're anticipating thousands of proxies, we don't need them to poll so frequently.
The broker could instead tell each proxy how long to wait before polling again. The broker could even dynamically adjust the rate based on an estimate of supply and demand.
One way to do this would be a custom header in responses to `/proxy` requests:
```
Snowflake-Next-Poll: Thu, 22 Mar 2018 18:05:47 GMT
```
Or using a relative time offset:
```
Snowflake-Next-Poll: 600
```
There was a similar idea for flash proxy.
legacy/trac#8171::
The facilitator included a fixed `check-back-in=600` in its responses.
legacy/trac#8172::
Adjust polling interval dynamically (never implemented).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25595Test suite for Snowflake on various NAT topologies2023-08-01T23:45:54ZArlo BreaultTest suite for Snowflake on various NAT topologiesMigrated from https://github.com/keroserene/snowflake/issues/20Migrated from https://github.com/keroserene/snowflake/issues/20max-bmax-bhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25593Broker needs better resilience against DoS2024-02-14T14:59:35ZArlo BreaultBroker needs better resilience against DoSMigrated from https://github.com/keroserene/snowflake/issues/25Migrated from https://github.com/keroserene/snowflake/issues/25Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/36Webtunnel does not support proxy in Tor Browser2024-03-25T11:15:40ZValdikSSWebtunnel does not support proxy in Tor BrowserTor Browser 13.0.12.
If configured with upstream Socks5 proxy, Webtunnel bridge does not send any requests via proxy (and at all).Tor Browser 13.0.12.
If configured with upstream Socks5 proxy, Webtunnel bridge does not send any requests via proxy (and at all).shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40345migrate docker image to this repo2024-03-23T19:38:24Zmeskiomeskio@torproject.orgmigrate docker image to this repoWe used to develop the docker image in a separated repo: https://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy/
But now we have a CI building the docker image in this repo: !246
Let's deprecate the original docker re...We used to develop the docker image in a separated repo: https://gitlab.torproject.org/tpo/anti-censorship/docker-snowflake-proxy/
But now we have a CI building the docker image in this repo: !246
Let's deprecate the original docker repo and move everything here. Things that might be missing:
* [ ] move docker-compose.yml to this repo or somewhere
* [ ] update the community documentation to use our repo
* [ ] integrate publishing the docker image in the release process
* [ ] are we cross building in the CI?
* [ ] how are we going to push to dockerhub the image?
* [ ] archive docker-snowflake-proxy reposhelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40343Make the client automatic try and report to user what snowflake options combi...2024-03-04T10:16:38Zsnowflake_user_40314Make the client automatic try and report to user what snowflake options combination workI think current we have too many snowflake options combination(e.g. front domains, STUN servers, URLs of brokers at various CDN, and others).\
Thus, I think perhaps we should provide a way let user input the potential options as front do...I think current we have too many snowflake options combination(e.g. front domains, STUN servers, URLs of brokers at various CDN, and others).\
Thus, I think perhaps we should provide a way let user input the potential options as front domains list, STUN servers list, URLs of brokers list, and others; then automatic try report to user what options combination(or bridge line) work.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40012Domain fronting requests don't work on some older Android versions2024-03-12T00:09:26ZPier Angelo VendrameDomain fronting requests don't work on some older Android versionsTor Browser for Android supports old versions of Android (API21, i.e., Android Lollipop).
While 13.5a3 doesn't work there because I used some NIO API that requires API26+, I've opened a MR to fix this (tpo/applications/tor-browser!894)....Tor Browser for Android supports old versions of Android (API21, i.e., Android Lollipop).
While 13.5a3 doesn't work there because I used some NIO API that requires API26+, I've opened a MR to fix this (tpo/applications/tor-browser!894).
While checking if things worked, I noticed that domain fronting requests don't (I don't get the special countries list).
As written in that MR, I tried to enable logging (I added `"-enableLogging", "-logLevel", "DEBUG", "-unsafeLogging"` as arguments), but I could get only these messages:
```
2024/01/22 10:20:23 [NOTICE]: obfs4proxy-0.0.14 - launched
2024/01/22 10:20:23 [INFO]: libObfs4proxy.so - initializing client transport listeners
2024/01/22 10:20:23 [INFO]: meek_lite - registered listener: 127.0.0.1:55852
2024/01/22 10:20:23 [INFO]: libObfs4proxy.so - accepting connections
2024/01/22 10:20:23 [WARN]: meek_lite(bridges.torproject.org:443) - closed connection: readfrom tcp 127.0.0.1:55852->127.0.0.1:48836: io: read/write on closed pipe
```
I think there might be some problems with some HTTPS certificate (at least letsencrypt had this problem a few years ago, indeed cohosh mentioned snowflake#40087. Fastly isn't using letsencrypt, but maybe they have a similar problem).
I can open bridges.torproject.org both in TBA and in the system browser, but I can't open https://moat.torproject.org.global.prod.fastly.net/ because it has a wrong certificate.
I don't think I'm using the latest version of Lyrebird, because in the last one the log file should be called lyrebird.log (I submitted a patch for that, unless I missed the log filename), but I can try to build one from a nightly build.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40322Local LAN access through snowflake2024-02-27T11:30:44Zdreamboat301Local LAN access through snowflakeHi
I'm a little bit late to the party. I've read a report from the 37C3 about the success helping people from Iran and other countries avoiding traffic blocks.
So I installed a snowflake instance in proxmox and I was overwhelmed with t...Hi
I'm a little bit late to the party. I've read a report from the 37C3 about the success helping people from Iran and other countries avoiding traffic blocks.
So I installed a snowflake instance in proxmox and I was overwhelmed with traffic. Mostly from Iran and roughly 25 GB a day. I love it that I could be of help!
But I believe there is an issue with it.
I put the instance in its own VLAN and configured the firewall to block any VLAN traffic to and from this network.
A few times a day I get an alert in my firewall claiming that this machine wants to connect to other VLANs. First I thought it might answer broadcast messages. But the IPs it requests don't exist. E.g. 192.168.1.5 is nowhere to be seen. But these are only the visable connections. Because of the nature of Unifi I can't block access to 192.168.1.1 because it is the same as 192.168.x.1 of any VLAN. So I shut down the instance to avoid people of maybe hacking my network. There were also connections to 10.x.x.x networks.
How can this be possible, that people can access my local LAN? I thought that I'm just a bridge to the Tor network and forwarding any traffic to it. Including local LAN addresses (or blocking it).
I've done a few tests. If I access in Tor Browser the IP 192.168.1.1 it gets blocked right away. Thats fine. I created a subdomain of a domain I own and added 192.168.1.1 as an A record. Suddendly I'm able to get through. Somewhere it is blocked anyway but it looks like that it is not fully blocked.
I'm just a home user. Please have patience with me when you direct me to do something.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/311 webtunnel bridge instead of two!2024-02-27T19:09:02Zcypherpunks1 webtunnel bridge instead of two!You should give at least two bridges for conflux to work.You should give at least two bridges for conflux to work.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/88Firefox Android support2024-02-27T11:18:30ZcypherpunksFirefox Android supportHi. 14 December, 2023 onwards, Firefox Android has now allowed all extensions to be installed on Android, as long as they are made (and marked as) compatible with it.
Could the Snowflake addon be updated to allow Android installs? Or is...Hi. 14 December, 2023 onwards, Firefox Android has now allowed all extensions to be installed on Android, as long as they are made (and marked as) compatible with it.
Could the Snowflake addon be updated to allow Android installs? Or is there any pending work before that can happen?https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/185Distribute a single bridge in the QR code2024-03-04T15:30:36ZboyskaDistribute a single bridge in the QR codeThe current implementation of BridgeDB gives the user 3 bridges, and a QR code including them all.
It's a well-acknowledged fact that it's very difficult to scan this huge QR code from a smartphone.
It's almost impossible to scan it from...The current implementation of BridgeDB gives the user 3 bridges, and a QR code including them all.
It's a well-acknowledged fact that it's very difficult to scan this huge QR code from a smartphone.
It's almost impossible to scan it from a piece of paper.
It would therefore be great if the QR could include only a single bridge. While this would make the QR code slightly less useful, it would also make it much more _usable_.
I know that #40052+ is already tracking improvements for QR codes. However, they are mostly independent:
- To get one bridge per QR code, bridgedb#40052 is not needed
- Changing the format to a proper URI doesn't imply we will be switching to one-bridge-per-QR-code.
I can see two possible implementations:
1. Provide 3 bridges and 1 QR code. The QR code only includes data for one of the bridges.
2. Provide 3 bridges and 3 QR codes.
In Tails, we will be shipping QR code scanning [in 5.8](https://tails.boum.org/news/test_5.8-beta1/). This is expected to happen around December 20. It would be great if BridgeDB could distribute more usable QR codes by that time!shelikhooshelikhoo2024-03-29