Age | Commit message (Collapse) | Author |
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17271)
|
|
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17135)
|
|
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17158)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16924)
|
|
If an async job pauses while processing a TLS connection then the
rwstate gets set to SSL_ASYNC_PAUSED. When resuming the job we should
reset the rwstate back to SSL_NOTHING. In fact we can do this
unconditionally since if we're about to call ASYNC_start_job() then either
we are about to start the async job for the first time (in which case the
rwstate should already by SSL_NOTHING), or we are restarting it after a
pause (in which case reseting it to SSL_NOTHING is the correct action).
Fixes #16809
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17013)
(cherry picked from commit 07f620e3acf0dd76a3a03ada9911c544aa483aa7)
|
|
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16955)
|
|
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16957)
|
|
Normally we expect a client to send new extensions in the ClientHello,
which may be echoed back by the server in subsequent messages. However the
server can also send a new extension in the certificate request message to
be echoed back in a certificate message
Fixes #16632
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16634)
(cherry picked from commit cbb862fbaaa1ec5a3e33836bc92a6dbea97ceba0)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16671)
|
|
Fixes #16428
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16441)
|
|
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16375)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16385)
(cherry picked from commit 562d4cd3c35b32f2bc6ac0770b80ce394f8d76a4)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
The `sk` variable is assigned to `s->session->peer_chain`.
If `ssl3_digest_cached_records()` were to fail, then `sk` would still be
non-NULL, and subsequently freed on the error return. When the session
is freed, it will then attempt to free `s->session->peer_chain`,
resulting in a double-free (of `sk`).
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16309)
(cherry picked from commit 0449702abc95a3af24c049cb02c01ca6a8015cef)
|
|
Various comments referred to s->packet and s->packet_length instead of
s->rlayer.packet and s->rlayer.packet_length. Also fixed is a spot where
RECORD_LAYER_write_pending() should have been used. Based on the review
comments in #16077.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(cherry picked from commit ca001524971ccd595bc0e9843611e6784adfc981)
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16105)
|
|
If an application is halfway through writing application data it should
not be allowed to attempt an SSL_key_update() operation. Instead the
SSL_write() operation should be completed.
Fixes #12485
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16098)
|
|
Sometimes this function gets called when the buffers have already been
set up. If there is already a partial packet in the read buffer then the
packet pointer will be set to an incorrect value. The packet pointer already
gets reset to the correct value when we first read a packet anyway, so we
don't also need to do it in ssl3_setup_read_buffer.
Fixes #13729
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16098)
|
|
We received a report of an "excessive message size" for a received
session ticket. Our maximum size was significantly less than the theoretical
maximum. The server may put any data it likes in the session ticket
including (for example) the full certificate chain so we should be able to
handle longer tickets. Update the value to the maximum allowed by the spec.
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15877)
(cherry picked from commit e54f0c9b2fe3dd2dcb5e8100e2c69e5b2f6eb681)
|
|
manual merge from https://github.com/openssl/openssl/pull/15818
id d7b5c648d682b499b71320a03747602a6ba4dec3
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15832)
|
|
The function dtls1_handle_timeout() calls dtls1_double_timeout() which
was calling dtls1_start_timer(). However dtls1_start_timer() is also
called directly by dtls1_handle_timeout(). We only need to start the timer
once.
Fixes #15561
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15595)
(cherry picked from commit f570d33b02d824e2a3f676f718c4692572f45333)
|
|
When EVP_MD_CTX_new fails call SSLfatal before the goto err.
This resolves a state machine issue on the out of memory condition:
ssl/statem/statem.c:643: OpenSSL internal error: Assertion failed:
(s)->statem.in_init && (s)->statem.state == MSG_FLOW_ERROR
Fixes #15491.
CLA: trivial
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15511)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/15518)
|
|
Otherwise, the state machine ends up being in a bad state:
```
SSL routines:write_state_machine:missing fatal:ssl/statem/statem.c:850:
```
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/15485)
|
|
Fixes #14875
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15383)
(cherry picked from commit 3f987381929ee725daf4746591144dde18f313e1)
|
|
TLS 1.3 allows for the "psk_ke" and "psk_dhe_ke" key-exchange modes.
Only the latter mode introduces a new ephemeral (Diffie-Hellman)
key exchange, with the PSK being the only key material used in the
former case.
It's a compliance requirement of RFC 8446 that the server MUST NOT
send a KeyShareEntry when using the "psk_ke" mode, but prior to
this commit we would send a key-share based solely on whether the
client sent one. This bug goes unnoticed in our internal test suite
since openssl communicating with openssl can never negotiate the
PSK-only key-exchange mode. However, we should still be compliant
with the spec, so check whether the DHE mode was offered and don't
send a key-share if it wasn't.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(cherry picked from commit e776858bce32d473bd7a69c616ad7f6c2f979dfc)
(Merged from https://github.com/openssl/openssl/pull/15255)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15255)
|
|
It's a MUST-level requirement that if the client sends a pre_shared_key
extension not accompanied by a psk_key_exchange_modes extension, the
server must abort the handshake. Prior to this commit the server
would continue on.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(cherry picked from commit efe0f315354b020213097885c79ce856a2f5ac68)
(Merged from https://github.com/openssl/openssl/pull/15255)
|
|
Fixes #11388
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15159)
(cherry picked from commit 22d1138fe2fde9a16e80b81de1d848ae6fa879ef)
|
|
Fixes #12735 for 1.1.1
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15109)
|
|
It's possible to set an invalid protocol list that will be sent in a
ClientHello. This validates the inputs to make sure this does not
happen.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14679)
|
|
CLA: trivial
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14719)
(cherry picked from commit 7947a1eb13c221bbc034796bd394ba00b0e2387d)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
|
|
Following on from CVE-2021-3449 which was caused by a non-zero length
associated with a NULL buffer, other buffer/length pairs are updated to
ensure that they too are always in sync.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
As the variable peer_sigalgslen is not cleared on ssl rehandshake, it's
possible to crash an openssl tls secured server remotely by sending a
manipulated hello message in a rehandshake.
On such a manipulated rehandshake, tls1_set_shared_sigalgs() calls
tls12_shared_sigalgs() with the peer_sigalgslen of the previous
handshake, while the peer_sigalgs has been freed.
As a result tls12_shared_sigalgs() walks over the available
peer_sigalgs and tries to access data of a NULL pointer.
This issue was introduced by c589c34e61 (Add support for the TLS 1.3
signature_algorithms_cert extension, 2018-01-11).
Signed-off-by: Peter Kästle <peter.kaestle@nokia.com>
Signed-off-by: Samuel Sapalski <samuel.sapalski@nokia.com>
CVE-2021-3449
CLA: trivial
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14639)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14585)
(cherry picked from commit 3de7f014a985637361bdee775f78209300c88aae)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
This field has not been used since #3858 was merged in 2017 when we
moved to a table-based lookup for certificate type properties instead of
an index-based one.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/13991)
(cherry picked from commit 3bc0b621a7baf1a11bc5cad69a287ad093674d68)
|
|
Fixes #13183
From the original issue report, before this commit, on master and on
1.1.1, the issue can be detected with the following steps:
- Start with a default SSL_CTX, initiate a TLS 1.3 connection with SNI,
"Accept" count of default context gets incremented
- After servername lookup, "Accept" count of default context gets
decremented and that of SNI context is incremented
- Server sends a "Hello Retry Request"
- Client sends the second "Client Hello", now again "Accept" count of
default context is decremented. Hence giving a negative value.
This commit fixes it by adding a check on `s->hello_retry_request` in
addition to `SSL_IS_FIRST_HANDSHAKE(s)`, to ensure the counter is moved
only on the first ClientHello.
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13297)
|
|
Our free functions should be able to deal with the case where the object
being freed is NULL. This turns out to not be quite the case for DTLS
related objects.
Fixes #13649
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13655)
(cherry picked from commit d0afb30ef3950cacff50ec539e90073b95a276df)
|
|
A servername cb may change the available certificates, so if we have one
set then we cannot rely on the configured certificates to determine if we
are capable of negotiating TLSv1.3 or not.
Fixes #13291
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13305)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
This code started off as a copy of ssl3_write_bytes(), and the comment
was not updated with the implementation.
Reported by yangyangtiantianlonglong in #13518
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13566)
(cherry picked from commit 70cae332a2c200087605f94cdccfee80c9380fbf)
|
|
The handling for the SCSVs was the same as for regular ciphers;
just merge them into the same table-driven handler.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(cherry picked from commit 231849bc9ca69dfd3adf40821421d8e2d804d8e8)
(Merged from https://github.com/openssl/openssl/pull/13280)
|
|
Return immediately on matched cipher. Without this patch the code only breaks out of the inner for loop, meaning for a matched TLS13 cipher the code will still loop through 160ish SSL3 ciphers.
CLA: trivial
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(cherry picked from commit d93bded6aa2852e681de2ed76fb43c415687af68)
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/13280)
|
|
We were missing a call to SSLfatal. A comment claimed that we had already
called it - but that is incorrect.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/13230)
|
|
Fixes regression from 7844f3c784bfc93c9b94ae5a4082f9d01e82e0af
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13194)
|
|
The security operation SSL_SECOP_TMP_DH is defined to take an EVP_PKEY
in the "other" parameter:
/* Temporary DH key */
# define SSL_SECOP_TMP_DH (7 | SSL_SECOP_OTHER_PKEY)
In most places this is what is passed. All these places occur server side.
However there is one client side call of this security operation and it
passes a DH object instead. This is incorrect according to the
definition of SSL_SECOP_TMP_DH, and is inconsistent with all of the other
locations.
Our own default security callback, and the debug callback in the apps,
never look at this value and therefore this issue was never noticed
previously. In theory a client side application could be relying on this
behaviour and could be broken by this change. This is probably fairly
unlikely but can't be ruled out.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/13136)
|
|
orignal -> original
CLA: trivial
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/13111)
(cherry picked from commit 9f7505ab6a1ce76497654ea8cf6a74307da78989)
|
|
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13055)
(cherry picked from commit 8ad369171fc2b435c0ca427111481da4d4c3c1ce)
|