They are no longer "all" digests, but only the "common" digests.
Part of 17795.
This is an automated patch I made with a couple of perl one-liners:
perl -i -pe 's/crypto_digest_all/crypto_common_digests/g;' src/*/*.[ch]
perl -i -pe 's/\bdigests_t\b/common_digests_t/g;' src/*/*.[ch]
Closes ticket 18242.
The rationale here is that I like having coverage on by default in my
own working directory, but I always want assertions turned on unless
I'm doing branch coverage specifically.
We use sensible parameters taken from common sources, and no longer
have dynamic DH groups as an option, but it feels prudent to have
OpenSSL validate p and g at initialization time.
We've never actually tested this support, and we should probably assume
it's broken.
To the best of my knowledge, only OpenVMS has this, and even on
OpenVMS it's a compile-time option to disable it. And I don't think
we build on openvms anyway. (Everybody else seems to be working
around the 2038 problem by using a 64-bit time_t, which won't expire
for roughly 292 billion years.)
Closes ticket 18184.
node_get_all_orports and router_get_all_orports incorrectly used or_port
with IPv6 addresses. They now use ipv6_orport.
Also refactor and remove duplicated code.
This closes bug 18162; bugfix on a45b131590, which fixed a related
issue long ago.
In addition to the #18162 issues, this fixes a signed integer overflow
in smarltist_add_all(), which is probably not so great either.
Avoid using a pronoun where it makes comments unclear.
Avoid using gender for things that don't have it.
Avoid assigning gender to people unnecessarily.
Check size argument to memwipe() for underflow.
Closes bug #18089. Reported by "gk", patch by "teor".
Bugfix on 0.2.3.25 and 0.2.4.6-alpha (#7352),
commit 49dd5ef3 on 7 Nov 2012.
LibreSSL doesn't use OpenSSL_version (it uses the older SSLeay_version
API), but it reports a major version number as 2 in
OPENSSL_VERSION_NUMBER. Instead of fudging the version check, for now,
let's just check if we're using LibreSSL by checking the version number
macro exists, and use compatibility defines unconditionally when we
detect LibreSSL.
When _list() is called with AF_UNSPEC family and fails to enumerate
network interfaces using platform specific API, have it call
_hack() twice to find out IPv4 and/or IPv6 address of a machine Tor
instance is running on. This is correct way to handle this case
because _hack() can only be called with AF_INET and AF_INET6 and
does not support any other address family.
OpenSSL doesn't use them, and fwict they were never called. If some
version of openssl *does* start using them, we should test them before
we turn them back on.
See ticket 17926
This is an eXtendable-Output Function with the following claimed
security strengths against *all* adversaries:
Collision: min(d/2, 256)
Preimage: >= min(d, 256)
2nd Preimage: min(d, 256)
where d is the amount of output used, in bits.
* DIGEST_SHA3_[256,512] added as supported algorithms, which do
exactly what is said on the tin.
* test/bench now benchmarks all of the supported digest algorithms,
so it's possible to see just how slow SHA-3 is, though the message
sizes could probably use tweaking since this is very dependent on
the message size vs the SHA-3 rate.
* The option is now KeepBindCapabilities
* We now warn if the user specifically asked for KeepBindCapabilities
and we can't deliver.
* The unit tests are willing to start.
* Fewer unused-variable warnings.
* More documentation, fewer misspellings.
Prop210: Add attempt-based connection schedules
Existing tor schedules increment the schedule position on failure,
then retry the connection after the scheduled time.
To make multiple simultaneous connections, we need to increment the
schedule position when making each attempt, then retry a (potentially
simultaneous) connection after the scheduled time.
(Also change find_dl_schedule_and_len to find_dl_schedule, as it no
longer takes or returns len.)
Prop210: Add multiple simultaneous consensus downloads for clients
Make connections on TestingClientBootstrapConsensus*DownloadSchedule,
incrementing the schedule each time the client attempts to connect.
Check if the number of downloads is less than
TestingClientBootstrapConsensusMaxInProgressTries before trying any
more connections.
On FreeBSD backtrace(3) uses size_t instead of int (as glibc does). This
causes integer precision loss errors when we used int to store its
results.
The issue is fixed by using size_t to store the results of backtrace(3).
The manual page of glibc does not mention that backtrace(3) returns
negative values. Therefore, no unsigned integer wrapping occurs when its
result is stored in an unsigned data type.
Consistently ignore multicast addresses when automatically
generating reject private exit policies.
Closes ticket 17763. Bug fix on 10a6390deb,
not in any released version of Tor. Patch by "teor".
These functions must really never fail; so have crypto_rand() assert
that it's working okay, and have crypto_seed_rng() demand that
callers check its return value. Also have crypto_seed_rng() check
RAND_status() before returning.
(But it won't work on some systems without IPv4/IPv6 localhost
(some BSD jails) by design, to avoid creating sockets on routable
IP addresses. However, those systems likely have the AF_UNIX socketpair,
which tor prefers.)
Fixes bug #17638; bugfix on a very early tor version,
earlier than 22dba27d8d (23 Nov 2004) / svn:r2943.
Patch by "teor".
Without this check, we potentially look up to 3 characters before
the start of a malloc'd segment, which could provoke a crash under
certain (weird afaik) circumstances.
Fixes 17404; bugfix on 0.2.6.3-alpha.
Since 11150 removed client-side support for renegotiation, we no
longer need to make sure we have an openssl/TLSvX combination that
supports it (client-side)
Now that x509_get_not{Before,After} are functions in OpenSSL 1.1
(not yet releasesd), we need to define a variant that takes a const
pointer to X509 and returns a const pointer to ASN1_time.
Part of 17237. I'm not convinced this is an openssl bug or a tor
bug. It might be just one of those things.
When logging to syslog, allow a tag to be added to the syslog identity
("Tor"), i.e. the string prepended to every log message. The tag can be
configured by setting SyslogIdentityTag and defaults to none. Setting
it to "foo" will cause logs to be tagged as "Tor-foo". Closes: #17194.
Ensure that either a valid address is returned in address pointers,
or that the address data is zeroed on error.
Ensure that free_interface_address6_list handles NULL lists.
Add unit tests for get_interface_address* failure cases.
Fixes bug #17173.
Patch by fk/teor, not in any released version of tor.
... that was removed by 31eb486c46 which first appeared in
0.2.7.3-rc.
If tor is running in a ElectroBSD (or FreeBSD) jail it can't
get any IP addresses that aren't assigned to the jail by
looking at the interfaces and (by design) the
get_interface_address6_via_udp_socket_hack() fallback doesn't
work either.
The missing return code check resulted in tor_addr_is_internal()
complaining about a "non-IP address of type 49", due to reading
uninitialised memory.
Fixes#17173.
src/test/test_policy.c:
Merged calls to policies_parse_exit_policy by adding additional arguments.
fixup to remaining instance of ~EXIT_POLICY_IPV6_ENABLED.
Compacting logic test now produces previous list length of 4, corrected this.
src/config/torrc.sample.in:
src/config/torrc.minimal.in-staging:
Merged torrc modification dates in favour of latest.
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.
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.
(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.
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.
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 base64 and base32 functions used to be in crypto.c;
crypto_format.h had no header; some general-purpose functions were in
crypto_curve25519.c.
This patch makes a {crypto,util}_format.[ch], and puts more functions
there. Small modules are beautiful!
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
The runtime sanity checking is slightly different from the optimized
basepoint stuff in that it uses a given implementation's self tests if
available, and checks if signing/verification works with a test vector
from the IETF EdDSA draft.
The unit tests include a new testcase that will fuzz donna against ref0,
including the blinding and curve25519 key conversion routines. If this
is something that should be done at runtime (No?), the code can be
stolen from there.
Note: Integrating batch verification is not done yet.
Integration work scavanged from nickm's `ticket8897_9663_v2` branch,
with minor modifications. Tor will still sanity check the output but
now also attempts to catch extreme breakage by spot checking the
optimized implementation vs known values from the NaCl documentation.
Implements feature 9663.
Integrate ed25519-donna into the build process, and provide an
interface that matches the `ref10` code. Apart from the blinding and
Curve25519 key conversion, this functions as a drop-in replacement for
ref10 (verified by modifying crypto_ed25519.c).
Tests pass, and the benchmarks claim it is quite a bit faster, however
actually using the code requires additional integration work.
RFC 952 is approximately 30 years old, and people are failing to comply,
by serving A records with '_' as part of the hostname. Since relaxing
the check is a QOL improvement for our userbase, relax the check to
allow such abominations as destinations, especially since there are
likely to be other similarly misconfigured domains out there.
clang complains that the address of struct member in an assert in
SSL_SESSION_get_master_key is always non-NULL.
Instead, check each pointer argument is non-NULL before using it.
Fix on f90a704f12 from 27 May 2015, not in any released version of tor.
Unused variable warnings were still generated under some versions of OpenSSL.
Instead, make sure all variables are used under all versions.
Fix on 496df21c89, not in any released version of tor.
An earlier version of these tests was broken; now they're a nicer,
more robust, more black-box set of tests. The key is to have each
test check a handshake message that is wrong in _one_ way.
When there are annotations on a router descriptor, the
ed25519-identity element won't be at position 0 or 1; it will be at
router+1 or router-1.
This patch also adds a missing smartlist function to search a list for
an item with a particular pointer.
Routers now use TAP and ntor onion keys to sign their identity keys,
and put these signatures in their descriptors. That allows other
parties to be confident that the onion keys are indeed controlled by
the router that generated the descriptor.
For prop220, we have a new ed25519 certificate type. This patch
implements the code to create, parse, and validate those, along with
code for routers to maintain their own sets of certificates and
keys. (Some parts of master identity key encryption are done, but
the implementation of that isn't finished)
If the OpenSSL team accepts my patch to add an
SSL_get_client_ciphers function, this patch will make Tor use it
when available, thereby working better with openssl 1.1.
We previously used this function instead of SSL_set_cipher_list() to
set up a stack of client SSL_CIPHERs for these reasons:
A) In order to force a particular order of the results.
B) In order to be able to include dummy entries for ciphers that
this build of openssl did not support, so we could impersonate
Firefox harder.
But we no longer do B, since we merged proposal 198 and stopped
lying about what ciphers we know.
And A was actually pointless, since I had misread the implementation
of SSL_set_cipher_list(). It _does_ do some internal sorting, but
that is pre-sorting on the master list of ciphers, not sorting on
the user's preferred order.
As OpenSSL >= 1.0.0 is now required, ECDHE is now mandatory. The group
has to be validated at runtime, because of RedHat lawyers (P224 support
is entirely missing in the OpenSSL RPM, but P256 is present and is the
default).
Resolves ticket #16140.
The key here is to never touch ssl->cipher_list directly, but only
via SSL_get_ciphers(). But it's not so simple.
See, if there is no specialized cipher_list on the SSL object,
SSL_get_ciphers returns the cipher_list on the SSL_CTX. But we sure
don't want to modify that one! So we need to use
SSL_set_cipher_list first to make sure that we really have a cipher
list on the SSL object.
This field was only needed to work with the now-long-gone (I hope,
except for some horrible apples) openssl 0.9.8l; if your headers say
you have openssl 1.1, you won't even need it.
OpenSSL 1.1.0 must be built with "enable-deprecated", and compiled with
`OPENSSL_USE_DEPRECATED` for this to work, so instead, use the newer
routine as appropriate.
Use it in the sample_laplace_distribution function to make sure we return
the correct converted value after math operations are done on the input
values.
Thanks to Yawning for proposing a solution.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
- Rewrite changes file.
- Avoid float comparison with == and use <= instead.
- Add teor's tor_llround(trunc(...)) back to silence clang warnings.
- Replace tt_assert() with tt_i64_op() and friends.
- Fix whitespace and a comment.
Consistently check for overflow in round_*_to_next_multiple_of.
Check all round_*_to_next_multiple_of functions with expected values.
Check all round_*_to_next_multiple_of functions with maximal values.
Related to HS stats in #13192.
Avoid division by zero.
Avoid taking the log of zero.
Silence clang type conversion warnings using round and trunc.
The existing values returned by the laplace functions do not change.
Add tests for laplace edge cases.
These changes pass the existing unit tests without modification.
Related to HS stats in #13192.
These commands allow for the creation and management of ephemeral
Onion ("Hidden") services that are either bound to the lifetime of
the originating control connection, or optionally the lifetime of
the tor instance.
Implements #6411.
Incidently, this fixes a bug where the maximum value was never used when
only using crypto_rand_int(). For instance this example below in
rendservice.c never gets to INTRO_POINT_LIFETIME_MAX_SECONDS.
int intro_point_lifetime_seconds =
INTRO_POINT_LIFETIME_MIN_SECONDS +
crypto_rand_int(INTRO_POINT_LIFETIME_MAX_SECONDS -
INTRO_POINT_LIFETIME_MIN_SECONDS);
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
This uses a Linux-ism to attempt to always clean up background processes
if possible. Note that it is not a catch-all, in that executables with
suid/sgid or elevated capabilities will have the prctl() attribute
stripped as part of the execve().
Resolves ticket 15471.
Background processes spawned by Tor now will have a valid stdin.
Pluggable transports can detect this behavior with the aformentioned
enviornment variable, and exit if stdin ever gets closed.
On clang (and elsewhere?) __PRETTY_FUNCTION__ includes parenthesized
argument lists. This is clever, but it makes our old "%s(): " format
look funny.
This is a fix on 0957ffeb, aka svn:r288. Fixes bug 15269.
Remove src/or/or_sha1.i and src/common/common_sha1.i on `make clean` and remove
the temporary micro-revision file when its no longer needed.
Additional changes;
- show a message when generating the micro-revision file.
- add the temporary micro revision file to the list of files to be removed on
`make clean` just in case.
- fix indentation of the make rule to improve readability.
When calling pthread_attr_setdetachstate, we were using 1 as the
argument. But the pthreads documentation says that you have to say
PTHREAD_CREATE_DETACH, which on Solaris is apparently 0x40. Calling
pthread_attr_setdetachstate with 1 crashes on Solaris with FLTBOUNDS.
(Because we're so late in the release cycle, I made the code define
PTHREAD_CREATE_DETACHED if it doesn't exist, so we aren't likely to
break any other platforms.)
This bug was introduced when we made threading mandatory in
0.2.6.1-alpha; previously, we had force-disabled threading on
Solaris. See #9495 discussion.
__libc_message() tries to open /dev/tty with O_RDWR, but the sandbox
catches that and calls it a crash. Instead, I'm making the sandbox
setenv LIBC_FATAL_STDERR_, so that glibc uses stderr instead.
Fix for 14759, bugfix on 0.2.5.1-alpha
They have been off-by-default since 0.2.5 and nobody has complained. :)
Also remove the buf_shrink() function, which hasn't done anything
since we first stopped using contiguous memory to store buffers.
Closes ticket 14848.
This both fixes the problem, and ensures that forgetting to update
domain_list in the future will trigger the bug codepath instead of
a NULL pointer deref.
If the returned value of read/recv is 0 (meaning EOF), we'll end up in an
infinite loop (active wait) until something is written on the pipe which is
not really what we want here especially because those functions are called
from the main thread.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Introduces two new circuit status name-value parameters: SOCKS_USERNAME
and SOCKS_PASSWORD. Values are enclosing in quotes and unusual characters
are escaped.
Example:
650 CIRC 5 EXTENDED [...] SOCKS_USERNAME="my_username" SOCKS_PASSWORD="my_password"
This is to avoid that the pthread_cond_timedwait() is not affected by time
adjustment which could make the waiting period very long or very short which
is not what we want in any cases.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Previously I used one queue per worker; now I use one queue for
everyone. The "broadcast" code is gone, replaced with an idempotent
'update' operation.
This way we can use the linux eventfd extension where available.
Using EVFILT_USER on the BSDs will be a teeny bit trickier, and will
require libevent hacking.
Also, re-enable the #if'd out condition-variable code.
Work queues are going to make us hack on all of this stuff a bit more
closely, so it might not be a terrible idea to make it easier to hack.
When tor is configured with --enable-bufferevents, the build fails
because compat_libevent.h makes use of the macro MOCK_DECL() which
is defined in testsupport.h, but not included. We add the include.
apparantly, "pragma GCC diagnostic push/pop" don't exist with older versions.
Fixes bug in 740e592790f570c446cbb5e6d4a77f842f75; bug not in any
released Tor.
Fixes bug 11454, where we would keep around a superseded descriptor
if the descriptor replacing it wasn't at least a week later. Bugfix
on 0.2.1.8-alpha.
Fixes bug 11457, where a certificate with a publication time in the
future could make us discard existing (and subsequent!) certificates
with correct publication times. Bugfix on 0.2.0.3-alpha.
Have clients and authorities both have new behavior, since the
fix for bug 11243 has gone in. But make clients still accept
accept old bogus HSDir descriptors, to avoid fingerprinting trickery.
Fixes bug 9286.
Otherwise we risk a subsequent memdup or memcpy copying
uninitialized RAM into some other place that might eventually expose
it. Let's make sure that doesn't happen.
Closes ticket 14041
