I've managed to keep this change mainly contained to our
self-testing module. The changes here are:
* There are two different variables for tracking "is our orport
reachable".
* We have a new function that says whether we can skip a single
family's orport reachability test; the old function for this now
tells whether we can skip _all_ orport reachability testing.
(The name, router_should_skip_orport_reachability_test, is not
so good. I will rename it later if I can think of a good
replacement.)
* The function that launches orport reachability tests now only
launches the ones that haven't completed.
* The function that notes that we're reachable on an ORPort now
takes a family.
* Various log messages are cleaned up.
Since Tor 0.2.9 has been unsupported since January, 0.3.5 is the
oldest supported version, and its features constitute the oldest
recommended feature-set.
This patch updates these recommendations:
DirCache=2
Support for consensus diffs.
New in 0.3.1.1-alpha.
HSDir=2
Support for v3 onion service descriptors.
New in 0.3.0.4-alpha.
HSIntro=4
Support for Ed25519 intropoint authentication keys.
New in 0.3.0-4-alpha.
HSRend=2
Support for rendezvous cells longer than 20 bytes.
New in 0.2.9.4-alpha.
Link=5
Link padding and link padding negotiation.
New in 0.3.3.2-alpha.
LinkAuth=3
Ed25519 link authentication.
New in 0.3.0.1-alpha.
M_SYSCALL is used to report information about a sandbox violation,
but when we don't have a definition for it, it still makes sense to
compile.
Closes ticket 34382.
Resume being willing to use preemptively-built circuits when
UseEntryGuards is set to 0. We accidentally disabled this feature with
that config setting (in our fix for #24469), leading to slower load times.
Fixes bug 34303; bugfix on 0.3.3.2-alpha.
Make Rust protocol version support checks consistent with the
undocumented error behaviour of the corresponding C code.
Fixes bug 34251; bugfix on 0.3.3.5-rc.
Declare support for the onion service introduction point denial of
service extensions, when building tor with Rust.
Fixes bug 34248; bugfix on 0.4.2.1-alpha.
... and DISABLE_ASSERTS_IN_UNIT_TESTS.
Make all of tor's assertion macros support the ALL_BUGS_ARE_FATAL and
DISABLE_ASSERTS_IN_UNIT_TESTS debugging modes.
Implements these modes for IF_BUG_ONCE(). (It used to log a non-fatal
warning, regardless of the debugging mode.)
Fixes bug 33917; bugfix on 0.2.9.1-alpha.
Allow clients and relays to send dual-stack and IPv6-only EXTEND2 cells.
Parse dual-stack and IPv6-only EXTEND2 cells on relays.
Relays do not make connections or extend circuits via IPv6: that's the
next step.
Closes ticket 33901.
Log IPv6 addresses on connections where this relay is the responder.
Previously, responding relays would replace the remote IPv6 address with
the IPv4 address from the consensus.
(The port is replaced with the IPv6 ORPort from the consensus, we will
resolve this issue in 33898.)
Fixes bug 33899; bugfix on 0.3.1.1-alpha.
Consider IPv6 addresses when checking if a connection is canonical.
In 17604, relays assumed that a remote relay could consider an IPv6
connection canonical, but did not set the canonical flag on their side
of the connection.
Fixes bug 33899; bugfix on 0.3.1.1-alpha.
The client auth protocol allows attacker-controlled x25519 private keys being
passed around, which allows an attacker to potentially trigger the all-zeroes
assert for client_auth_sk in hs_descriptor.c:decrypt_descriptor_cookie().
We fixed that by making sure that an all-zeroes client auth key will not be
used.
There are no guidelines for validating x25519 private keys, and the assert was
there as a sanity check for code flow issues (we don't want to enter that
function with an unitialized key if client auth is being used). To avoid such
crashes in the future, we also changed the assert to a BUG-and-err.
This change broke torsocks that by default is expecting an IPv4 for hostname
resolution because it can't ask tor for a specific IP version with the SOCKS5
extension.
PreferIPv6 made it that sometimes the IPv6 could be returned to torsocks that
was expecting an IPv4.
Torsocks is probably a very unique case because the runtime flow is that it
hijacks DNS resolution (ex: getaddrinfo()), gets an IP and then sends it back
for the connect() to happen.
The libc has DNS resolution functions that allows the caller to request a
specific INET family but torsocks can't tell tor to resolve the hostname only
to an IPv4 or IPv6 and thus by default fallsback to IPv4.
Reverting this change into 0.4.3.x series but we'll keep it in the 0.4.4.x
series in the hope that we add this SOCKS5 extension to tor for DNS resolution
and then change torsocks to use that.
Fixes#33804
Signed-off-by: David Goulet <dgoulet@torproject.org>
Avoid conflicts between the fake sockets in tor's unit tests, and real
file descriptors. Resolves issues running unit tests with GitHub
Actions, where the process that embeds or launches the tests has
already opened a large number of file descriptors.
Fixes bug 33782; bugfix on 0.2.8.1-alpha.
Found and fixed by Putta Khunchalee.
If the buf_t's length could potentially become greater than INT_MAX - 1,
it sets off an IF_BUG_ONCE in buf_read_from_tls().
All of the rest of the buffers.c code has similar BUG/asserts for this
invariant.
When IPv6 ORPorts are set to "auto", tor relays and bridges would
advertise an incorrect port in their descriptor.
This may be a low-severity memory safety issue, because the published
port number may be derived from uninitialised or out-of-bounds memory
reads.
Fixes bug 32588; bugfix on 0.2.3.9-alpha.
Previously we just ignored this option, which would leave it unset,
and cause an assertion failure later on when running with the User
option.
Fixes bug 33668; bugfix on 0.4.3.1-alpha.
Copy required DLLs to test and app, before running tor's tests.
This ensures that tor.exe and test*.exe use the correct version of each
DLL. This fix is not required, but we hope it will avoid DLL search
issues in future.
Closes bug 33673; bugfix on 0.3.4.2-alpha.
For example, "TOR_SKIP_TESTCASES=crypto/.. ./src/test/test" will run
the tests and suppress all the "crypto/" tests. You could get the
same effect by running "./src/test/test :crypto/..", but that can be
harder to arrange from CI.
Part of a fix/workaround for 33643.
Given that ed25519 public key validity checks are usually not needed
and (so far) they are only necessary for onion addesses in the Tor
protocol, we decided to fix this specific bug instance without
modifying the rest of the codebase (see below for other fix
approaches).
In our minimal fix we check that the pubkey in
hs_service_add_ephemeral() is valid and error out otherwise.
This function does a nonfatal assertion to make sure that a machine
is not registered twice, but Tobias Pulls found a case where it
happens. Instead, make the function exit early so that it doesn't
cause a remotely triggered memory leak.
Fixes bug 33619; bugfix on 0.4.0.1-alpha. This is also tracked as
TROVE-2020-004.
Now port_cfg_new() returns all default flags and
port_parse_config() acts on defaults returned by port_cfg_new()
that is uses the default port_cfg_t object returned by port_cfg_new()
and modifies them later according to the port specifications in
configuration files
Might close tor#32994.
Stop forcing all non-SOCKSPorts to prefer IPv6 exit connections.
Instead, prefer IPv6 connections by default, but allow users to change
their configs using the "NoPreferIPv6" port flag.
Fixes bug 33608; bugfix on 0.4.3.1-alpha.
To run this, say something like
TOR_DEVTOOL_DIR=~/bin scripts/git/git-install-tools.sh all
To see what it would do, give it the -n flag.
To get help, give it the -h flag.
When a service can not upload its descriptor(s), we have no logs on why. This
adds logging for each possible reason for each descriptors.
That logging is emitted every second so it is rate limited for each reason and
per descriptor.
Closes#33400
Signed-off-by: David Goulet <dgoulet@torproject.org>
For a bridge configured with a pluggable transport, the transport name is
used, with the IP address, for the GeoIP client cache entry.
However, the DoS subsystem was not aware of it and always passing NULL when
doing a lookup into the GeoIP cache.
This resulted in bridges with a PT are never able to apply DoS defenses for
newly created connections.
Fixes#33491
Signed-off-by: David Goulet <dgoulet@torproject.org>
