| Age | Commit message (Collapse) | Author |
|---|
|
* 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).
|
|
|
|
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.
|
|
Part of issue #9.
|
|
All of the obfs4 code except unit tests now uses the csrand wrapper
routines.
|
|
* handhake_ntor_test now is considerably more comprehensive.
* The padding related constants in the spec were clarified.
This breaks wireprotocol compatibility.
|
|
This is done by maintaining a map keyed off the SipHash-2-4 digest of
the MAC_C component of the handshake. Collisions, while possible are
unlikely in the extreme and are thus treated as replays.
In concept this is fairly similar to the ScrambleSuit `replay.py` code,
with a few modifications:
* There is a upper bound on how large the replay filter can grow.
Currently this is set to 102400 entries, though it is unlikely that
this limit will be hit.
* A doubly linked list is also maintained parallel to the map, so the
filter compaction process does not need to iterate over the entire
filter.
|
|
|
|
* Fixed where the code wasn't ensuring that the MAC_[C,S] was present.
* Optimized the server side to only look at the tail of the (possibly
incomplete handshakeRequest).
|
|
Clients will now always add 87 bytes of padding to the clientRequest,
and Servers will always send the PRNG seed frame unpadded, and bundled
with the serverResponse.
Why 87 bytes? The amount of data that the server sends is 87.
This fixes #5.
|
|
|
|
* HMAC-SHA256 -> HMAC-SHA256-128.
* Mark/MAC are now both caluclated using Public Key | NodeID.
This breaks wire protocol compatibility.
|
|
The same algorithm as ScrambleSuit is used, except:
* SipHash-2-4 in OFB mode is used to create the distribution.
* The system CSPRNG is used when sampling the distribution.
This fixes most of #3, all that remains is generating and sending a
persistent distribution on the server side to the client.
|
|
Like ScrambleSuit, a random interval between 1x and 5x of additional
data from the peer is read and immediately discarded before closing.
Additionally, obfs4 will close off invalid connections anywhere between
0 and 60 seconds after it determines that the incoming connection will
never complete the handshake successfully.
|
|
|
