The upstream obfs4 repository has a fix to the Elligator2 public key
representative leak (https://github.com/agl/ed25519/issues/27).
https://gitlab.com/yawning/obfs4/-/commit/393aca86cc3b1a5263018c10f87ece09a…
All releases prior to this commit are trivially distinguishable
with simple math, so upgrading is strongly recommended. The
upgrade is fully backward-compatible with existing
implementations, however the non-upgraded side will emit traffic
that is trivially distinguishable from random.
The file internal/README.md elaborates:
All existing versions prior to the migration to the new code
(anything that uses agl's code) are fatally broken, and trivial
to distinguish via some simple math. For more details see Loup
Vaillant's writings on the subject. Any bugs in the
implementation are mine, and not his.
Representatives created by this implementation will correctly be
decoded by existing implementations. Public keys created by this
implementation be it via the modified scalar basepoint multiply
or via decoding a representative will be somewhat non-standard,
but will interoperate with a standard X25519 scalar-multiply.
As the obfs4 handshake does not include the decoded
representative in any of it's authenticated handshake digest
calculations, this change is fully-backward compatible (though
the non-upgraded side of the connection will still be trivially
distinguishable from random).
We'll meet tomorrow, 2022-01-11 at 16:00 to cooperatively set up a
staging Snowflake bridge. Let's meet in #tor-dev and we can move from
there if needed. I am anticipating spending 2 hours or less on this.
https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl…
Here is a pad with an agenda and a place to draft an installation guide.
https://pad.riseup.net/p/pvKoxaIcejfiIbvVAV7j
If you have SSH and sudo access on the existing Snowflake bridge, you
should already have the same on the staging server. I am thinking that
we can share a screen session and work through the installation steps,
keeping notes in the pad.
There has been a near-total Internet shutdown in Kazakhstan since
2022-01-05, with only a few hours of partial connectivity per day. From
correspondence with some of the people affected, it appears that, for
whatever reason, proxies on TCP port 3785 are accessible during the
shutdown, at least on Kaz Telecom, the largest ISP. I set up an obfs4
bridge on port 3785 and a user reported that it was reachable.
It might be a good idea to push to have a few bridges that run on port
3785, at least for the front desk to hand out?
httpe://ntc.party/t/network-shutdown-all-around-kazakhstan/1601
https://github.com/net4people/bbs/issues/99https://ntc.party/t/network-shutdown-all-around-kazakhstan/1601/14
> SOCKS5 proxy 3785 port works fine. Not sure why, VoIP using skype and
> other services works as well, so I guess 3785 may be used for VoIP
>
> in general, it’s easy to configure in telegram, but if clients are
> able to configure proxy on their OS(for example using proxifyer) https
> and all other traffic works as well.
>
> This has been tested in at least 3 regions.
https://ntc.party/t/network-shutdown-all-around-kazakhstan/1601/16
> > I am not familiar with that one either. nmap-services calls it
> > bfd-echo “BFD Echo Protocol”. RFC 5881 says it is a UDP protocol:
>
> Yeah, if it’s not VoIP I have no idea why it works. I guess people
> found it out by brute-forcing different ports
https://ntc.party/t/network-shutdown-all-around-kazakhstan/1601/17
> Here is an obfs4 bridge on port 3785 (IPv4 and IPv6) to try in Tor
> Browser:
https://ntc.party/t/network-shutdown-all-around-kazakhstan/1601/19
> The IPv4 obfs4 bridge is working!