While this was a good idea back when I did it:
* People don't like the fact that it requires a fork of utls to fix
compatibility issues, and would rather spend 3 years complaining
about it instead of spending a weekend to fix the issues in
upstream.
* Tor over meek is trivially identifiable regardless of utls or not.
* Malware asshats ruined domain fronting for everybody.
Replace agl's Elligator2 implementation with a different one, that fixes
the various distinguishers stemming from bugs in the original
implementation and "The Elligator paper is extremely hard to read".
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.
Special thanks to Loup Vaillant for his body of work on this primitive,
and for motivating me to fix it.
Microsoft recently updated the root CA certificates that are served to
Azure clients. See the following article for more details:
https://docs.microsoft.com/en-us/azure/security/fundamentals/tls-certificate-changes
This change broke meek-lite because none of its pins work anymore. That
means that Tor Browser users can no longer use meek-azure or moat as
both rely on meek-lite.
This patch fixes the problem by updating the certificate pins.
Signed-off-by: Yawning Angel <yawning@schwanenlied.me>
The old behavior closed the connection on handshake failure after:
* The first N bytes (random on a per-server basis).
* The first M seconds (random on a per-server basis).
Whichever came first. As Sergey Frolov kindly points out, depending on
which conditions cause termination, the server will send either a FIN or
a RST. This change will remove the "amount read" based termination
threshold, so that connections that cause failed handshakes will discard
all data received until the teardown time is reached.
Thanks to Sergey Frolov for bringing this issue to my attention.
HPKP is effectively dead as far as a standard goes, but the idea has
merit in certain use cases, this being one of them.
As a TLS MITM essentially will strip whatever obfuscation that the
transport may provide, the digests of the SubjectPublicKeyInfo fields
of the Tor Browser Azure meek host are now hardcoded.
The behavior can be disabled by passing `disableHPKP=true` on the bridge
line, for cases where comaptibility is prefered over security.
There's still some interesting oddities depending on remote server and
what fingerprint is chosen, but I can watch videos online with the
chosen settings and the TBB Azure bridge.
Note: Despite what people are claiming in the Tor Browser bug tracker
it isn't all that hard to use the built in http client with utls. And
yes, the `transport.go` code does negotiate correctly in a standalone
test case (apart from compatibility related oddities).
This commit changes the upstream repo location to:
https://gitlab.com/yawning/obfs4.git
Additionally all the non-`main` sub-packages now have an import
comment annotation. As a matter of courtesy, I will continue to
push to both the existing github.com and git.torproject.org repos
for the foreseeable future, though I reserve the right to stop
doing so at any time.
The biggest win is that we now declare what versions of each dependency
we require to build. This way, building a certain version of obfs4 will
always use the same source code, independent of the master branch of
each dependency.
This is necessary for reproducible builds. On top of that, go.sum
contains checksums of all the transitive dependencies and their modules,
so the build system will also recognise when the source code has been
changed.
Updated the build instructions accordingly. We don't drop support for
earlier Go versions, but those won't get the benefit of reproducible
builds unless we start vendoring the dependencies too.
It's supposed to use the one derived from the client's handshake
(assuming the clock skew is within acceptable limits), but it was using
the one based off the current system time.
It used to be that all of the bridge side parameters needed to be
manually specified together. This was somewhat nonsensical, and the IAT
mode can now be set as the only obfs4 option in a `ServerTransportOptions`
torrc directive.
Thanks to dcf for reporting the issue.
This is a meek client only implementation, with the following
differences with dcf's `meek-client`:
- It is named `meek_lite` to differentiate it from the real thing.
- It does not support using an external helper to normalize TLS
signatures, so adversaries can look for someone using the Go
TLS library to do HTTP.
- It does the right thing with TOR_PT_PROXY, even when a helper is
not present.
Most of the credit goes to dcf, who's code I librerally cribbed and
stole. It is intended primarily as a "better than nothina" option
for enviornments that do not or can not presently use an external
Firefox helper.
Differences from my goptlib branch:
* Instead of exposing a net.Listener, just expose a Handshake() routine
that takes an existing net.Conn. (#14135 is irrelevant to this socks
server.
* There's an extra routine for sending back sensible errors on Dial
failure instead of "General failure".
* The code is slightly cleaner (IMO).
Gotchas:
* If the goptlib pt.Args datatype or external interface changes,
args.go will need to be updated.
Tested with obfs3 and obfs4, including IPv6.
The ideal solution here would be to implement #15435, but till then
use one of several kludges:
* Linux - prctl() so that the kernel SIGTERMs on parent exit.
* Other U*ix - Poll the parent process id once a second, and SIGTERM
ourself/exit if it changes. Former is better since all the normal
cleanup if any gets done.
* Windows - Log a warning.
The Go developers decided to move the go.net repository to
golang.org/x/net, and also to transition from hg to git. This wasn't
changed when the go.crypto imports were since the 'proxy' component
doesn't have imports that break, so the old code still works.
While the change here is simple (just update the import location), this
affects packagers as it now expects the updated package. Sorry for the
inconveneince, I blame the Go people, and myself for not just doing
this along with the go.crypto changes.