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/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/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.