| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fixes #40874
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Skip a warning using EC_GFp_nist_method() which was removed in LibreSSL
3.8.
Based on a patch from OpenBSD.
https://github.com/openbsd/ports/commit/33fe251a08cb11f30ce6094a2e0759c3bb63ed16
These functions are deprecated since OpenSSL 3.0.
https://www.openssl.org/docs/man3.1/man3/EC_GFp_nist_method.html
|
|
detection false positive.
|
|
|
|
Part of #40548
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
We already did this in a couple of places, but there are more that
we didn't get. This is necessary for systems with versions of
NSS that don't do their prototypes properly.
Fixes #40409; bugfix on 0.3.5.1-alpha.
|
|
|
|
|
|
|
|
It was used nowhere outside its own unit tests, and it was causing
compilation issues with recent OpenSSL 3.0.0 alphas.
Closes ticket 40399.
|
|
|
|
|
|
This way, if we guess wrong about whether the library has it,
we don't conflict with the library's headers.
Fixes #40181; bug not in any released version.
|
|
This was once used for rate-limiting, but now it's only for
accounting. It hasn't served a useful purpose in a long time.
Closes ticket 33097.
|
|
|
|
|
|
Closes ticket 40035.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This warning only affects platforms (like win32) with 32-bit time_t.
Fixes bug 40028; bugfix on 0.3.2.8-rc.
|
|
This patch changes our bits-to-bytes conversion logic in the NSS
implementation of `tor_tls_cert_matches_key()` from using (x >> 3) to
((x + 7) >> 3) since DER bit-strings are allowed to contain a number of
bits that is not a multiple of 8.
Additionally, we add a comment on why we cannot use the
`DER_ConvertBitString()` macro from NSS, as we would potentially apply
the bits-to-bytes conversion logic twice, which would lead to an
insignificant amount of bytes being compared in
`SECITEM_ItemsAreEqual()` and thus turn the logic into being a
prefix match instead of a full match.
The `DER_ConvertBitString()` macro is defined in NSS as:
/*
** Macro to convert der decoded bit string into a decoded octet
** string. All it needs to do is fiddle with the length code.
*/
#define DER_ConvertBitString(item) \
{ \
(item)->len = ((item)->len + 7) >> 3; \
}
Thanks to Taylor Yu for spotting this problem.
This patch is part of the fix for TROVE-2020-001.
See: https://bugs.torproject.org/33119
|
|
We add constness to `peer_info_orig_len` and `cert_info_orig_len` in
`tor_tls_cert_matches_key` to ensure that we don't accidentally alter
the variables.
This patch is part of the fix for TROVE-2020-001.
See: https://bugs.torproject.org/33119
|
|
This patch fixes an out-of-bound memory read in
`tor_tls_cert_matches_key()` when Tor is compiled to use Mozilla's NSS
instead of OpenSSL.
The NSS library stores some length fields in bits instead of bytes, but
the comparison function found in `SECITEM_ItemsAreEqual()` needs the
length to be encoded in bytes. This means that for a 140-byte,
DER-encoded, SubjectPublicKeyInfo struct (with a 1024-bit RSA public key
in it), we would ask `SECITEM_ItemsAreEqual()` to compare the first 1120
bytes instead of 140 (140bytes * 8bits = 1120bits).
This patch fixes the issue by converting from bits to bytes before
calling `SECITEM_ItemsAreEqual()` and convert the `len`-fields back to
bits before we leave the function.
This patch is part of the fix for TROVE-2020-001.
See: https://bugs.torproject.org/33119
|
|
|
|
Now instead of saying "DONE, DONE" or "MISC, MISC" or "TLS_ERROR,
TLS_ERROR", we can finally give a nice sensible "TLS_ERROR,
wrong version number" which should help debug a great deal.
Closes ticket 32622.
|
|
The buf_read_from_tls() function was designed to read up to a certain number
of bytes a TLS socket using read_to_chunk_tls() which boils down to SSL_read()
(with OpenSSL, common case).
However, at the end of the loop, the returned number of bytes from
read_to_chunk_tls() was treated like the syscall read() for which if less
bytes than the total asked are returned, it signals EOF.
But, with SSL_read(), it returns up to a TLS record which can be less than
what was asked. The assumption that it was EOF was wrong which made the while
loop exiting before it was able to consume all requested bytes (at_most
parameter).
The general use case that Tor sees is that it will ask the network layer to
give it at most 16KB (that is roughly 32 cells) but because of KIST scheduler,
the highest possible TLS record we currently observe is 4096 bytes (4KB or 8
cells). Thus the loop would at best always return 8 cells even though much
more could be on the TLS socket. See ticket #40006 for more details.
Fixes #40006
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
No functionality change.
|
|
|
|
|
|
|
|
|
|
Fixes bug 32673; bugfix on 0.3.0.4-alpha. We introduced these
checks in ee5471f9aab5526 to help diagnose 21369, but we used "-1"
when "TOR_TLS_ERROR_MISC" would have been correct. Found by opara.
I don't think that this is actually getting triggered in the wild,
but if it were, it could cause nasty behavior: spurious
WANTREAD/WANTWRITE returns have a way of turning into CPU-eating
busy-loops.
|
|
We introduced these BUG() checks in b0ddaac07428a06 to prevent a
recurrence of bug 23690. But there's a report of the BUG() message
getting triggered and filling up the disk. Let's change it to
IF_BUG_ONCE().
Fixes bug 33093; bugfix on 0.3.2.2-alpha.
|
|
|
|
This gives us the definition of tor_x509_cert_impl_t, and makes us
less dependent on include order.
|
|
This is an automated commit, generated by:
perl -i -pe 'next if /define/; s/((?:ENABLE|DISABLE)_GCC_WARNING)\(([A-Za-z0-9_\-]+)\)/$1(\"-W$2\")/' src/*/*/*.[ch] src/*/*.[ch]
|
|
|
