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.
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.
* Bump the module import to a new tag
* Bump the rest of the dependencies while I'm here
* Add some new fingerprints from upstream
* Disable my fork's AES timing sidechannel defenses
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.
Changes:
* Use a fork of utls with some compatibility improvements.
* Switch the default ClientHello profile to `HelloFirefox_Auto`.
* Add the `HelloChrome_71` profile.
The existing `HelloFirefox_Auto` profile that points to
`HelloFirefox_63` also matches the (common) behavior of Firefox 65,
assuming that 3DES ciphersuites are not disabled.
Per dcf:
> As for the TODO, my plan was was to expose a "utls" SOCKS arg
> to make it configurable per bridge, and just reuse the utls
> Client Hello ID names:
> utls=HelloChrome_Auto
This adds support for all currently supported utls ClientHello IDs
with the following caveats/differences:
* `none` - Disables using utls entirely, forces `crypto/tls`.
* `HelloGolang` - Alias of `none`, since using utls is pointless.
* `HelloCustom` - Omitted as pointless.
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.
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.
ClientFactories now have a Dial() method instead of a WrapConn()
method, so that it is possible to write something like meek-client
using the obfs4proxy framework.
This breaks the external interface if anyone is using obfs4proxy as
a library, but the new way of doing things is a trivial modification,
to a single routine that shouldn't have been very large to begin with.
This allows obfs4proxy to be used as a ScrambleSuit client that is wire
compatible with the obfs4proxy implementation, including session ticket
support, and length obfuscation.
The current implementation has the following limitations:
* IAT obfuscation is not supported (and is disabled in all other
ScrambleSuit implementations by default).
* The length distribution and probabilites are different from those
generated by obfsproxy and obfsclient due to a different DRBG.
* Server support is missing and is unlikely to be implemented.
The Go developers decided to move the go.crypto repository to
golang.org/x/crypto, and also to transition from hg to git. The tip of
tree code.google.com copy of the code is broken due to the import paths
pointing at the new repository.
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.
Exhaustively testing padding combinations is really slow, and was
causing timeouts during the Debian ARM package build process. Attempt
to improve the situation by:
* Reusing the client and server keypair for all of the tests, to cut
runtime down by ~50%.
* Splitting the client side and server side tests up, as it appears
the timeout is per-test case.
If this doesn't fix things, the next thing to try would be to reduce
the actual number of padding lengths tested, but that is a last resort
at the moment.
Instead of "node-id" and "public-key" that are Base16 encoded, use
"cert" which contains the "node-id" and "public-key" in Base64 encoded
form. This is more compact and cuts the length down by 49 characters.
Write an example client bridge line suitable for use with the running
obfs4 server instance to "obfs4_bridgeline.txt" for the convenience of
bridge operators.
* Unbreak inbound TYPE_PRNG_SEED processing.
* IAT obfuscation is now a per-bridge argument (iat-mode).
* 0 (default) = Disabled.
* 1 = Enabled, ScrambleSuit-style with bulk throughput optimizations.
* 2 = Paranoid, Each IAT write will send a length sampled from the
length distribution. (EXPENSIVE).
The "iat-mode" argument is mandatory on the Bridge lines, and as a
ServerTransportOption. Old statefiles will continue to load and use
the default value, edit it if your hat is made of tin foil.
WARNING: THIS BREAKS BACKWARD COMPATIBILITY.
This is primarily to work around bug #12930. Base16 was chosen over
unpadded Base64 because the go runtime Base64 decoder does not handle
omitting the padding.
May $deity have mercy on anyone who needs to hand-enter an obfs4 bridge
line because I will not.
Golang's command line parser is slightly cumbersome to use with
subcommands, so the arguments are "obfs4-iatObufscation" and
"obfs-distBias" instead of obfsproxy style subcommands.
* Changed obfs4proxy to be more like obfsproxy in terms of design,
including being an easy framework for developing new TCP/IP style
pluggable transports.
* Added support for also acting as an obfs2/obfs3 client or bridge
as a transition measure (and because the code itself is trivial).
* Massively cleaned up the obfs4 and related code to be easier to
read, and more idiomatic Go-like in style.
* To ease deployment, obfs4proxy will now autogenerate the node-id,
curve25519 keypair, and drbg seed if none are specified, and save
them to a JSON file in the pt_state directory (Fixes Tor bug #12605).
Yawning Angel
Philipp Winter
Ox Cart
Yawning Angel
pminmax945
Daniel Martí