We've done a lot to improve our internal APIs since we wrote this
code, and it shows. We can just use a buf_t to build up the
bandwidth lines, and save a bunch of stack fiddling.
Additionally, we can use a function to format a single line, and
thereby get rid of the cheezy pattern that does
for (i=0;i<n;++i) {
switch (i) {
...
}
...
}
Unclear but that somehow failed on Windows once (?) according to ticket #33768
but we are not seeing that failure.
Nevertheless, add a simple unit test.
Closes#33768
Signed-off-by: David Goulet <dgoulet@torproject.org>
This will make sure that we always properly initialize the cache by the exact
size all the time.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
When receiving an introduction NACK, the client either decides to close or
re-extend the circuit to another intro point.
In order to do this, the service descriptor needs to exists but it is possible
that it gets removed from the cache between the establishement of the
introduction circuit and the reception of the (N)ACK.
For that reason, the BUG(desc == NULL) is removed because it is a possible
normal use case. Tor recovers gracefully already.
Fixes#34087
Signed-off-by: David Goulet <dgoulet@torproject.org>
It now uses the 'goto err' pattern, instead of the fatal_unreached()
pattern. The latter pattern is usually used when there is a loop, but there is
no loop in this function so it can be simplified easily.
This commit modifies the behavior of `parse_extended_address` in such a way
that if it fails, it will always return a `BAD_HOSTNAME` value, which is then
used to return the 0xF6 extended error code. This way, in any case that is
not a valid v2 address, we return the 0xF6 error code, which is the expected
behavior.
Signed-off-by: David Goulet <dgoulet@torproject.org>
We do look at the address but with this we also look if the identity digest of
the relay suggesting us an address is a trusted source.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
This reverts commit bf2a399fc0.
Don't set by default the prefer IPv6 feature on client ports because it breaks
the torsocks use case. The SOCKS resolve command is lacking a mechanism to ask
for a specific address family (v4 or v6) thus prioritizing IPv6 when an IPv4
address is asked on the resolve SOCKS interface resulting in a failure.
Tor Browser explicitly set PreferIPv6 so this should not affect the majority
of our users.
Closes#33796
Signed-off-by: David Goulet <dgoulet@torproject.org>
If no Address statement are found in the configuration file, attempt to learn
our address by looking at the ORPort address if any. Specifying an address is
optional so if we can't find one, it is fine, we move on to the next discovery
mechanism.
Note that specifying a hostname on the ORPort is not yet supported at this
commit.
Closes#33236
Signed-off-by: David Goulet <dgoulet@torproject.org>
Attempt to learn our address from the NETINFO cell.
At this commit, the address won't be used in the descriptor if selected. Next
commit will make it happen.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
This behaves like router_new_address_suggestion() but differs in couple of
ways:
1. It takes a tor_addr_t instead of an address string and supports both
AF_INET and AF_INET6.
2. It does _not_ use the last_guessed_ip local cache and instead only relies
on the last resolved address cache in resolve_addr.c
It is not used at this commit. This function is made to process a suggested
address found in a NETINFO cell exactly like router_new_address_suggestion()
does with the address a directory suggests us.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
Rename the static function update_resolved_cache() to resolved_addr_set_last()
and make it public.
We are about to use it in order to record any suggested address from a NETINFO
cell.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
In the spirit of reducing technical debt. Move code that marks a channel as a
client into its own function and document it properly.
No behavior change, only code movement.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
In order to process a NETINFO cell, the OR connection needs to go through a
series of validation else we don't process the cell.
Move those into its own function in and improve documentation.
This is an attempt at reducing technical debt of the rather large and
complicated channel_tls_process_netinfo_cell() function.
Related to #40022
Signed-off-by: David Goulet <dgoulet@torproject.org>
This patch changes our bits-to-bytes conversion logic in the NSS
implementation of `tor_tls_cert_matches_key()` from using (x >> 3) to
((x + 7) >> 3) since DER bit-strings are allowed to contain a number of
bits that is not a multiple of 8.
Additionally, we add a comment on why we cannot use the
`DER_ConvertBitString()` macro from NSS, as we would potentially apply
the bits-to-bytes conversion logic twice, which would lead to an
insignificant amount of bytes being compared in
`SECITEM_ItemsAreEqual()` and thus turn the logic into being a
prefix match instead of a full match.
The `DER_ConvertBitString()` macro is defined in NSS as:
/*
** Macro to convert der decoded bit string into a decoded octet
** string. All it needs to do is fiddle with the length code.
*/
#define DER_ConvertBitString(item) \
{ \
(item)->len = ((item)->len + 7) >> 3; \
}
Thanks to Taylor Yu for spotting this problem.
This patch is part of the fix for TROVE-2020-001.
See: https://bugs.torproject.org/33119
We add constness to `peer_info_orig_len` and `cert_info_orig_len` in
`tor_tls_cert_matches_key` to ensure that we don't accidentally alter
the variables.
This patch is part of the fix for TROVE-2020-001.
See: https://bugs.torproject.org/33119
This patch fixes an out-of-bound memory read in
`tor_tls_cert_matches_key()` when Tor is compiled to use Mozilla's NSS
instead of OpenSSL.
The NSS library stores some length fields in bits instead of bytes, but
the comparison function found in `SECITEM_ItemsAreEqual()` needs the
length to be encoded in bytes. This means that for a 140-byte,
DER-encoded, SubjectPublicKeyInfo struct (with a 1024-bit RSA public key
in it), we would ask `SECITEM_ItemsAreEqual()` to compare the first 1120
bytes instead of 140 (140bytes * 8bits = 1120bits).
This patch fixes the issue by converting from bits to bytes before
calling `SECITEM_ItemsAreEqual()` and convert the `len`-fields back to
bits before we leave the function.
This patch is part of the fix for TROVE-2020-001.
See: https://bugs.torproject.org/33119
This patch lifts the `tor_tls_cert_matches_key()` tests out of the
OpenSSL specific TLS test suite and moves it into the generic TLS test
suite that is executed for both OpenSSL and NSS.
This patch is largely a code movement, but we had to rewrite parts of
the test to avoid using OpenSSL specific data-types (such as `X509 *`)
and replace it with the generic Tor abstraction type
(`tor_x509_cert_impl_t *`).
This patch is part of the fix for TROVE-2020-001.
See: https://bugs.torproject.org/33119
