| Age | Commit message (Collapse) | Author |
|---|
|
tor only marks a channel as 'open' once the TLS and OR handshakes have both
completed, and normal "client" (ORPort) DoS protection is not enabled until
the channel becomes open. This patch adds an additional earlier initialization
path for DoS protection on incoming TLS connections.
This leaves the existing dos_new_client_conn() call sites intact, but adds a
guard against multiple-initialization using the existing
tracked_for_dos_mitigation flag. Other types of channels shouldn't be affected
by this patch.
|
|
Fixes #40743
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
Fortunately, our tor_free() is setting the variable to NULL after so we were
in a situation where NULL was always used instead of the transport name.
This first appeared in 894ff2dc8422cb86312c512698acd76476224f87 and results in
basically no bridge with a transport being able to use DoS defenses.
Fixes #40345
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
This is unfortunately massive but both functionalities were extremely
intertwined and it would have required us to actually change the HSv2 code in
order to be able to split this into multiple commits.
After this commit, there are still artefacts of v2 in the code but there is no
more support for service, intro point and HSDir.
The v2 support for rendezvous circuit is still available since that code is
the same for the v3 and we will leave it in so if a client is able to
rendezvous on v2 then it can still transfer traffic. Once the entire network
has moved away from v2, we can remove v2 rendezvous point support.
Related to #40266
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
The time diffs were misleading and unpretty when a channel has not seen
a client, a cell or transmitted a cell.
This commit adds some prettier messages.
Fixes #40182
|
|
Typos found with codespell.
Please keep in mind that this should have impact on actual code
and must be carefully evaluated:
src/core/or/lttng_circuit.inc
- ctf_enum_value("CONTROLER", CIRCUIT_PURPOSE_CONTROLLER)
+ ctf_enum_value("CONTROLLER", CIRCUIT_PURPOSE_CONTROLLER)
|
|
|
|
|
|
|
|
|
|
Also, explain why it's relevant for bootstrapping.
This is a comments-only patch.
|
|
|
|
|
|
|
|
We set this flag if we've launched the connection in order to
satisfy an origin circuit, or when we decide the connection _would_
satisfy an origin circuit. These are the only or_connections we
want to consider for bootstrapping: other or_connections are opened
because of client EXTEND requests, and they may succeed or fail
because of the clients' confusion or misconfiguration.
Closes #25061.
|
|
|
|
Previously, we would treat *any* incoming circuit on a non-local
channel as meaning that our ORPort was reachable. With this patch,
we make sure that the address that the peer _says_ we have is the
same as the one we're trying to advertise right now.
Closes 20165. Bugfix on 4f5192b2803c706 in 0.1.0.1-rc, when
reachability self-tests were first introduced.
|
|
|
|
Fixes bug 40080. Bugfix on 0.2.7.2-alpha.
|
|
Resolves conflicts:
src/core/or/channel.c
src/test/test_channel.c
|
|
This function once served to let circuits continue to be built over
version-1 link connections. But such connections are long-obsolete,
and it's time to remove this check.
Closes #40081.
|
|
|
|
|
|
Previously we tolerated up to 1.5 connections for every relay we
were connected to, and didn't warn if we had fewer than 5
connections total.
Now we tolerate up to 1.5 connections per relay, and up to 4
connections per authority, and we don't warn at all when we have
fewer than 25 connections total.
Fixes bug 33880, which seems to have been provoked by our #17592
change in 0.3.5.
|
|
|
|
Since we can list the real address and the canonical one in a
human-readable format we don't need to pick.
|
|
Now that we've clarified that these functions only need to describe
the peer in a human-readable way, we can have them delegate to
connection_describe_peer().
|
|
This mode was only used in one place, and it caused a dangerous
mingling of functionality. The method is supposed to _describe_ the
peer's address, not give its actual address. We already had a
function to get the actual address.
|
|
* We no longer call this an optional method
* We document that it returns the real address, not a canonical one.
* We have it try harder if the real address hasn't been set yet.
|
|
|
|
(There is no reason that looking up the address of a channel should
ever change it.)
|
|
Refactor channel_matches_target_addr_for_extend() to return a boolean
result.
Part of 33817.
|
|
Search for existing connections using the remote IPv4 and IPv6
addresses.
Part of 33817.
|
|
It isn't used outside channel.c.
Part of 33817.
|
|
|
|
|
|
|
|
Preparation for testing circuit_extend().
Part of 33633.
|
|
Explain what the function does now.
Fix some typos.
Part of 33633.
|
|
|
|
|
|
|
|
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>
|
|
|
|
|
