[guardian-dev] `snowflake-stun` contains some servers that are offline or do not support RFC 5780

David Fifield david at bamsoftware.com
Thu Sep 19 14:28:17 EDT 2024


cohosh looked into Orbot's use of STUN server for Snowflake, as part of
trying to understand the problem of Orbot Snowflake proxies frequently
self-testing an "unknown" NAT type
(https://lists.mayfirst.org/pipermail/guardian-dev/2024-September/005716.html).
She found a few issues that, it turns out, are probably not the cause of
that particular problem, but are worth fixing independently. In summary:

1. The `snowflake-stun` setting
   (https://github.com/guardianproject/orbot/blob/939ce1d58db6810f51f833cb33dd51235f1eed69/orbotservice/src/main/assets/fronts#L3)
   has a couple of servers that are offline: at least
   stun:stun.bluesip.net:3478 and stun:stun.stunprotocol.org:3478.
2. The `snowflake-stun` list of servers is used not only by Orbot's
   Snowflake client, but also by its kindness mode proxy, which chooses
   one element at random
   (https://github.com/guardianproject/orbot/blob/939ce1d58db6810f51f833cb33dd51235f1eed69/orbotservice/src/main/java/org/torproject/android/service/OrbotService.java#L399-L400).
   It might be better to decouple the client and proxy STUN server
   lists, and use just one highly reliable STUN server in the proxy.
3. Not all the STUN servers in `snowflake-stun` support RFC 5780 NAT
   behavior detection. This doesn't need immediate action, as it is
   something we are also working on upstream in
   https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40304.

Here's the discussion and notes from today:
https://meetbot.debian.net/tor-meeting/2024/tor-meeting.2024-09-19-16.00.log.html#l-22
https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469/timeslider#19195
> * IPtProxy frequently failing NAT type test ("unrestricted" Orbot proxies) https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40384
>   * Possible cause: `snowflake-stun` setting in Orbot, used in common by the snowflake client and the Kindness Mode proxy, which randomizes over a list of STUN servers, some of which no longer exist, or are unreliable.
>     * https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40384
>     * We might ask Orbot to refactor their Kindness Mode proxy to use (for example) a single reliable STUN server, while continuing to select randomly from a pool for their Snowflake client.
>       * Like how the standalone proxy already works now.
>     * This issue of offline STUN servers used by Snowflake proxies is distinct from that of STUN servers not supporting RFC 5780 in Snowflake clients, which is https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40304

For point (1), according to
https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/40384#note_3080493,
stun:stun.bluesip.net:3478 and stun:stun.stunprotocol.org:3478 are no
longer running. This could prevent either a client or a proxy connection
from working, if one of these STUN servers is selected at random.
stun:stun.stunprotocol.org:3478 has already been removed upstream:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/commit/8c775562c151c527264c2737f568516d33522600.
(Aside, there's also a duplicate stun:stun.sonetel.com:3478, removed
upstream in
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/commit/7db2568448fed6d883b33db11e3a497c69f1748f.)

For (2), the Snowflake client pulls STUN servers at random froma small
pool as a slight mitigation against blocking and variable availability.
But the random selection is not necessary for a *proxy*. For proxies,
reliability is more important. In the command-line Snowflake proxy, we
use a default of stun:stun.l.google.com:19302, not referring to the list
used by clients:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L63
You may want to do the same. A proxy that fails its STUN server
connection may accept client but be unable to serve them.

The meeting discussion on point (2) is slightly incorrect; it was
corrected after the logged part of the meeting. The issue, here, is not
RFC 5780 support (because proxies do not use the STUN server to test
their NAT type, using a facility on the broker instead), but rather
simply the reliability of the STUN server.

> <cohosh> dcf1: to be clear, for that it's not rfc 5780 that's
>          important, it's more whether or not the stun servers are
>          actually working, since we use the probetest server to
>          determine NAT types for these proxies
> <dcf1> cohosh: oh then I misunderstand something
> <cohosh> so did i at first, that was my bad
> <cohosh> but the core problem still holds since from a quick glance i
>          think many of those stun servers don't exist anymore
> <dcf1> are you saying that some of the STUN servers on the list are
>        not working, they're just offline?
> <cohosh> yeah
> <cohosh> or they are unreliable
> <WofWca[m]> Though if a STUN server is offline, the proxy will still
>             make an offer.
> <dcf1> ah, okay, I see the point about 5780 now, 5780 is only for
>        clients, proxies use probetest and don't rely on the STUN
>        server having 5780 support, I get it
> <cohosh> that's true, which is why i thought we'd just end up with
>          more restricted proxies rather than unknowns
> <cohosh> so i'm second guessing this but i think guardian project
>          should make a change regardless
> <WofWca[m]> That's for sure
> <cohosh> because an empty offer makes things worse anyway, even if
>          it's not related to this issue

But point (2) is likely not the reason for the high number of "unknown"
NAT types among Orbot proxies, which was the original reason for looking
into all this:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40384#note_3080493
> based on tests on the CLI version of Snowflake proxy bcac2250,
> firstly, a non-functional server simply results in a "restricted" NAT
> type because in this case we only send host candidates to probetest
> (for probetest `keepLocalAddresses: false` has no effect).

On point (3), you can feel free to wait for further guidance as we are
working on that issue ourselves at
https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/40304.


More information about the guardian-dev mailing list