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.
Client side logs are less spammy than server side in general, so more
messages should be visible at the default logLevel when running as a
client.
Server side logging will be spammy basically no matter what unless
obfs4proxy gets into the (arguably dangerous) business of figuring out
which errors are people being evil vs which ones are transient network
issues, so most logging is suppressed by default, unless the admin
choses to open the floodgates.
The prolog prints the version as soon as logging is enabled, but before
the pluggable transport configuration is done. The epilog is printed as
the code returns from main, as long as either client or server pt
configuration succeded.
By default logging will be done at the "WARN" level. Fatal
initialization errors will always be logged as long as logging
is enabled regardless of logLevel.
Instead of omitting errors entirely when running with the log scrubber,
filter common network errors through elideError() that can scrub the
common net.Error types and remove sensitive information.
* 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.
This matches what the code actually sends. It's shorter than the
ScrambleSuit PRNG seed, but that's because the SipHash-2-4 based
Hash_DRBG has 24 bytes of internal state (key + initial output).
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.
The Golang runtime will happily splatter the remote IP address and port
in the error's string representation for network related errors. While
useful for debugging, this is unacceptable from a privacy standpoint.
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).
The weight generation code also was cleaned up (and now can support
generating distributions that look like what ScrambleSuit does as
a compile time change).
Per: http://www.keithschwarz.com/darts-dice-coins/
To ease delopyment, "-genServerParams has changed".
* "-genServerParams" is now a bool, and will by default generate a
random node-id.
* "-genServerParams -genServerParamsFP=<Base16 blob>" will convert the
supplied bridge fingerprint to a node-id (the old behavior).
Either way of deriving node-id is belived to be secure.
* https://lists.torproject.org/pipermail/tor-dev/2014-May/006929.html
* https://lists.torproject.org/pipermail/tor-dev/2014-June/006936.html
The extra parameter was added because golang's flags library doesn't
support distinguishing between "set but used the default value" and
"not set, so you go the default value".
Instead of using the nonce for the secret box, just use SipHash-2-4 in
OFB mode instead. The IV is generated as part of the KDF. This
simplifies the code a decent amount and also is better on the off
chance that SipHash-2-4 does not avalanche as well as it is currently
assumed.
While here, also decouple the fact that *this implementation* of obfs4
uses a PRNG with 24 bytes of internal state for protocol polymorphism
instead of 32 bytes (that the spec requires).
THIS CHANGE BREAKS WIRE PROTCOL COMPATIBILITY.
Instead of threading the code, move the keypair generation to right
after Accept() is called. This should mask the timing differential due
to the rejection sampling with the noise from the variablity in how
long it takes for the server to get around to pulling a connection out
of the backlog, and the time taken for the client to send it's portion
of the handshake.
The downside is that anyone connecting to the obfs4 port does force us
to do a bunch of math, but the obfs4 math is relatively cheap compared
to it's precursors.
Fixes#9.
The old way was biasted towards the earlier values. Thanks to asn for
pointing this out and suggesting an alternative.
As an additional tweak, do not reuse the drbg seed when calculating the
IAT distribution, but instead run the seed through SHA256 first, for
extra tinfoil goodness.
