| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This makes it consistent across all incoming connections, for real this
time (oops).
|
|
It will vary per bridge as it is based off the DRBG, but ever attempt
at poking at any given bridge will exhibit consistent behavior.
|
|
This is more common than 15 seconds (It's what Firefox uses for the
request timeout).
|
|
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.
|
|
This fixes #3, and brings the code to be on par with the delopyed
versions of ScrambleSuit in terms of features.
|
|
This also adds the drgb-seed option to the `-gen` obfs4proxy output.
|
|
This paves the way for having servers use the same seed for all
incoming connections, across multiple startup/shutdown cycles. As
opposed to the current situation where each Obfs4Listener will
randomly generate it's seed at creation time.
Additionally, use 256 bit seeds (128 bit SipHash-2-4 key + 16 bytes of
initial material).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
On second thought instead of using log.Panicf(), panic() and do the
logging with recover(). This somewhat centralizes logging in
obfs4proxy, which will be easier to change when I invariably decide to
do logging differently in the future.
|
|
This adds preliminary support for data padding by adding another layer
of encapsulation inside each AEAD frame containing a type and length.
For now, data is still sent unpadded, but the infrastructure for
supporting it is mostly there.
Additionally, use log.Panic[f]() instead of panic through out the code
so that some panics are logged.
|
|
Write timeouts are obnoxious to handle as the frame encoder state
already is updated to cover the entire payload for the Write() call
that timed out. In theory it is possible to buffer the pending data,
but that causes Write() to voilate the semantics of the interface.
|
|
|
|
The current timeout value before the server fails the handshake is
15 s. This may need to be increased for clients over slow links.
|
|
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.
|
|
* The old and the busted: obfs4-[client,server].
* The new hotness: obfs4client.
* Add obfs4.ServerHandshake() that servers need to call after a
successful return from Accept(). This allows implementations to
move the handshake into a goroutine or whatever.
|
|
|
