Right now, all our curve25519 backends ignore the high bit of the
public key. But possibly, others could treat the high bit of the
public key as encoding out-of-bounds values, or as something to be
preserved. This could be used to distinguish clients with different
backends, at the cost of killing a circuit.
As a workaround, let's just clear the high bit of each public key
indiscriminately before we use it. Fix for bug 8121, reported by
rransom. Bugfix on 0.2.4.8-alpha.
The fix is to move the two functions to format/parse base64
curve25519 public keys into a new "crypto_format.c" file. I could
have put them in crypto.c, but that's a big file worth splitting
anyway.
Fixes bug 8153; bugfix on 0.2.4.8-alpha where I did the fix for 7869.
Now as we move into a future where most bridges can handle microdescs
we will generally find ourselves using them, rather than holding back
just because one of our bridges doesn't use them.
When we first implemented TLS, we assumed in conneciton_handle_write
that a TOR_TLS_WANT_WRITE from flush_buf_tls meant that nothing had
been written. But when we moved our buffers to a ring buffer
implementation back in 0.1.0.5-rc (!), we broke that invariant: it's
possible that some bytes have been written but nothing.
That's bad. It means that if we do a sequence of TLS writes that ends
with a WANTWRITE, we don't notice that we flushed any bytes, and we
don't (I think) decrement buckets.
Fixes bug 7708; bugfix on 0.1.0.5-rc
Instead of hardcoding the minimum fraction of possible paths to 0.6, we
take it from the user, and failing that from the consensus, and
failing that we fall back to 0.6.
Previously we did this based on the fraction of descriptors we
had. But really, we should be going based on what fraction of paths
we're able to build based on weighted bandwidth, since otherwise a
directory guard or two could make us behave quite oddly.
Implementation for feature 5956
This is allowed by the C statndard, which permits you to represent
doubles any way you like, but in practice we have some code that
assumes that memset() clears doubles in structs. Noticed as part of
7802 review; see 8081 for more info.
You can get it back by saying ./autogen.sh -v
Patch from onizuka; for bug 4664.
This isn't a complete fix, since starting from a clean checkout still
reports that it's installing stuff
This is ticket 7706, reported by "bugcatcher." The rationale here
is that if somebody says 'ExcludeNodes {tv}', then they probably
don't just want to block definitely Tuvaluan nodes: they also want
to block nodes that have unknown country, since for all they know
such nodes are also in Tuvalu.
This behavior is controlled by a new GeoIPExcludeUnknown autobool
option. With the default (auto) setting, we exclude ?? and A1 if
any country is excluded. If the option is 1, we add ?? and A1
unconditionally; if the option is 0, we never add them.
(Right now our geoip file doesn't actually seem to include A1: I'm
including it here in case it comes back.)
This feature only takes effect if you have a GeoIP file. Otherwise
you'd be excluding every node.
This won't actually break them any worse than they were broken before:
it just removes a set of warnings that nobody was actually seeing, I
hope.
Closes 6826
The implementation is pretty straightforward: parse_extended_hostname() is
modified to drop any leading components from an address like
'foo.aaaaaaaaaaaaaaaa.onion'.
In 6fbdf635 we added a couple of statements like:
if (test) {
...
};
The extraneous semicolons there get flagged as worrisome empty
statements by the cparser library, so let's fix them.
Patch by Christian Grothoff; fixes bug 7115.
Otherwise, it's possible to create streams or circuits with these
bogus IDs, leading to orphaned circuits or streams, or to ones that
can cause bandwidth DOS problems.
Fixes bug 7889; bugfix on all released Tors.
The right way to set "MaxOnionsPending" was to adjust it until the
processing delay was appropriate. So instead, let's measure how long
it takes to process onionskins (sampling them once we have a big
number), and then limit the queue based on its expected time to
finish.
This change is extra-necessary for ntor, since there is no longer a
reasonable way to set MaxOnionsPending without knowing what mix of
onionskins you'll get.
This patch also reserves 1/3 of the onionskin spots for ntor
handshakes, on the theory that TAP handshakes shouldn't be allowed to
starve their speedier cousins. We can change this later if need be.
Resolves 7291.
Our old warn_nonlocal_client_ports() would give a bogus warning for
every nonlocal port every time it parsed any ports at all. So if it
parsed a nonlocal socksport, it would complain that it had a nonlocal
socksport...and then turn around and complain about the nonlocal
socksport again, calling it a nonlocal transport or nonlocal dnsport,
if it had any of those.
Fixes bug 7836; bugfix on 0.2.3.3-alpha.
mr-4 reports on #7799 that he was seeing it several times per second,
which suggests that things had gone very wrong.
This isn't a real fix, but it should make Tor usable till we can
figure out the real issue.
This implements the server-side of proposal 198 by detecting when
clients lack the magic list of ciphersuites that indicates that
they're lying faking some ciphers they don't really have. When
clients lack this list, we can choose any cipher that we'd actually
like. The newly allowed ciphersuites are, currently, "All ECDHE-RSA
ciphers that openssl supports, except for ECDHE-RSA-RC4".
The code to detect the cipher list relies on on (ab)use of
SSL_set_session_secret_cb.
This is good enough to give P_success >= 999,999,999/1,000,000,000 so
long as the address space is less than 97.95 full. It'd be ridiculous
for that to happen for IPv6, and usome reasonable assumptions, it
would also be pretty silly for IPv4.
This replaces the old FallbackConsensus notion, and should provide a
way -- assuming we pick reasonable nodes! -- to give clients
suggestions of placs to go to get their first consensus.
This is the simplest possible workaround: make it safe to call
circuit_cell_queue_clear() on a non-attached circuit, and make it
safe-but-a-LD_BUG-warning to call update_circuit_on_cmux() on a
non-attached circuit.
LocalWords: unstage src Untracked
Apparently some compilers like to eliminate memset() operations on
data that's about to go out-of-scope. I've gone with the safest
possible replacement, which might be a bit slow. I don't think this
is critical path in any way that will affect performance, but if it
is, we can work on that in 0.2.4.
Fixes bug 7352.
Instead of warning about low ports that are advertised, we should have
been warning about low ports that we're listening on. Bug 7285, fix
on 0.2.3.9-alpha.
That's not where I'd want to put a $, but apparently the other
foo/id/<identity> things allow it, as does an arguably valid
interpretation of control-spec.txt. So let's be consistent.
Fix for a piece of bug 7059.
This is part of what's needed to build without warnings on mingw64:
it was warning about the cast from void* to long that happened in
the places we were using test_{n,}eq on pointers.
The alternative here would have been to broaden tt_int_op to accept
a long long or an intptr_t, but that's less correct (since pointers
aren't integers), and would hurt the portability of tinytest a
little.
Fixes part of 7260.
We still want to build on compilers w/o c99 support, such as
(notoriously, shamefully) MSVC.
So I'm commenting out the designated initializers in
circuitmux_ewma.c. The alternative would have been to use some kind
of macros to use designated initializers only when they're
supported, but that's error-prone, and can lead to code having
different meanings under different compilers.
Bug 7286; fix on 0.2.4.4-alpha; spotted by Gisle Vanem.
If we completed the handshake for the v2 link protocol but wound up
negotiating the wong protocol version, we'd become so confused about
what part of the handshake we were in that we'd promptly die with an
assertion.
This is a fix for CVE-2012-2250; it's a bugfix on 0.2.3.6-alpha.
All servers running that version or later should really upgrade.
Bug and fix from "some guy from France." I tweaked his code slightly
to make it log the IP of the offending node, and to forward-port it to
0.2.4.
If we completed the handshake for the v2 link protocol but wound up
negotiating the wong protocol version, we'd become so confused about
what part of the handshake we were in that we'd promptly die with an
assertion.
This is a fix for CVE-2012-2250; it's a bugfix on 0.2.3.6-alpha.
All servers running that version or later should really upgrade.
Bug and fix from "some guy from France." I tweaked his code slightly
to make it log the IP of the offending node.
Clients now consider the ClientRejectInternalAddresses config option
when using a microdescriptor consensus stanza to decide whether
an exit relay would allow exiting to an internal address. Fixes
bug 7190; bugfix on 0.2.3.1-alpha.
Our implementation of parse_short_policy was screwed up: it would
ignore the last character of every short policy. Obviously, that's
broken.
This patch fixes the busted behavior, and adds a bunch of unit tests
to make sure the rest of that function is okay.
Fixes bug 7192; fix on 0.2.3.1-alpha.
Conflicts:
src/or/circuitbuild.c
There was a huge-looking conflict in circuitbuild.c, but the only
change that had been made to circuitbuild.c since I forked off the
split_circuitbuild branch was 17442560c4. So I took the
split_circuitbuild version of the conflicting part, and manually
re-applied the change from 17442560c44e8093f9a..
OpenSSL 1.0.0 added an implementation of TLS session tickets, a
"feature" that let session resumption occur without server-side state
by giving clients an encrypted "ticket" that the client could present
later to get the session going again with the same keys as before.
OpenSSL was giving the keys to decrypt these tickets the lifetime of
the SSL contexts, which would have been terrible for PFS if we had
long-lived SSL contexts. Fortunately, we don't. Still, it's pretty
bad. We should also drop these, since our use of the extension stands
out with our non-use of session cacheing.
Found by nextgens. Bugfix on all versions of Tor when built with
openssl 1.0.0 or later. Fixes bug 7139.
Failure to do so left us open to a remotely triggerable assertion
failure. Fixes CVE-2012-2249; bugfix on 0.2.3.6-alpha. Reported by
"some guy from France".
This patch is a forward-port to 0.2.4, to work with the new channel
logic.
Failure to do so left us open to a remotely triggerable assertion
failure. Fixes CVE-2012-2249; bugfix on 0.2.3.6-alpha. Reported by
"some guy from France".
Our convention is that we use the changelog to note release-to-release
changes; we don't need to add changelog entries for bugs that didn't
appear in any released version of Tor. (By convention, we sometimes
say "this bug does not appear in any released version of Tor" or words
to that effect in the commit message so that when Roger goes to make
sure the changelog is right, he knows not to expect a changelog entry
for that part.)
There are as many divergent implementations of sys/queue.h as there
are operating systems shipping it, it would seem. They have some code
in common, but have drifted apart, and have added other stuff named
differently. So I'm taking a relatively sane one, and hoping for the
best.
I'm taking OpenBSD's in particular because of the lack of external
dependencies, the presence of a CIRCLEQ (we could use one of those in
places), and the liberal licensing terms.
I'm naming the file tor_queue.h, since historically we've run into
trouble having headers with the same names as system headers (log.h,
for example.)
The rationale for treating these files differently is that we should
be checking upstream for changes as applicable, and merging changes
upstream as warranted.
Conflicts:
src/or/circuitbuild.c
The conflict was trivial, since no line of code actually changed in
both branches: There was a fmt_addr() that turned into fmt_addrport()
in bug7011, and a "if (!n_conn)" that turned into "if (!n_chan)" in
master.
They're typically redundant with the "Your computer is too slow"
messages. Fixes bug 7038; bugfix on 0.2.2.16-alpha.
(In retrospect, we should have fixed this bug back in ticket 1042.)
