david415 / obfsproxy Public

…rts/obfsproxy into david-bananaphone

Traceback (most recent call last):
  File "./bin/obfsproxy", line 15, in <module>
    from obfsproxy.pyobfsproxy import run
  File "./obfsproxy/pyobfsproxy.py", line 12, in <module>
    import obfsproxy.network.launch_transport as launch_transport
  File "./obfsproxy/network/launch_transport.py", line 2, in <module>
    import obfsproxy.transports.transports as transports
  File "./obfsproxy/transports/transports.py", line 15
    'scramblesuit' : {'base':  scramblesuit.ScrambleSuitTransport,
    ^
IndentationError: unexpected indent

Signed-off-by: David Stainton <dstainton415@gmail.com>

Merge branch 'master' of https://git.torproject.org/pluggable-transports/obfsproxy into david-bananaphone

Conflicts:
	obfsproxy/common/transport_config.py
	obfsproxy/managed/client.py
	obfsproxy/managed/server.py
	obfsproxy/pyobfsproxy.py
	obfsproxy/transports/transports.py

…nching.

Conflicts:
	obfsproxy/transports/scramblesuit/scramblesuit.py

Because of technical problems (see #10887:comment:11) it was not so easy
to write the actual Bridge line that people were supposed to use. Let's
just write the password for now.

Conflicts:
	obfsproxy/transports/scramblesuit/const.py
	obfsproxy/transports/scramblesuit/state.py

Conflicts:
	obfsproxy/transports/scramblesuit/scramblesuit.py

Conflicts:
	obfsproxy/test/transports/test_scramblesuit.py

This argument permits to run obfsproxy in unmanaged mode and
pass a file containing the scramblesuit password. That way
password won't be visible in process list.

We only want to run the packet morphing algorithm when we really need
it -- which is immediately before we send data.  Previously, we would morph
immediately upon receiving data which is not optimal.

This should fix <https://bugs.torproject.org/10991>.  Thanks to Yawning Angel
who pointed out the problem.

Thanks to Yawning Angel for catching this.

To a user, it's not immediately clear that a given password was not well
formed.  The refactored error messages should fix that.  See bug
<https://bugs.torproject.org/11143> for context.

Conflicts:
	ChangeLog

While the general idea is explained, there are no exact details.
Implementations may use different (CS)PRNGs to derive probability
distributions.  Such "flow diversity" might even be beneficial.

Conflicts:
	doc/scramblesuit/scramblesuit-spec.txt

The first message makes use of the HMAC key which is derived from the master
key.  It does not use the master key itself.

On occasion, a client's or a server's epoch might already have increased
whereas the epoch of the other party didn't.  This is a benign event and there
is no reason to fail authentication because of this.  As a result, as a server,
we now also test boundary values, i.e., epoch - 1, epoch, epoch + 1.

That's only relevant for UniformDH.

There's no need for the server to determine its own epoch.

Since we no longer process data after authentication has failed, we might as
well increase the closing threshold.  The larger interval hopefully makes
ScrambleSuit bridges less fingerprintable for active adversaries.

If the client did not authenticate after MAX_HANDSHAKE_LENGTH bytes,
authentication has failed.  For obfuscation, we keep the connection open a
while longer but we stop processing all data from that point on to prevent
denial-of-service attacks.  (Partial) patch by Yawning Angel.
For previous discussion, see: <https://bugs.torproject.org/11092>.

We know in which array slice the mark is expected.  As a result, we don't have
to look any further than that.  Patch by Yawning Angel.  See the following
ticket for reference: <https://bugs.torproject.org/11092>.

1. Fix a typo by changing "X" to "Y".
2. Add "M_C" and "M_S" to the respective MAC function as they are also
   authenticated.

The problem was pointed out by Yawning Angel in:
<https://bugs.torproject.org/10893>

The problem was pointed out by Yawning Angel in:
<https://bugs.torproject.org/10893#comment:3>

Conflicts:
	ChangeLog