Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2022-11-15T18:04:35Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/22945End-to-end confidentiality for Snowflake client registrations2022-11-15T18:04:35ZDavid Fifielddcf@torproject.orgEnd-to-end confidentiality for Snowflake client registrationsClient requests sent to the /client broker endpoint use TLS to the front domain, and TLS from the front to the broker, but the fronting service itself (e.g. App Engine) can inspect them in plaintext. The fronting service unavoidably gets...Client requests sent to the /client broker endpoint use TLS to the front domain, and TLS from the front to the broker, but the fronting service itself (e.g. App Engine) can inspect them in plaintext. The fronting service unavoidably gets to learn the IP addresses of clients, but we could encrypt the additional metadata that appears in the registration messages.
I was thinking of giving the broker a private key and wrapping client registrations in a [NaCl box](https://godoc.org/golang.org/x/crypto/nacl/box).
This is roughly how it worked in flash proxy. The facilitator had a private RSA key, and client registration methods were encrypted before being posted to the facilitator.
https://gitweb.torproject.org/flashproxy.git/tree/facilitator/facilitator.cgi?id=1.4#n60
The actual key material was isolated into a facilitator-reg-daemon process that was separated from the web server and facilitator CGI:
https://gitweb.torproject.org/flashproxy.git/tree/facilitator/facilitator-reg-daemon?id=1.4David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25591Pass STUN information from Broker to WebRTC Client2023-08-02T00:02:28ZArlo BreaultPass STUN information from Broker to WebRTC Client> The clients may be in filtered regions where common ICE servers may be unavailable.
>
> May need to revise the Configuration interface of go-webrtc while figuring this part out.
\\ Migrated from https://github.com/keroserene/snowflake...> The clients may be in filtered regions where common ICE servers may be unavailable.
>
> May need to revise the Configuration interface of go-webrtc while figuring this part out.
\\ Migrated from https://github.com/keroserene/snowflake/issues/3
We had some discussion [in a recent meeting](http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-12-05-18.00.log.html) about the original intent of this ticket.
I think to address the need of "default STUN servers are blocked for the client", it would be more interesting to pursue ways in which NAT punching information for the client could be sent over the domain-fronted connection to the broker. Some discussion on legacy/trac#30579 laid out reasons why a more private way of getting ICE candidates is desirable.https://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/snowflake/-/issues/25594Broker: investigate non-domain-fronting secure client / proxy registrations2024-02-27T18:55:26ZArlo BreaultBroker: investigate non-domain-fronting secure client / proxy registrations> Pasting discussion from email,
>
>> in the Flashproxy case, registration wasn't
>> bidi, and I think they imagined using insecure
>> channels to register like OSSes. In Snowflake,
>> the client is making TLS connections with the
>> bro...> Pasting discussion from email,
>
>> in the Flashproxy case, registration wasn't
>> bidi, and I think they imagined using insecure
>> channels to register like OSSes. In Snowflake,
>> the client is making TLS connections with the
>> broker, which amounts to the same thing as
>> encrypting the payload with the facilitator's
>> public key.
>
> Also,
>
>> There's also the case where an adversary DOSes the facilitator with a
>> bunch of fake client or proxy registrations and things like that.
>
> This is now legacy/trac#25593
>
>> Also, there is the potential that in the future we might need some
>> sort of non-domain-fronting rendezvous. It seems that right now we
>> have an ecosystem of tools growing that assumes domain-fronting will
>> always be available & effective. May be worth considering how to
>> prepare for regions where this might not work as well in the future.
>
> So this ticket should probably be for that.
\\ Migrated from https://github.com/keroserene/snowflake/issues/13
Ideas that have been proposed or done:
* #25985 AMP cache
* #25874 DNS
* #26151 Amazon SQSDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://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/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/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/25723Multiplex - one client splits traffic across multiple proxies2024-02-27T18:57:33ZDavid Fifielddcf@torproject.orgMultiplex - one client splits traffic across multiple proxiesThis is the dual of legacy/trac#25601.
It would be a great feature if a client could be connected to multiple snowflake proxies at once, and split traffic across all of them. Like the [Conflux](http://cacr.uwaterloo.ca/techreports/2013/...This is the dual of legacy/trac#25601.
It would be a great feature if a client could be connected to multiple snowflake proxies at once, and split traffic across all of them. Like the [Conflux](http://cacr.uwaterloo.ca/techreports/2013/cacr2013-16.pdf) proposal for Tor. It would be a hedge against getting assigned a single slow proxy.
This would require interposing some kind of sequencing and reliability layer, with possible retransmissions.
A potential benefit for privacy is that an individual snowflake proxy only sees a subset of a client's traffic flow.
However, instantly making _N_ WebRTC connections is a tell for traffic classification.https://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/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/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/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/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/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/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/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/31847Expand contribution guidelines for snowflake2022-03-01T15:55:52ZCecylia BocovichExpand contribution guidelines for snowflakeWe're getting more contributors to the project, we should expand CONTRIBUTING.md with some more basic guidelines like
- formatting of commit messages
- creating tickets for each pull request
- make sure the changes in the commit adhere t...We're getting more contributors to the project, we should expand CONTRIBUTING.md with some more basic guidelines like
- formatting of commit messages
- creating tickets for each pull request
- make sure the changes in the commit adhere to the commit message and the corresponding tickethttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/32677Find a way to notify deployed proxy-go instances of updates2024-03-13T06:57:03ZCecylia BocovichFind a way to notify deployed proxy-go instances of updatesWe've had a few people run proxy-go instances in the past and express interest in running them. These instances should be updated periodically or when there is a critical reason to do so. Right now we don't have a good way to notify depl...We've had a few people run proxy-go instances in the past and express interest in running them. These instances should be updated periodically or when there is a critical reason to do so. Right now we don't have a good way to notify deployed instances of updates.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40012Have the broker cache stats results when being restarted2024-03-21T15:06:18ZCecylia BocovichHave the broker cache stats results when being restartedRight now the stats results are stored in memory and if the broker is restarted, they are just dropped and start again from zero. Let's listen for the shutdown signal and save a cache of the stats counts to disk so they can be reloaded w...Right now the stats results are stored in memory and if the broker is restarted, they are just dropped and start again from zero. Let's listen for the shutdown signal and save a cache of the stats counts to disk so they can be reloaded when snowflake starts up again.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40014Make Snowflake's DTLS fingerprint more similar to popular WebRTC implementations2024-01-12T17:12:10ZCecylia BocovichMake Snowflake's DTLS fingerprint more similar to popular WebRTC implementationsSome recent work by researchers at Princeton shows that Snowflake's DTLS fingerprint differs from some other popular WebRTC implementations (Facebook, Google, and Discord): https://arxiv.org/pdf/2008.03254.pdf
I'm hesitant to rush chang...Some recent work by researchers at Princeton shows that Snowflake's DTLS fingerprint differs from some other popular WebRTC implementations (Facebook, Google, and Discord): https://arxiv.org/pdf/2008.03254.pdf
I'm hesitant to rush changes to the fingerprint without a more complete comparison to more WebRTC implementations popular in censored regions. But, we can get a start on figuring out how to change the fingerprint in pion and see whether we will need to submit upstream patches to provide us with this kind of agility. Something like uTLS would be great for us in the long run.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibettheodorsmtheodorsm