| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
| |
If the password argument is missing from the bridge line entirely,
`handle_socks_args()` will never get called as the username/password
auth will not be negotiated. Correctly detect that this has happened
at client handshake time, log a warning and drop the connection.
Fixes bug #13587.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Adapt the server's behaviour to the spec change of commit 892846eb. When a
server bootstraps for the first time, it randomly generates a byte threshold
after which unauthenticated connections are closed.
This should fix <https://bugs.torproject.org/11092>.
|
| |
|
|
|
|
|
|
|
| |
In particular, discuss strategies which servers should implement if clients
cannot authenticate. Otherwise, malicious clients could run computation-based
or memory-based denial-of-service attacks. This problem was reported by
Yawning Angel.
This should fix <https://bugs.torproject.org/11092>.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
instead of printing it for every new connection
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
twisted.internet.error.UnsupportedAddressFamily was added in twisted-12.1.0.
This commit adds a stub that emulates it for platforms that don't have a
recent Twisted (e.g. Debian squeeze/wheezy).
|
| |
|
|
| |
Server-side obfsproxy does not need txsocksx.
|
| |
|
|
|
|
| |
From now on, obfsproxy when configured to connect to a proxy (either
using --proxy or TOR_PT_PROXY) will refuse to run if it doesn't have
txsocksx or its Twisted is too old (< 13.2.0).
|
| |\
| |
| |
| |
| | |
Conflicts:
ChangeLog
|
| | |
| |
| |
| |
| |
| | |
Clean some long lines, and some instances of pylint's
logging-not-lazy (although the rest of the codebase has many more
instances of this).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some HTTP proxys opt to close the connection instead of returning a
HTTP status code on certain failures (Eg: polipo auth faliure, privoxy
ACL denial). This change logs a better error message to the obfsproxy
log when that happens.
As an added bonus the SOCKS5 server now knows about EHOSTUNREACH, so
a more informative response is sent on that failure type.
|
| | | |
|