It's only safe to remove the failure limit (per 20536) if we are in
fact waiting a bit longer each time we try to download.
Fixes bug 20534; bugfix on 0.2.9.1-alpha.
If a consensus expires while we are waiting for certificates to download,
stop waiting for certificates.
If we stop waiting for certificates less than a minute after we started
downloading them, do not consider the certificate download failure a
separate failure.
Fixes bug 20533; bugfix on commit e0204f21 in 0.2.0.9-alpha.
Relays do not deliberately launch multiple attempts, so the impact of this
bug should be minimal. This fix also defends against bugs like #20499.
Bugfix on 0.2.8.1-alpha.
(OpenSSL 1.1 makes EVP_CIPHER_CTX opaque, _and_ adds acceleration
for counter mode on more architectures. So it won't work if we try
the older approach, and it might help if we try the newer one.)
Fixes bug 20588.
Note that the "signed key" in the signing key certificate is the
signing key. The "signing key" in the signing key certificate is
the key that signs the certificate -- that is, the blinded key.
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.
