This parameter controls if onion services version 3 (first version of prop224)
is enabled or not. If disabled, the tor daemon will not support the protocol
for all components such as relay, directory, service and client. If the
parameter is not found, it's enabled by default.
Closes#19899
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: George Kadianakis <desnacked@riseup.net>
This implements the proposal 224 directory descriptor cache store and lookup
functionalities. Furthermore, it merges the OOM call for the HSDir cache with
current protocol v2 and the new upcoming v3.
Add hs_cache.{c|h} with store/lookup API.
Closes#18572
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: George Kadianakis <desnacked@riseup.net>
Add hs_descriptor.{c|h} with the needed ABI to represent a descriptor and
needed component.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: George Kadianakis <desnacked@riseup.net>
Also add a trunnel definition for link_specifier_list
Signed-off-by: John Brooks <special@torproject.org>
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: George Kadianakis <desnacked@riseup.net>
In order to implement proposal 224, we need the data structure rend_data_t to
be able to accomodate versionning that is the current version of hidden
service (2) and the new version (3) and future version.
For that, we implement a series of accessors and a downcast function to get
the v2 data structure. rend_data_t becomes a top level generic place holder.
The entire rend_data_t API has been moved to hs_common.{c|h} in order to
seperate code that is shared from between HS versions and unshared code (in
rendcommon.c).
Closes#19024
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: George Kadianakis <desnacked@riseup.net>
One is fixed by disabling the -Wredundant-decls warnings around
openssl headers here, because of the old double-declaration of
SSL_get_selected_srtp_profile().
One is fixed by including compat.h before or.h so that we get the
winsock2.h include before the windows.h include.
In our code to write public keys to a string, for some unfathomable
reason since 253f0f160e, we would allocate a memory BIO, then
set the NOCLOSE flag on it, extract its memory buffer, and free it.
Then a little while later we'd free the memory buffer with
BUF_MEM_free().
As of openssl 1.1 this doesn't work any more, since there is now a
BIO_BUF_MEM structure that wraps the BUF_MEM structure. This
BIO_BUF_MEM doesn't get freed in our code.
So, we had a memory leak!
Is this an openssl bug? Maybe. But our code was already pretty
silly. Why mess around with the NOCLOSE flag here when we can just
keep the BIO object around until we don't need the buffer any more?
Fixes bug 20553; bugfix on 0.0.2pre8
This function is allowed to return NULL if the certified key isn't
RSA. But in a couple of places we were treating this as a bug or
internal error, and in one other place we weren't checking for it at
all!
Caught by Isis during code review for #15055. The serious bug was
only on the 15055 branch, thank goodness.
All supported Tors (0.2.4+) require versions of openssl that can
handle this.
Now that our link certificates are RSA2048, this might actually help
vs fingerprinting a little.
This was a stopgap method, designed on the theory that some routers
might support it before they could support Ed25519. But it looks
like everybody who supports RFC5705 will also have an Ed25519 key,
so there's not a lot of reason to have this even supported.
This patch moves the pregenerated RSA key logic into a new
testing_rsakeys.c.
Also, it adds support for RSA2048, since the link handshake tests
want that.
Also, it includes pregenerated keys, rather than trying to actually
generate the keys at startup, since generating even a small handful
of RSA2048 keys makes for an annoying delay.
This code stores the ed certs as appropriate, and tries to check
them. The Ed25519 result is not yet used, and (because of its
behavior) this will break RSA authenticate cells. That will get
fixed as we go, however.
This should implement 19157, but it needs tests, and it needs
to get wired in.
In particular, these functions are the ones that set the identity of
a given connection or channel, and/or confirm that we have learned
said IDs.
There's a lot of stub code here: we don't actually need to use the
new keys till we start looking up connections/channels by Ed25519
IDs. Still, we want to start passing the Ed25519 IDs in now, so it
makes sense to add these stubs as part of 15055.
The impact here isn't too bad. First, the only affected certs that
expire after 32-bit signed time overflows in Y2038. Second, it could
only make it seem that a non-expired cert is expired: it could never
make it seem that an expired cert was still live.
Fixes bug 20027; bugfix on 0.2.7.2-alpha.
Also, adjust signing approach to more closely match the signing
scheme in the proposal.
(The format doesn't quite match the format in the proposal, since
RSA signatures aren't fixed-length.)
Closes 19020.
See proposal 244. This feature lets us stop looking at the internals
of SSL objects, *and* should let us port better to more SSL libraries,
if they have RFC5705 support.
Preparatory for #19156
We no longer generate certs cells by pasting the certs together one
by one. Instead we use trunnel to generate them.
Preliminary work for 19155 (send CERTS cell with ed certs)
passthrough_test_setup doesn't pass through arguments if the argument
is equal to 0 or TT_SKIP. Instead, it fails or skips the test.
Assert on this, so we don't accidentally fail or skip tests.
Fixes bug 19969; bugfix on b1d56fc58. We can fix this some more in
later Tors, but for now, this is probably the simplest fix possible.
This is a belt-and-suspenders fix, where the earlier fix ("Ask
event_base_loop to finish when we add a pending stream") aims to respond
to new streams as soon as they arrive, and this one aims to make sure
that we definitely respond to all of the streams.
ome policies are default-reject, some default-accept. But
policy_is_reject_star() assumed they were all default_reject. Fix
that!
Also, document that policy_is_reject_star() treats a NULL policy as
empty. This allows us to simplify the checks in
parse_reachable_addresses() by quite a bit.
Fxes bug 20306; bugfix on 0.2.8.2-alpha.
(Also, refactor the code to create a hidden service directory into a
separate funcion, so we don't have to duplicate it.)
Fixes bug 20484; bugfix on 0.2.9.3-alpha.
This simplifies the function: if we have an ntor key, use ntor/EXTEND2,
otherwise, use TAP/EXTEND.
Bugfix on commit 10aa913 from 19163 in 0.2.9.3-alpha.
I had replaced a comment implying that a set of ifs was meant to be
exhaustive with an actual check for exhaustiveness. It turns out,
they were exhaustive, but not in the way I had assumed. :(
Bug introduced in f3e158edf7, not in any released Tor.
Use the following coccinelle script to change uses of
smartlist_add(sl, tor_strdup(str)) to
smartlist_add_strdup(sl, string) (coccinelle script from nickm
via bug 20048):
@@
expression a;
expression b;
@@
- smartlist_add
+ smartlist_add_strdup
(a,
- tor_strdup(
b
- )
)
The tor_fragile_assert() bug has existed here since c8a5e2d588
in tor-0.2.1.7-alpha forever, but tor_fragile_assert() was mostly a
no-op until 0.2.9.1-alpha.
Fixes bug 19869.
When we refactored purpose_needs_anonymity(), we made it so _all_
bridge requests required anonymity. But that missed the case
that we are allowed to ask a bridge for its own descriptor.
With this patch, we consider the resource, and allow "authority.z"
("your own descriptor, compressed") for a bridge's server descriptor
to be non-anonymous.
Fix for bug 20410; bug not in any released Tor.
I believe that this should never trigger, but if it does, it
suggests that there was a gap between is_sensitive_dir_purpose and
purpose_needs_anonymity that we need to fill. Related to 20077.
This helps protect against bugs where any part of a buf_t's memory
is passed to a function that expects a NUL-terminated input.
It also closes TROVE-2016-10-001 (aka bug 20384).
This commit adds or improves the module-level documenation for:
buffers.c circuitstats.c command.c connection_edge.c control.c
cpuworker.c crypto_curve25519.c crypto_curve25519.h
crypto_ed25519.c crypto_format.c dircollate.c dirserv.c dns.c
dns_structs.h fp_pair.c geoip.c hibernate.c keypin.c ntmain.c
onion.c onion_fast.c onion_ntor.c onion_tap.c periodic.c
protover.c protover.h reasons.c rephist.c replaycache.c
routerlist.c routerparse.c routerset.c statefile.c status.c
tor_main.c workqueue.c
In particular, I've tried to explain (for each documented module)
what each module does, what's in it, what the big idea is, why it
belongs in Tor, and who calls it. In a few cases, I've added TODO
notes about refactoring opportunities.
I've also renamed an argument, and fixed a few DOCDOC comments.
(I've done this instead of changing the semantics of
router_compare_to_my_exit_policy, because dns.c uses
router_compare_to_my_exit_policy too, in a slightly weird way.)
Some compilers apparently noticed that p2len was allowed to be equal
to msg, and so maybe we would be doing memset(prompt2, ' ', 0), and
decided that we probably meant to do memset(prompt2, 0, 0x20);
instead.
Stupid compilers, doing optimization before this kind of warning!
My fix is to just fill the entire prompt2 buffer with spaces,
because it's harmless.
Bugfix on e59f0d4cb9, not in any released Tor.
(Specifically, carriage return after a quoted value in a config
line. Fixes bug 19167; bugfix on 0.2.0.16-alpha when we introduced
support for quoted values. Unit tests, changes file, and this
parenthetical by nickm.)
This is a kludge to deal with the fact that `tor_addr_t` doesn't contain
`sun_path`. This currently ONLY happens when circuit isolation is being
checked, for an isolation mode that is force disabled anyway, so the
kludge is "ugly but adequate", but realistically, making `tor_addr_t`
and the AF_UNIX SocksPort code do the right thing is probably the better
option.
Closes ticket 20303.
The LIBRESSL_VERSION_NUMBER check is needed because if our openssl
is really libressl, it will have an openssl version number we can't
really believe.
Previously, we would reject even rendezvous connections to IPv6
addresses when IPv6Exit was false. But that doesn't make sense; we
don't count that as "exit"ing. I've corrected the logic and tried
to make it a lottle more clear.
Fixes bug 18357; this code has been wrong since 9016d9e829 in
0.2.4.7-alpha.
