- 06 Jul, 2018 1 commit
-
-
Matt Caswell authored
Previoulsy we just had max_early_data which controlled both the value of max early_data that we advertise in tickets *and* the amount of early_data that we are willing to receive from clients. This doesn't work too well in the case where we want to reduce a previously advertised max_early_data value. In that case clients with old, stale tickets may attempt to send us more early data than we are willing to receive. Instead of rejecting the early data we abort the connection if that happens. To avoid this we introduce a new "recv_max_early_data" value. The old max_early_data becomes the value that is advertised in tickets while recv_max_early_data is the maximum we will tolerate from clients. Fixes #6647 Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/6655)
-
- 05 Jul, 2018 2 commits
-
-
Rich Salz authored
Reviewed-by:
-
Rich Salz authored
Reported by Ingo Schwarze Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/6656)
-
- 04 Jul, 2018 3 commits
-
-
Richard Levitte authored
Fixes #6644 Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6645)
-
Billy Brumley authored
Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6648)
-
Matt Caswell authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6634)
-
- 03 Jul, 2018 7 commits
-
-
Pauli authored
Reviewed-by:
-
Rich Salz authored
Also fix some L<> labels and =item entries found while doing this. Reviewed-by:
-
Andy Polyakov authored
The 128-byte vectors are extensively used in chacha20_poly1305_tls_cipher and dedicated code path is ~30-50% faster on most platforms. Reviewed-by:
-
Andy Polyakov authored
Hexadecimals were erroneously recognized as symbols in .xdata. Reviewed-by:
-
Matt Caswell authored
Tickets are supposed to be single use so we remove them from the cache on use. Fixes #6377 Reviewed-by:
-
Matt Caswell authored
In TLSv1.2 and below we should remove an old session from the client session cache in the event that we receive a new session ticket from the server. Reviewed-by:
-
Pauli authored
The problematic case falls back to a NULL conf which returns the result of getenv(2). If this returns NULL, everything was good. If this returns a string an attempt to convert it to a number is made using the function pointers from conf. This fix uses the strtol(3) function instead, we don't have the configuration settings and this behaves as the default would. Reviewed-by:
-
- 02 Jul, 2018 6 commits
-
-
Matt Caswell authored
This also adds the ability to control this through s_server Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Document SSL_OP_NO_ANTI_REPLAY and SSL_CTX_set_allow_early_data_cb() Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Fixes #6389 Reviewed-by:
-
Matt Caswell authored
Fixes #6574 Reviewed-by:
-
- 01 Jul, 2018 4 commits
-
-
Benjamin Kaduk authored
We need to check the provided SSL_SESSION* for NULL before attempting to derference it to see if it's a TLS 1.3 session. Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/6622)
-
Pauli authored
The issue was discovered on the x86/64 when attempting to include libcrypto inside another shared library. A relocation of type R_X86_64_PC32 was generated which causes a linker error. Reviewed-by:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6595)
-
Andy Polyakov authored
Occasionally, e.g. when compiling for elderly glibc, you end up passing -D_GNU_SOURCE on command line, and doing so triggered warning... Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
- 29 Jun, 2018 3 commits
-
-
Andy Polyakov authored
Inputs not longer than 64 bytes are processed ~10% faster, longer lengths not divisble by 64, e.g. 255, up to ~20%. Unfortunately it's impossible to measure with apps/speed.c, -aead benchmarks TLS-like call sequence, but not exact. It took specially crafted code path... Reviewed-by:
-
Billy Brumley authored
1. For every named curve, two "golden" keypair positive tests. 2. Also two "golden" stock ECDH positive tests. 3. For named curves with non-trivial cofactors, additionally two "golden" ECC CDH positive tests. 4. For named curves with non-trivial cofactors, additionally two negative tests. There is some overlap with existing EVP tests, especially for the NIST curves (for example, positive testing ECC CDH KATs for NIST curves). "Golden" here means all the values are independent from OpenSSL's ECC code. I used sage to calculate them. What comes from OpenSSL is: 1. The OIDs (parsed by tooling) 2. The curve parameters (parsing ecparam output with tooling) The values inside the PEMs (private keys, public keys) and shared keys are from sage. The PEMs themselves are the output of asn1parse, with input taken from sage. Reviewed-by:
-
Pauli authored
In ssl/t1_lib.c. Reviewed-by:
-
- 28 Jun, 2018 1 commit
-
-
Rich Salz authored
Fixes uninitialized memory read reported by Nick Mathewson Reviewed-by:
Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6603)
-
- 27 Jun, 2018 4 commits
-
-
Matt Caswell authored
Currently if you encounter application data while waiting for a close_notify from the peer, and you have called SSL_shutdown() then you will get a -1 return (fatal error) and SSL_ERROR_SYSCALL from SSL_get_error(). This isn't accurate (it should be SSL_ERROR_SSL) and isn't persistent (you can call SSL_shutdown() again and it might then work). We change this into a proper fatal error that is persistent. Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by:
-
Matt Caswell authored
In the case where we are shutdown for writing and awaiting a close_notify back from a subsequent SSL_shutdown() call we skip over handshake data that is received. This should not be treated as an error - instead it should be signalled with SSL_ERROR_WANT_READ. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
If we've sent a close_notify and we're waiting for one back we drop incoming records until we see the close_notify we're looking for. If SSL_MODE_AUTO_RETRY is on, then we should immediately try and read the next record. Fixes #6262 Reviewed-by:
-
- 26 Jun, 2018 8 commits
-
-
Pauli authored
This allows operation inside a chroot environment without having the random device present. A new call, RAND_keep_random_devices_open(), has been introduced that can be used to control file descriptor use by the random seed sources. Some seed sources maintain open file descriptors by default, which allows such sources to operate in a chroot(2) jail without the associated device nodes being available. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
During anti-replay we cache the ticket anyway, so there is no point in using a full stateless ticket. Fixes #6391 Reviewed-by:
-
Matt Caswell authored
Implement support for stateful TLSv1.3 tickets, and use them if SSL_OP_NO_TICKET is set. Reviewed-by:
-
Matt Caswell authored
Separate out as a new function the code to write out data which is specific to a stateless ticket. Reviewed-by:
-
Andy Polyakov authored
... and mention more runtime search path flags. Reviewed-by:
-
Matt Caswell authored
Make SSL_SESSION_print() show a bit more information for TLSv1.3 Reviewed-by:
-
Matt Caswell authored
s_client was dumping session data at the end of the handshake. In TLSv1.3 we don't have session data until receipt of a NewSessionTicket message which happens post-handshake. Therefore we delay dumping the session data until that message has arrived if TLSv1.3 has been negotiated. Fixes #6482 Reviewed-by:
-
- 25 Jun, 2018 1 commit
-
-
Richard Levitte authored
This function is documented to be deprecated since OpenSSL 1.1.0. We need to make it so in openssl/ssl.h as well. Fixes #6565 Reviewed-by:
-
