GitLab

Tracks the total number of established introduction circuit.

Related to #40063
Signed-off-by: David Goulet <dgoulet@torproject.org>

The total number of rendezvous circuit created and the number of established
ones which is a gauge that decreases to keep an updated counter.

Related to #40063
Signed-off-by: David Goulet <dgoulet@torproject.org>

Related to #40063
Signed-off-by: David Goulet <dgoulet@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

At this commit, a new service registers to the module and a store is created.
It also remove itself from the metrics module if it goes away.

In order to hook into the metrics subsystem, this commit attaches the HS
subsystem into the subsystem global list so its get_metrics() call can be
accessible.

HS initialization is still _not_ done through the subsys module as it is
likely require much more testing.

Related to #40063
Signed-off-by: David Goulet <dgoulet@torproject.org>

no actual changes

This is an automated commit, generated by this command:

./scripts/maint/rename_c_identifier.py \
        tor_cert_create tor_cert_create_ed25519

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.

Turns out that the HS DoS defenses parameters were overwritten by the
consensus parameters everytime a new consensus would arrive.

This means that a service operator can still enable the defenses but as soon
as the intro point relay would get a new consensus, they would be overwritten.
And at this commit, the network is entirely disabling DoS defenses.

Fix this by introducing an "explicit" flag that indicate if the
ESTABLISH_INTRO cell DoS extension set those parameters or not. If set, avoid
using the consenus at once.

We are not bumping the protover HSIntro value for this because 0.4.2.x series
is EOL in 1 month and thus 0.4.3.x would be the only series with this bug. We
are confident that a backport and then upgrade path to the latest 0.4.4.x
stable coming up soon is enough to mitigate this problem in the coming months.

It avoids the upgrade path on the service side by keeping the requirement for
protover HSIntro=5.

Fixes #40109
Signed-off-by: David Goulet <dgoulet@torproject.org>

We used to have a single boolean, "FascistFirewall".  Ages ago, in
tickets #17840 and #9067, we added an improved "ReachableAddresses"
mechanism.  It's time to rename related identifiers in the code for
consistency.  This closes #18106.

This is an automated commit, generated by this command:

./scripts/maint/rename_c_identifier.py \
        fascist_firewall_allows_address reachable_addr_allows \
        fascist_firewall_use_ipv6 reachable_addr_use_ipv6 \
        fascist_firewall_prefer_ipv6_impl reachable_addr_prefer_ipv6_impl \
        fascist_firewall_prefer_ipv6_orport reachable_addr_prefer_ipv6_orport \
        fascist_firewall_prefer_ipv6_dirport reachable_addr_prefer_ipv6_dirport \
        fascist_firewall_allows_address_addr reachable_addr_allows_addr \
        fascist_firewall_allows_address_ap reachable_addr_allows_ap \
        fascist_firewall_allows_base reachable_addr_allows_base \
        fascist_firewall_allows_ri_impl reachable_addr_allows_ri_impl \
        fascist_firewall_allows_rs_impl reachable_addr_allows_rs_impl \
        fascist_firewall_allows_rs reachable_addr_allows_rs \
        fascist_firewall_allows_md_impl reachable_addr_allows_md_impl \
        fascist_firewall_allows_node reachable_addr_allows_node \
        fascist_firewall_allows_dir_server reachable_addr_allows_dir_server \
        fascist_firewall_choose_address_impl reachable_addr_choose_impl \
        fascist_firewall_choose_address reachable_addr_choose \
        fascist_firewall_choose_address_base reachable_addr_choose_base \
        fascist_firewall_choose_address_rs reachable_addr_choose_from_rs \
        fascist_firewall_choose_address_ls reachable_addr_choose_from_ls \
        fascist_firewall_choose_address_node reachable_addr_choose_from_node \
        fascist_firewall_choose_address_dir_server reachable_addr_choose_from_dir_server

David Goulet authored Jul 10, 2020 and Nick Mathewson committed Jul 14, 2020

Closes #40033

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.

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

There's nothing wrong with the comment, but the script I'm about to
apply wouldn't like it.

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.

George Kadianakis authored Mar 30, 2020 and Nick Mathewson committed Apr 13, 2020

And also disallow all-zeroes keys from the filesystem; add a test for it too.

George Kadianakis authored Mar 30, 2020 and Nick Mathewson committed Apr 13, 2020

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.

asn: Accidentally left this commit out when merging #32542, so cherry-picking
it now.
Signed-off-by: David Goulet <dgoulet@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

Signed-off-by: David Goulet <dgoulet@torproject.org>

Fixes #33779
Signed-off-by: David Goulet <dgoulet@torproject.org>

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>

It's more natural there since it's runtime state.

The ob_subcreds array was not copied after SIGHUP, and that left the
post-SIGHUP service with a NULL ob_subcreds pointer (until the next descriptor
gets build where we regenerate ob_subcreds in hs_ob_refresh_keys()).

Fixes bug #33762; not in any released tor version.

George Kadianakis authored Mar 11, 2020 and David Goulet committed Mar 30, 2020

Make it LOG_PROTOCOL_WARN and also add the expiration timestamp in there to
ease debugging in the future.