| Age | Commit message (Collapse) | Author |
|---|
|
Part of 33817.
|
|
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
tor_addr_get_ipv6_bytes tor_addr_copy_ipv6_bytes
|
|
|
|
Flatten the logic in circuit_choose_ip_ap_for_extend().
Part of 33817.
|
|
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.
|
|
Add IPv4-only and IPv6-only tests for
circuit_open_connection_for_extend().
Part of 33817.
|
|
When an EXTEND2 cell has an IPv4 and an IPv6 address, choose one of them
uniformly at random.
Part of 33817.
|
|
Re-use the newly created extend_info to launch the connection in
circuit_open_connection_for_extend().
No behaviour change.
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.
|
|
Search for existing connections using the remote IPv4 and IPv6
addresses.
Part of 33817.
|
|
Part of 33817.
|
|
It isn't used outside channel.c.
Part of 33817.
|
|
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.
|
|
Disable SafeLogging for some extend tests, so we can check the actual
addresses.
Part of 33817.
|
|
Always log the address family in extend protocol warnings.
If SafeLogging is 0, also log the address and port.
Diagnostics for 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.
|
|
|
|
No behaviour change.
Part of 33817.
|
|
tor_addr_port_is_valid_ap(ap, 0) checks if the address or port are
zero, exactly like the previous code.
Preparation for 33817.
|
|
Check for invalid zero IPv4 addresses and ports, when sending and
receiving extend cells.
Fixes bug 33900; bugfix on 0.2.4.8-alpha.
|
|
Part of 33901.
|
|
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.
|
|
|
|
|
|
Part of 33817.
|
|
Clarify the comments in channel_tls_matches_target_method(), and make
it clear that the attack is a covert attack.
|
|
|
|
|
|
Stop truncating IPv6 addresses and ports in channel and connection logs.
Fixes bug 33918; bugfix on 0.2.4.4-alpha.
|
|
|
|
|
|
Lock-in improvements.
Accept some small function size increases.
Allow a small amount of extra file size increase.
|
|
Fix a typo, and say "v3 (and later) handshake".
Comment-only change.
|
|
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.
|
|
Remove the unused function prototype for connection_or_get_for_extend().
There is no function implementation.
Part of 33817.
|
|
"ours" to avoid version bump.
|
|
|
|
|
|
|
|
|
|
And also disallow all-zeroes keys from the filesystem; add a test for it too.
|
|
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.
|
|
|
|
|
|
"ours" to avoid version bump
|
|
|
|
|
