Replace it by find_my_address() everywhere. This changes many parts of the
code that uses it to use a tor_addr_t instead of a plain uint32_t for IPv4.
Many changes to the unit test to also use the new interface.
Part #33233
Signed-off-by: David Goulet <dgoulet@torproject.org>
Series of changes:
1. Rename function to reflect the namespace of the file.
2. Use the new last resolved cache instead of the unused
last_resolved_addr_v4 (which is also removed in this commit).
3. Make the entire code base use the new resolved_addr_is_local() function.
You will notice that this function uses /24 to differentiate subnets where the
rest of tor uses /16 (including documentation of EnforceDistinctSubnets).
Ticket #40009 has been opened for that.
But that the moment, the function keeps looking at /24.
Part of #33233
Signed-off-by: David Goulet <dgoulet@torproject.org>
Series of things done in this commit:
1. Rename the functions to better reflect the namespace of the file.
2. Make both reset and get function to operate on the last_resolved_addrs
cache that is per family.
3. Make the get function to take a tor_addr_t.
4. Change all callsite to use the new convention.
Part of #33233
Signed-off-by: David Goulet <dgoulet@torproject.org>
In order to transition smoothly, maek resolve_my_address_v4() call the new
fancy find_my_address() with AF_INET.
Next commits should remove the use of resolve_my_address_v4() accross the code
to use find_my_address().
This commit is so the unit tests would be more easily fixed and port to the
new find_my_address() internals.
Part of #33233.
Signed-off-by: David Goulet <dgoulet@torproject.org>
resolve_my_address() was beyond repair in terms of refactoring. Way too
complex and doing too many things.
This commit implements find_my_address() which in theory does the same as
resolve_my_address() but in a more clean, concise and modern way using the
tor_addr_t interface and for multiple address family.
The caller needs to pass the address family (IPv4 or IPv6) which this
interface supports. For both, a last resolved cache is used as well.
Implements #33233
Signed-off-by: David Goulet <dgoulet@torproject.org>
These identifiers are confusing and unreadable. I think these
replacements should be better. Closes ticket #40012.
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
router_should_skip_orport_reachability_check_family router_orport_seems_reachable \
router_should_skip_dirport_reachability_check router_dirport_seems_reachable \
router_should_skip_dirport_reachability_check router_all_orports_seem_reachable
The buf_read_from_tls() function was designed to read up to a certain number
of bytes a TLS socket using read_to_chunk_tls() which boils down to SSL_read()
(with OpenSSL, common case).
However, at the end of the loop, the returned number of bytes from
read_to_chunk_tls() was treated like the syscall read() for which if less
bytes than the total asked are returned, it signals EOF.
But, with SSL_read(), it returns up to a TLS record which can be less than
what was asked. The assumption that it was EOF was wrong which made the while
loop exiting before it was able to consume all requested bytes (at_most
parameter).
The general use case that Tor sees is that it will ask the network layer to
give it at most 16KB (that is roughly 32 cells) but because of KIST scheduler,
the highest possible TLS record we currently observe is 4096 bytes (4KB or 8
cells). Thus the loop would at best always return 8 cells even though much
more could be on the TLS socket. See ticket #40006 for more details.
Fixes#40006
Signed-off-by: David Goulet <dgoulet@torproject.org>
Since "skip orport check" is the "and" of v4_ok and v6_ok, we can
just compute v4_ok and v6_ok once, to clarify that we don't enter
this block of code if they're both true.
With prop312, we want to support IPv4 and IPv6 thus multiple Address statement
(up to 2) will be accepted.
For this, "Address" option becomes a LINELIST so we can properly process the
IPv4 or/and IPv6.
Part of #33233
Signed-off-by: David Goulet <dgoulet@torproject.org>
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.
This tracking of the instantiation count should eliminate race conditions due
to starting and stopping machines rapidly. Now, we should no longer obey
STOP commands for previous machines.
This field area was memset to 0 in old versions, which the code treats as
"match any machine instance", for backward compatibility without a protover
bump.
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.
Per ticket #32888 this should address logging "the Address torrc
option", "and whether it is an IP address, or a DNS name"; or the
detected "local hostname", "and whether it is an IP address, or a DNS
name". Some of these details already seem to be logged, so just add
what's missing.
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.
Add an inline helper function that indicates if the cached object contains a
decrypted descriptor or not.
The descriptor object is NULL if tor is unable to decrypt it (lacking client
authorization) and some actions need to be done only when we have a decrypted
object.
This improves code semantic.
Fixes#33458
Signed-off-by: David Goulet <dgoulet@torproject.org>
The warning was:
11:23:10 ../tor/src/feature/hs/hs_service.c: In function 'log_cant_upload_desc':
11:23:10 ../tor/src/feature/hs/hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
See #34254 for more info.
I guess this means that gcc assigned an unsigned type to the
`log_desc_upload_reason_t` enum and it warned if we compared it against 0...
For now I think it's simpler to remove that check instead of turning the enum
to a signed type, or trying to hack it some other way.
From what it seems, enum is up to the compiler on whether it's signed/unsigned:
https://stackoverflow.com/questions/159034/are-c-enums-signed-or-unsigned
Use the node check function to check that there are enough nodes to
select a circuit path.
Adds these checks, which are implied by other code:
* supports EXTEND2 cells,
* does not allow single-hop exits,
Adds these extra checks:
* has a general-purpose routerinfo,
* if it is a direct connection, check reachable addresses.
These checks reduce the node count, but they will never under-count
nodes.
Bridge nodes aren't handled correctly, we'll fix that in the next
commit.
Part of 34200.
And check that the correct flags are passed when choosing exits.
Adds the following checks for exits:
* must support EXTEND2 cells,
* must have an ntor circuit crypto key,
* can't require the guard flag,
* can't be a direct connection.
All these checks are already implied by other code.
Part of 34200.
Instead, call out to a helper function, repeating the call if needed.
Avoids duplicating exclusions for:
* the current relay's family, and
* any exclusions specified by the caller.
Part of 34200.
And delete a loop that is now empty. This change should improve tor's
performance, because we no longer iterate through the nodelist twice for
every node in every circuit path.
Part of 34200.
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.
Add tests for relays sending IPv6 extend cells in
circuit_send_next_onion_skin().
Clients also use this code, check that they can only extend over IPv4
(for now).
Part of 33222.
Rewrite inform_testing_reachability() to use separate buffers for IPv4
ORPort, IPv6 ORPort, and IPv4 DirPort. And use consistent APIs to fill
those buffers.
Part of 33222.
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
client_or_conn_should_skip_reachable_address_check router_or_conn_should_skip_reachable_address_check \
client_dir_conn_should_skip_reachable_address_check router_dir_conn_should_skip_reachable_address_check
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
router_skip_orport_reachability_check router_should_skip_orport_reachability_check \
router_skip_dirport_reachability_check router_should_skip_dirport_reachability_check \
router_connect_assume_or_reachable client_or_conn_should_skip_reachable_address_check \
router_connect_assume_dir_reachable client_dir_conn_should_skip_reachable_address_check
It was generated with --no-verify, so it probably breaks some commit hooks.
The commiter should be sure to fix them up in a subsequent commit.
GCC added an implicit-fallthrough warning a while back, where it
would complain if you had a nontrivial "case:" block that didn't end
with break, return, or something like that. Clang recently added
the same thing.
GCC, however, would let you annotate a fall-through as intended by
any of various magic "/* fall through */" comments. Clang, however,
only seems to like "__attribute__((fallthrough))". Fortunately, GCC
accepts that too.
A previous commit in this branch defined a FALLTHROUGH macro to do
the right thing if GNUC is defined; here we replace all of our "fall
through" comments with uses of that macro.
This is an automated commit, made with the following perl one-liner:
#!/usr/bin/perl -i -p
s#/\* *falls? ?thr.*?\*/#FALLTHROUGH;#i;
(In order to avoid conflicts, I'm applying this script separately to
each maint branch. This is the 0.4.3 version.)
GCC added an implicit-fallthrough warning a while back, where it
would complain if you had a nontrivial "case:" block that didn't end
with break, return, or something like that. Clang recently added
the same thing.
GCC, however, would let you annotate a fall-through as intended by
any of various magic "/* fall through */" comments. Clang, however,
only seems to like "__attribute__((fallthrough))". Fortunately, GCC
accepts that too.
A previous commit in this branch defined a FALLTHROUGH macro to do
the right thing if GNUC is defined; here we replace all of our "fall
through" comments with uses of that macro.
This is an automated commit, made with the following perl one-liner:
#!/usr/bin/perl -i -p
s#/\* *falls? ?thr.*?\*/#FALLTHROUGH;#i;
(In order to avoid conflicts, I'm applying this script separately to
each maint branch. This is the 0.4.2 version.)
GCC added an implicit-fallthrough warning a while back, where it
would complain if you had a nontrivial "case:" block that didn't end
with break, return, or something like that. Clang recently added
the same thing.
GCC, however, would let you annotate a fall-through as intended by
any of various magic "/* fall through */" comments. Clang, however,
only seems to like "__attribute__((fallthrough))". Fortunately, GCC
accepts that too.
A previous commit in this branch defined a FALLTHROUGH macro to do
the right thing if GNUC is defined; here we replace all of our "fall
through" comments with uses of that macro.
This is an automated commit, made with the following perl one-liner:
#!/usr/bin/perl -i -p
s#/\* *falls? ?thr.*?\*/#FALLTHROUGH;#i;
(In order to avoid conflicts, I'm applying this script separately to
each maint branch. This is the 0.4.1 version.)
GCC added an implicit-fallthrough warning a while back, where it
would complain if you had a nontrivial "case:" block that didn't end
with break, return, or something like that. Clang recently added
the same thing.
GCC, however, would let you annotate a fall-through as intended by
any of various magic "/* fall through */" comments. Clang, however,
only seems to like "__attribute__((fallthrough))". Fortunately, GCC
accepts that too.
A previous commit in this branch defined a FALLTHROUGH macro to do
the right thing if GNUC is defined; here we replace all of our "fall
through" comments with uses of that macro.
This is an automated commit, made with the following perl one-liner:
#!/usr/bin/perl -i -p
s#/\* *falls? ?thr.*?\*/#FALLTHROUGH;#i;
This macro defers to __attribute__((fallthrough)) on GCC (and
clang). Previously we had been using GCC's magic /* fallthrough */
comments, but clang very sensibly doesn't accept those.
Since not all compiler recognize it, we only define it when our
configure script detects that it works.
Part of a fix for 34078.
Move a series of function from config.c into that new file which is related to
address resolving.
Part of #33789
Signed-off-by: David Goulet <dgoulet@torproject.org>
This commit moves router_pick_published_address() and the related helper
functions into the new file.
The log_addr_has_changed() function has been made public in router.h so we can
use it in relay_resolve_addr.c.
This is a refactoring as part of Sponsor 55. Only code movement at this
commit.
Part of #33789
Signed-off-by: David Goulet <dgoulet@torproject.org>
Do not try to stuff "HS_DESC_DECODE_GENERIC_ERROR" (-1) into a
socks5_reply_status_t (enum). It doesn't actually make sense, and
isn't one of our documented extensions.
(This can only happen on a nonfatal assertion that we haven't seen,
so it probably isn't happening in practice.)
Fixes another case of bug 34077; bugfix on 0.4.3.1-alpha.
Allow relays and bridges to send IPv4 or IPv6 extend cells.
But keep restricting clients to IPv4 extend cells, because sending IPv6
extend cells would be an obvious version distinguisher.
Part of 33222.
When a relay starts testing reachability, log its IPv6 ORPort.
The existing code logs the IPv4 ORPort and DirPort.
The IPv4 ORPort is required. The other ports are only logged if they
are present.
Part of 33222.
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
check_whether_orport_reachable router_skip_orport_reachability_check \
check_whether_dirport_reachable router_skip_dirport_reachability_check
It was generated with --no-verify, so it probably breaks some commit hooks.
The commiter should be sure to fix them up in a subsequent commit.
Part of 33222.
Change some function names to distinguish between:
* client first hop reachability (ReachableAddresses)
* relay port reachability self-tests
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
router_skip_or_reachability router_connect_assume_or_reachable \
router_skip_dir_reachability router_connect_assume_dir_reachable
It was generated with --no-verify, so it probably breaks some commit hooks.
The commiter should be sure to fix them up in a subsequent commit.
Part of 33222.
Split "can extend over IPv6" and "has advertised IPv6 ORPort" into
separate functions. They currently have the same result, but this may
change in 33818 with ExtendAllowIPv6Addresses.
Part of 33817.
Refactor circuit_open_connection_for_extend(), splitting out the IP
address choice code into a new function.
Adds unit tests. No behaviour changes in tor.
Part of 33817.
Some tests use IF_BUG_ONCE(), which is fatal when ALL_BUGS_ARE_FATAL,
after the fixes in 33917.
Also run "make autostyle" on these changes.
Part of 33817.
... 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 extend cells with IPv6-only link specifiers.
Warn and fail if both IPv4 and IPv6 are invalid.
Also warn if the IPv4 or IPv6 addresses are unexpectedly internal,
but continue with the valid address.
Part of 33817.
Add fmt_addrport_ap(), a macro that takes a tor_addr_port_t, and uses
it to call fmt_addrport().
Add fmt_addr_family(), a function that returns a string constant
describing the address family.
Utility functions for 33817.
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>
circuit_extend() may be called when a client receives an extend cell,
even if the relay module is disabled.
Log a protocol warning when the relay module is disabled.
Part of 33633.
This is to allow a visual feedback in the logs for operators setting up Onion
Balance so they can confirm they properly configured the instances.
Signed-off-by: David Goulet <dgoulet@torproject.org>
