The code here parses the fields from the microdescriptor, including
possible annotations, and stores them into a microdesc_t object.
This commit is almost pure code movement; I recommend using
--color-moved to review it.
This code is logically independent of the rest of the function, and
goes better in its own function.
This is almost purely code movement; I suggest reviewing with
--color-moved.
Our dimap code asserts if you try to add the same key twice; this
can't happen if everything is running smoothly, but it's possible if
you try to start a relay where secret_onion_key_ntor is the same as
secret_onion_key_ntor.old.
Fixes bug 30916; bugfix on 0.2.4.8-alpha when ntor keys were
introduced.
We have code in microdescs_parse_from_string() to record the digests
of microdescriptors that we could not parse. But right now, that
code looks at the md->digest field, which is a bit inelegant, and
will stand in the way of sensible refactoring.
Instead, use a local variable to hold the digest.
When tor is missing descriptors for some primary entry guards, make the
log message less alarming. It's normal for descriptors to expire, as long
as tor fetches new ones soon after.
Fixes bug 31657; bugfix on 0.3.3.1-alpha.
This fixes LTO compilation for Android and -O0 compilation in
general, when --disable-module-dirauth is provided.
Fixes bug 31552; bugfix on 0.4.1.1-alpha.
Rewrite format_node_description() and router_get_verbose_nickname() to
use strlcpy() and strlcat(). The previous implementation used memcpy()
and pointer arithmetic, which was error-prone.
Closes ticket 31545. This is CID 1452819.
These functions are all used to implement the ROUTERSET_type_defn
object, which maps strings to and from routerset_t configuration
variables for the configuration module.
routerset_t has two representations of an empty routerset: NULL, and
a set containing no elements. But some of our config code assumes
that empty routersets are represented as NULL. So let's give it
what it assumes.
Fixes bug 31495. Bugfix on e16b90b88a76; but not in any released
Tor.
The right way to free a config object is now to wrap config_free(),
always. Instead of creating an alternative free function, objects
should provide an alternative clear callback to free any fields that
the configuration manager doesn't manage.
This lets us simplify our code a little, and lets us extend the
confparse.c code to manage additional fields in config_free.
Move everything to its own function in order to better log, document and tests
the introduction point validation process.
Signed-off-by: David Goulet <dgoulet@torproject.org>
When consensus changes, we also need to update the circuit INTRO2 defenses
enabled flag and not only the token bucket.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Remove the public functions returning the HS DoS consensus param or default
values as it is exclusively used internally now.
Rename the param_* variables to consensus_param_* for better code semantic.
Finally, make some private functions available to unit tests.
Signed-off-by: David Goulet <dgoulet@torproject.org>
This commit makes it that the hs_dos.c file only uses the consensus parameter
variables set when we initialize and when the consensus changes.
There is no need to call each time networkstatus_get_param(), which is
expensive, when we want access to a consensus value.
Signed-off-by: David Goulet <dgoulet@torproject.org>
A bit cleaner especially that the next commit(s) will make the consensus param
interface private to hs_dos.c so we expose as little as we can outside of the
subsystem.
Part of #30924
Signed-off-by: David Goulet <dgoulet@torproject.org>
This commit makes tor add the DoS cell extension to the ESTABLISH_INTRO cell
if the defense is enabled on the service side with a torrc option.
Furthermore, the cell extension is only added if the introduction point
supports it. The protover version HSIntro=5 is looked for.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Make it clear that these functions return the consensus param only.
Introduction point can not set those values with a torrc option.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Previously, v3 single onion services failed when all intro nodes were
unreachable via a 1-hop path. Now, we select intros that are only available
via a 3-hop path, and use a 3-hop path to connect to them.
Fixes bug 23507; bugfix on 0.3.2.1-alpha.
Previously, we used a 1-hop path when a single onion rend failed
immediately, and a 3-hop path when it failed after trying to build
a circuit.
Fixes bug 23818; bugfix on 0.3.2.1-alpha.
In case the consensus parameters for the rate/burst changes, we need to update
all already established introduction circuits to the newest value.
This commit introduces a "get all intro circ" function from the HS circuitmap
(v2 and v3) so it can be used by the HS DoS module to go over all circuits and
adjust the INTRODUCE2 token bucket parameters.
Signed-off-by: David Goulet <dgoulet@torproject.org>
This commit add the hs_dos.{c|h} file that has the purpose of having the
anti-DoS code for onion services.
At this commit, it only has one which is a function that decides if an
INTRODUCE2 can be sent on the given introduction service circuit (S<->IP)
using a simple token bucket.
The rate per second is 25 and allowed burst to 200.
Basic defenses on #15516.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Now that we have a reasonable implementation for overriding the
default options for TestingTorNetwork, we don't need to modify
config_var_t structs any more. And therefore, we can have constant
format options, like reasonable people.
It's important to make sure that we don't change a config_mgr_t
after we start using it to make objects, or we could get into
inconsistent states. This feature is the start of a safety
mechanism to prevent this problem.
Remember that our goal in the present refactoring is to allow each
subsystem to declare its own configuration structure and
variables. To do this, each module will get its own
config_format_t, and so we'll want a different structure that wraps
several config_format_t objects. This is a "config_mgr_t".
This shouldn't be possible while Tor is running, but the tests can
hit this code. Rather than force the tests to add a dummy channel
object, let's just tolerate their incompletely built circuits.
There is other code that uses this value, and some of it is
apparently reachable from inside router_dir_info_changed(), which
routerlist_free() apparently calls. (ouch!) This is a minimal fix
to try to resolve the issue without causing other problems.
Fixes bug 31003. I'm calling this a bugfix on 0.1.2.2-alpha, where
the call to router_dir_info_changed() was added to routerlist_free().
Fix add_onion_helper_clientauth() and add_onion_helper_keyarg() to
explicitly call the appropriate control reply abstractions instead of
allocating a string to pass to their callers.
Part of ticket 30889.
Always publish bridge pluggable transport information in the extra info
descriptor, even if ExtraInfoStatistics is 0. This information is
needed by BridgeDB.
Fixes bug 30956; bugfix on 0.4.1.1-alpha.
This will effectively also deny any bridge to be used as a single hop to the
introduction point since bridge do not authenticate like clients.
Fixes#24963
Signed-off-by: David Goulet <dgoulet@torproject.org>
When we consider all circuits in "waiting for guard" state to be promoted to
an "open" state, we were considering all circuits, even the one marked for
close.
This ultiamtely triggers a "circuit_has_opened()" called on the circuit that
is marked for close which then leads to possible undesirable behaviors within
a subsystem.
For instance, the HS subsystem would be unable to find the authentication key
of the introduction point circuit leading to a BUG() warning and a duplicate
mark for close on the circuit.
This commit also adds a unit test to make sure we never select marked for
close circuits when upgrading its guard state from waiting for guard to open.
Fixes#30871
Signed-off-by: David Goulet <dgoulet@torproject.org>
When we consider all circuits in "waiting for guard" state to be promoted to
an "open" state, we were considering all circuits, even the one marked for
close.
This ultiamtely triggers a "circuit_has_opened()" called on the circuit that
is marked for close which then leads to possible undesirable behaviors within
a subsystem.
For instance, the HS subsystem would be unable to find the authentication key
of the introduction point circuit leading to a BUG() warning and a duplicate
mark for close on the circuit.
This commit also adds a unit test to make sure we never select marked for
close circuits when upgrading its guard state from waiting for guard to open.
Fixes#30871
Signed-off-by: David Goulet <dgoulet@torproject.org>
When we consider all circuits in "waiting for guard" state to be promoted to
an "open" state, we were considering all circuits, even the one marked for
close.
This ultiamtely triggers a "circuit_has_opened()" called on the circuit that
is marked for close which then leads to possible undesirable behaviors within
a subsystem.
For instance, the HS subsystem would be unable to find the authentication key
of the introduction point circuit leading to a BUG() warning and a duplicate
mark for close on the circuit.
This commit also adds a unit test to make sure we never select marked for
close circuits when upgrading its guard state from waiting for guard to open.
Fixes#30871
Signed-off-by: David Goulet <dgoulet@torproject.org>
