ExitPolicyRejectPrivate now rejects more local addresses by default:
* the relay's published IPv6 address (if any), and
* any publicly routable IPv4 or IPv6 addresses on any local interfaces.
This resolves a security issue for IPv6 Exits and multihomed Exits that
trust connections originating from localhost.
Resolves ticket 17027. Patch by "teor".
Patch on 42b8fb5a15 (11 Nov 2007), released in 0.2.0.11-alpha.
In previous versions of Tor, ExitPolicy accept6/reject6 * produced
policy entries for IPv4 and IPv6 wildcard addresses.
To reduce operator confusion, change accept6/reject6 * to only produce
an IPv6 wildcard address.
Resolves bug #16069.
Patch on 2eb7eafc9d and a96c0affcb (25 Oct 2012),
released in 0.2.4.7-alpha.
Tor now warns when ExitPolicy lines occur after accept/reject *:*
or variants. These lines are redundant, and were always ignored.
Partial fix for ticket 16069. Patch by "teor".
Patch on 2eb7eafc9d and a96c0affcb (25 Oct 2012),
released in 0.2.4.7-alpha.
When parsing torrc ExitPolicies, we now warn if:
* an IPv4 address is used on an accept6 or reject6 line. The line is
ignored, but the rest of the policy items in the list are used.
(accept/reject continue to allow both IPv4 and IPv6 addresses in torrcs.)
* a "private" address alias is used on an accept6 or reject6 line.
The line filters both IPv4 and IPv6 private addresses, disregarding
the 6 in accept6/reject6.
When parsing torrc ExitPolicies, we now issue an info-level message:
* when expanding an accept/reject * line to include both IPv4 and IPv6
wildcard addresses.
In each instance, usage advice is provided to avoid the message.
Partial fix for ticket 16069. Patch by "teor".
Patch on 2eb7eafc9d and a96c0affcb (25 Oct 2012),
released in 0.2.4.7-alpha.
Add get_interface_address[6]_list by refactoring
get_interface_address6. Add unit tests for new and existing functions.
Preparation for ticket 17027. Patch by "teor".
Patch on 42b8fb5a15 (11 Nov 2007), released in 0.2.0.11-alpha.
This controls the circuit dirtyness reset behavior added for Tor
Browser's user experience fix (#15482). Unlike previous iterations
of this patch, the tunable actually works, and is documented.
(These inputs are possible when Shadow starts the world at time_t 0,
and breaks our assumption that Tor didn't exist in the 1970s.)
Fixes regression introduced in 241e6b09. Fixes#16980.
When this is set, and Tor is running as a relay, it will not
generate or load its secret identity key. You can manage the secret
identity key with --keygen. Implements ticket 16944.
In a nutshell, since a circuit can not exit at its entry point, it's very
easy for an attacker to find the hidden service guard if only one EntryNodes
is specified since for that guard, the HS will refuse to build a rendezvous
circuit to it.
For now, the best solution is to stop tor to allow a single EntryNodes for
an hidden service.
Fixes#14917
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Make "bridges+hs" the default test network. This tests almost all
tor functionality during make test-network, while allowing tests
to succeed on non-IPv6 systems.
Requires chutney commit 396da92 in test-network-bridges-hs.
Closes tickets 16945 (tor), 16946 (chutney) . Patches by "teor".
Previously we'd put these strings right on the controllers'
outbufs. But this could cause some trouble, for these reasons:
1) Calling the network stack directly here would make a huge portion
of our networking code (from which so much of the rest of Tor is
reachable) reachable from everything that potentially generated
controller events.
2) Since _some_ events (EVENT_ERR for instance) would cause us to
call connection_flush(), every control_event_* function would
appear to be able to reach even _more_ of the network stack in
our cllgraph.
3) Every time we generated an event, we'd have to walk the whole
connection list, which isn't exactly fast.
This is an attempt to break down the "blob" described in
http://archives.seul.org/tor/dev/Mar-2015/msg00197.html -- the set of
functions from which nearly all the other functions in Tor are
reachable.
Closes ticket 16695.
"option to prevent guard,exit,hsdir flag assignment"
"A node will never receive the corresponding flag unless
that node is specified in the
TestingDirAuthVote{Exit,Guard,HSDir} list, regardless of
its uptime, bandwidth, exit policy, or DirPort".
Patch modified by "teor": VoteOnHidServDirectoriesV2
is now obsolete, so TestingDirAuthVoteHSDir always
votes on HSDirs.
Closes ticket 14882. Patch by "robgjansen".
Commit message and changes file by "teor"
with quotes from "robgjansen".
This probably requires the user to manually set CFLAGS, but should
result in a net gain on 32 bit x86. Enabling SSE2 support would be
possible on x86_64, but will result in slower performance.
Implements feature #16535.
Instead of having it call update_all_descriptor_downloads and
update_networkstatus_downloads directly, we can have it cause them to
get rescheduled and called from run_scheduled_events.
Closes ticket 16789.
The code was always in our Ed25519 wrappers, so enable it when using
the ed25519-donna backend, and deal with the mocking related
crypto_rand silliness.
Implements feature 16533.
When we removed Running/Valid checks from Fast and Stable in 8712, I
removed them from HSDir too, which apparently wasn't a good idea.
Reverts part of a65e835800. Fixes bug 16524. Bugfix
on 0.2.7.2-alpha.
microdesc_free_() called get_microdesc_cache(), which had the fun
side-effect of potentially reloading the whole cache from disk.
Replace it with a variant that doesn't.
If setrlimit() failed, max_out wasn't set in set_max_file_descriptors()
ending in a state where we don't use ULIMIT_BUFFER for things like tor
private key files.
Also fix the set_max_file_descriptors() documentation.
Fixes#16274
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
According to POSIX, the mutex must be locked by the thread calling the signal
functions to ensure predictable scheduling behavior.
Found the issue using Helgrind which gave the warning `dubious: associated lock
is not held by any thread`.
The control port was using set_max_file_descriptors() with a limit set to 0
to query the number of maximum socket Tor can use. With the recent changes
to that function, a check was introduced to make sure a user can not set a
value below the amount we reserved for non socket.
This commit adds get_max_sockets() that returns the value of max_sockets so
we can stop using that "setter" function to get the current value.
Finally, the dead code is removed that is the code that checked for limit
equal to 0. From now on, set_max_file_descriptors() should never be used
with a limit set to 0 for a valid use case.
Fixes#16697
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
URI syntax (and DNS syntax) allows for a single trailing `.` to
explicitly distinguish between a relative and absolute
(fully-qualified) domain name. While this is redundant in that RFC 1928
DOMAINNAME addresses are *always* fully-qualified, certain clients
blindly pass the trailing `.` along in the request.
Fixes bug 16674; bugfix on 0.2.6.2-alpha.
1) We already require C99.
2) This allows us to support MSVC again (thanks to Gisle Vanem for
this part)
3) This change allows us to dump some rotten old compatibility code
from log.c
It did a good idea, but the code-quality of libupnpc and libnatpnp
is so dodgy that I'm not really comfortable including them alongside
Tor proper. Instead, we'll recommend that people do the pure-go
reimplementation instead. Closes ticket 13338.
