Fixes#21605
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21606)
Some ciphers/protocol versions have an explicit IV. We need to make sure we
have sufficient room for it in the underlying buffer.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20087)
Stitched ciphersuites can grow by more during encryption than the code
allowed for. We fix the calculation and add an assert to check we go it
right.
Also if we are adding the MAC independently of the cipher algorithm then
the encryption growth will not include that MAC so we should remove it
from the amount of bytes that we reserve for that growth. Otherwise we
might exceed our buffer size and the WPACKET_reserve operation will
fail.
Note that this is not a security issue. Even though we can overflow the
amount of bytes reserved in the WPACKET for the encryption, the underlying
buffer is still big enough.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19585)
If rule_str ended in a "-", "l" was incremented one byte past the
end of the buffer. This resulted in an out-of-bounds read when "l"
is dereferenced at the end of the loop. It is safest to just return
early in this case since the condition occurs inside a nested loop.
CLA: trivial
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19166)
(cherry picked from commit 428511ca66)
Fixes#18183.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19081)
Fixes a bug in the cookie code which would have caused problems for ten
minutes before and after the lower 32 bits of time_t rolled over.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19022)
Avoid problems when the lower 32 bits of time_t roll over by delaying
the cast to integer until after the time delta has been computed.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19004)
(cherry picked from commit a6cadcbdc3)
If app data is received before a Finished message in DTLS then we buffer
it to return later. The function SSL_pending() is supposed to tell you
how much processed app data we have already buffered, and SSL_has_pending()
is supposed to tell you if we have any data buffered (whether processed or
not, and whether app data or not).
Neither SSL_pending() or SSL_has_pending() were taking account of this
DTLS specific app data buffer.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18976)
This was found by my Reproducible Error Injection patch (#18356)
Due to the exact location of the injected memory
error the sha256 digest is missing, and this causes much later
the memory leak (and a failed assertion) in tls13_generate_secret.
But the reproduction is a bit challenging, as it requires AESNI
and RDRAND capability.
OPENSSL_ia32cap=0x4200000000000000 ERROR_INJECT=1657070330 ../util/shlib_wrap.sh ./client-test ./corpora/client/791afc153e17db072175eeef85385a38d7f6d194
#0 0x7fceaffb7d4f in __sanitizer_print_stack_trace ../../../../src/libsanitizer/asan/asan_stack.cc:36
#1 0x55fb9117f934 in my_malloc fuzz/test-corpus.c:114
#2 0x7fceafa147f3 in OPENSSL_LH_insert crypto/lhash/lhash.c:109
#3 0x7fceafa42639 in lh_OBJ_NAME_insert crypto/objects/obj_local.h:12
#4 0x7fceafa42639 in OBJ_NAME_add crypto/objects/o_names.c:236
#5 0x7fceaf9f7baa in EVP_add_digest crypto/evp/names.c:39
#6 0x7fceaf9c6b97 in openssl_add_all_digests_int crypto/evp/c_alld.c:39
#7 0x7fceafa0f8ec in ossl_init_add_all_digests crypto/init.c:275
#8 0x7fceafa0f8ec in ossl_init_add_all_digests_ossl_ crypto/init.c:264
#9 0x7fceaf69b4de in __pthread_once_slow /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_once.c:116
#10 0x7fceafafb27c in CRYPTO_THREAD_run_once crypto/threads_pthread.c:118
#11 0x7fceafa1000e in OPENSSL_init_crypto crypto/init.c:677
#12 0x7fceafa1000e in OPENSSL_init_crypto crypto/init.c:611
#13 0x7fceafdad3e8 in OPENSSL_init_ssl ssl/ssl_init.c:190
#14 0x55fb9117ee0f in FuzzerInitialize fuzz/client.c:46
#15 0x55fb9117e939 in main fuzz/test-corpus.c:194
#16 0x7fceaf4bc082 in __libc_start_main ../csu/libc-start.c:308
#17 0x55fb9117ec7d in _start (.../openssl/fuzz/client-test+0x2c7d)
#0 0x7fceaffb7d4f in __sanitizer_print_stack_trace ../../../../src/libsanitizer/asan/asan_stack.cc:36
#1 0x55fb9117f934 in my_malloc fuzz/test-corpus.c:114
#2 0x7fceafa147f3 in OPENSSL_LH_insert crypto/lhash/lhash.c:109
#3 0x7fceafa42639 in lh_OBJ_NAME_insert crypto/objects/obj_local.h:12
#4 0x7fceafa42639 in OBJ_NAME_add crypto/objects/o_names.c:236
#5 0x7fceaf9f7baa in EVP_add_digest crypto/evp/names.c:39
#6 0x7fceafdad328 in ossl_init_ssl_base ssl/ssl_init.c:87
#7 0x7fceafdad328 in ossl_init_ssl_base_ossl_ ssl/ssl_init.c:24
#8 0x7fceaf69b4de in __pthread_once_slow /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_once.c:116
#9 0x7fceafafb27c in CRYPTO_THREAD_run_once crypto/threads_pthread.c:118
#10 0x7fceafdad412 in OPENSSL_init_ssl ssl/ssl_init.c:193
#11 0x55fb9117ee0f in FuzzerInitialize fuzz/client.c:46
#12 0x55fb9117e939 in main fuzz/test-corpus.c:194
#13 0x7fceaf4bc082 in __libc_start_main ../csu/libc-start.c:308
#14 0x55fb9117ec7d in _start (.../openssl/fuzz/client-test+0x2c7d)
=================================================================
==1320996==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 80 byte(s) in 1 object(s) allocated from:
#0 0x7fceaffaa808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x7fceafa19425 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fceafa03a85 in int_ctx_new crypto/evp/pmeth_lib.c:144
#3 0x7fceafa03a85 in EVP_PKEY_CTX_new_id crypto/evp/pmeth_lib.c:250
#4 0x7fceafe38de5 in tls13_generate_secret ssl/tls13_enc.c:174
#5 0x7fceafd9537f in ssl_derive ssl/s3_lib.c:4833
#6 0x7fceafdde91c in tls_parse_stoc_key_share ssl/statem/extensions_clnt.c:1902
#7 0x7fceafdd4ac1 in tls_parse_all_extensions ssl/statem/extensions.c:752
#8 0x7fceafdf8079 in tls_process_server_hello ssl/statem/statem_clnt.c:1698
#9 0x7fceafe01f87 in ossl_statem_client_process_message ssl/statem/statem_clnt.c:1034
#10 0x7fceafdeec0d in read_state_machine ssl/statem/statem.c:636
#11 0x7fceafdeec0d in state_machine ssl/statem/statem.c:434
#12 0x7fceafdb88d7 in SSL_do_handshake ssl/ssl_lib.c:3718
#13 0x55fb9117f07c in FuzzerTestOneInput fuzz/client.c:98
#14 0x55fb9117f463 in testfile fuzz/test-corpus.c:182
#15 0x55fb9117eb92 in main fuzz/test-corpus.c:226
#16 0x7fceaf4bc082 in __libc_start_main ../csu/libc-start.c:308
Indirect leak of 1080 byte(s) in 1 object(s) allocated from:
#0 0x7fceaffaa808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x7fceafa19425 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fceafa11555 in pkey_hkdf_init crypto/kdf/hkdf.c:51
#3 0x7fceafa03b36 in int_ctx_new crypto/evp/pmeth_lib.c:160
#4 0x7fceafa03b36 in EVP_PKEY_CTX_new_id crypto/evp/pmeth_lib.c:250
#5 0x7fceafe38de5 in tls13_generate_secret ssl/tls13_enc.c:174
#6 0x7fceafd9537f in ssl_derive ssl/s3_lib.c:4833
#7 0x7fceafdde91c in tls_parse_stoc_key_share ssl/statem/extensions_clnt.c:1902
#8 0x7fceafdd4ac1 in tls_parse_all_extensions ssl/statem/extensions.c:752
#9 0x7fceafdf8079 in tls_process_server_hello ssl/statem/statem_clnt.c:1698
#10 0x7fceafe01f87 in ossl_statem_client_process_message ssl/statem/statem_clnt.c:1034
#11 0x7fceafdeec0d in read_state_machine ssl/statem/statem.c:636
#12 0x7fceafdeec0d in state_machine ssl/statem/statem.c:434
#13 0x7fceafdb88d7 in SSL_do_handshake ssl/ssl_lib.c:3718
#14 0x55fb9117f07c in FuzzerTestOneInput fuzz/client.c:98
#15 0x55fb9117f463 in testfile fuzz/test-corpus.c:182
#16 0x55fb9117eb92 in main fuzz/test-corpus.c:226
#17 0x7fceaf4bc082 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: 1160 byte(s) leaked in 2 allocation(s).
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18725)
When TLS-1.3 is used and the server does not send any CA names
the ca_dn will be NULL. sk_X509_NAME_num() returns -1 on null
argument.
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17986)
(cherry picked from commit 89dd854307)
Prior to the crash there is an out of memory error
in X509_verify_cert which makes the chain NULL or
empty. The error is ignored by ssl_add_cert_chain,
and ssl_security_cert_chain crashes due to the
unchecked null pointer.
This is reproducible with my error injection patch.
The test vector has been validated on the 1.1.1 branch
but the issue is of course identical in all branches.
$ ERROR_INJECT=1652848273 ../util/shlib_wrap.sh ./server-test ./corpora/server/47c8e933c4ec66fa3c309422283dfe0f31aafae8# ./corpora/server/47c8e933c4ec66fa3c309422283dfe0f31aafae8
#0 0x7f3a8f766eba in __sanitizer_print_stack_trace ../../../../gcc-trunk/libsanitizer/asan/asan_stack.cpp:87
#1 0x403ba4 in my_malloc fuzz/test-corpus.c:114
#2 0x7f3a8f39a430 in CRYPTO_zalloc crypto/mem.c:230
#3 0x7f3a8f46bd3b in sk_reserve crypto/stack/stack.c:180
#4 0x7f3a8f46bd3b in OPENSSL_sk_insert crypto/stack/stack.c:242
#5 0x7f3a8f4a4fd8 in sk_X509_push include/openssl/x509.h:99
#6 0x7f3a8f4a4fd8 in X509_verify_cert crypto/x509/x509_vfy.c:286
#7 0x7f3a8fed726e in ssl_add_cert_chain ssl/statem/statem_lib.c:959
#8 0x7f3a8fed726e in ssl3_output_cert_chain ssl/statem/statem_lib.c:1015
#9 0x7f3a8fee1c50 in tls_construct_server_certificate ssl/statem/statem_srvr.c:3812
#10 0x7f3a8feb8b0a in write_state_machine ssl/statem/statem.c:843
#11 0x7f3a8feb8b0a in state_machine ssl/statem/statem.c:443
#12 0x7f3a8fe84b3f in SSL_do_handshake ssl/ssl_lib.c:3718
#13 0x403202 in FuzzerTestOneInput fuzz/server.c:740
#14 0x40371b in testfile fuzz/test-corpus.c:182
#15 0x402856 in main fuzz/test-corpus.c:226
#16 0x7f3a8e859f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#17 0x402936 (/home/ed/OPC/openssl/fuzz/server-test+0x402936)
AddressSanitizer:DEADLYSIGNAL
=================================================================
==8400==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000158 (pc 0x7f3a8f4d822f bp 0x7ffc39b76190 sp 0x7ffc39b760a0 T0)
==8400==The signal is caused by a READ memory access.
==8400==Hint: address points to the zero page.
#0 0x7f3a8f4d822f in x509v3_cache_extensions crypto/x509v3/v3_purp.c:386
#1 0x7f3a8f4d9d3a in X509_check_purpose crypto/x509v3/v3_purp.c:84
#2 0x7f3a8f4da02a in X509_get_extension_flags crypto/x509v3/v3_purp.c:921
#3 0x7f3a8feff7d2 in ssl_security_cert_sig ssl/t1_lib.c:2518
#4 0x7f3a8feff7d2 in ssl_security_cert ssl/t1_lib.c:2542
#5 0x7f3a8feffa03 in ssl_security_cert_chain ssl/t1_lib.c:2562
#6 0x7f3a8fed728d in ssl_add_cert_chain ssl/statem/statem_lib.c:963
#7 0x7f3a8fed728d in ssl3_output_cert_chain ssl/statem/statem_lib.c:1015
#8 0x7f3a8fee1c50 in tls_construct_server_certificate ssl/statem/statem_srvr.c:3812
#9 0x7f3a8feb8b0a in write_state_machine ssl/statem/statem.c:843
#10 0x7f3a8feb8b0a in state_machine ssl/statem/statem.c:443
#11 0x7f3a8fe84b3f in SSL_do_handshake ssl/ssl_lib.c:3718
#12 0x403202 in FuzzerTestOneInput fuzz/server.c:740
#13 0x40371b in testfile fuzz/test-corpus.c:182
#14 0x402856 in main fuzz/test-corpus.c:226
#15 0x7f3a8e859f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#16 0x402936 (/home/ed/OPC/openssl/fuzz/server-test+0x402936)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV crypto/x509v3/v3_purp.c:386 in x509v3_cache_extensions
==8400==ABORTING
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18376)
(cherry picked from commit dc0ef292f7)
rotated_mac is a 64-byte aligned buffer of size 64 and rotate_offset is secret.
Consider a weaker leakage model(CL) where only cacheline base address is leaked,
i.e address/32 for 32-byte cacheline(CL32).
Previous code used to perform two loads
1. rotated_mac[rotate_offset ^ 32] and
2. rotated_mac[rotate_offset++]
which would leak 2q + 1, 2q for 0 <= rotate_offset < 32
and 2q, 2q + 1 for 32 <= rotate_offset < 64
The proposed fix performs load operations which will always leak 2q, 2q + 1 and
selects the appropriate value in constant-time.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18050)
This allows handshake to proceed if the maximum TLS version enabled is <1.3
Fixes#13583
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18213)
This fixes an internal error alert from the server and
an unexpected connection failure in the release version,
but a failed assertion and a server crash in the
debug version.
Reproduce this issue with a DTLS server/client like that:
./openssl s_server -dtls -mtu 1500
./openssl s_client -dtls -maxfraglen 512
In the debug version a crash happens in the Server now:
./openssl s_server -dtls -mtu 1500
Using default temp DH parameters
ACCEPT
ssl/statem/statem_dtls.c:269: OpenSSL internal error: Assertion failed: len == written
Aborted (core dumped)
While in the release version the handshake exceeds the
negotiated max fragment size, and fails because of this:
$ ./openssl s_server -dtls -mtu 1500
Using default temp DH parameters
ACCEPT
ERROR
4057152ADA7F0000:error:0A0000C2:SSL routines:do_dtls1_write:exceeds max fragment size:ssl/record/rec_layer_d1.c:826:
shutting down SSL
CONNECTION CLOSED
From the client's point of view the connection fails
with an Internal Error Alert:
$ ./openssl s_client -dtls -maxfraglen 512
Connecting to ::1
CONNECTED(00000003)
40B76343377F0000:error:0A000438:SSL routines:dtls1_read_bytes:tlsv1 alert internal error:ssl/record/rec_layer_d1.c:613:SSL alert number 80
and now the connection attempt fails unexpectedly.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18093)
(cherry picked from commit e915c3f538)
This causes the DTLS server to enter an error state:
./openssl s_server -dtls
./openssl s_client -dtls -maxfraglen 512 -sess_out s1.txt
[...]
Q
./openssl s_client -dtls -sess_in s1.txt
CONNECTED(00000003)
^C
./openssl s_client -dtls
CONNECTED(00000003)
140335537067840:error:14102410:SSL routines:dtls1_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_d1.c:614:SSL alert number 40
At this point the dtls server needs to be restarted,
because verify_cookie_callback always fails, because
the previous cookie is checked against the current one.
The reason for this is not fully understood.
In wireshark we see the following each time:
c->s Client Hello (without cookie)
s->c Hello Verify Request (with new cookie)
s->c Alert (Level: Fatal, Description: Handshake Failure)
c->s Client Hello (echoes new cookie)
The client gives up when the Alert arrives.
The Alert is triggered because the server calls
verify_cookie_callback with the previous cookie,
although it just sent the current cookie in the
Hello Verify Request.
However this does only happen because no Alert message
is sent when the client re-connects the session with
the missing -maxfraglen option.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18094)
Even though the function is not part of the public api, it is not
entirely removed, in order to minimize the chance of breakage,
because it is exported from libcrypto. Instead, we keep a dummy
implementation.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17975)
A cherry-pick from the master branch incorrectly introduced a usage of
3 argument SSLfatal. In 1.1.1 the function code is also required.
Fixes#17999
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18000)
For TLSv1.3, limit ticket lifetime hint to 1 week per RFC8446
Fixes#17948
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17952)
(cherry picked from commit 0089cc7f9d)
time_t is a 64 bits type on this platform.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17917)
(cherry picked from commit 9362638b08)
`SSL_kECDHE` and `SSL_kEECDH`, and `SSL_kDHE` and `SSL_kEDH` are already
marked as aliases of each other in the headers.
This commit, for each pair, replaces the leftover uses of the latter
synonym with the first one, which is considered more common.
(manually cherry picked from commit 66914fc024)
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17791)
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 07f620e3ac)
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 cbb862fbaa)
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)
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)
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 0449702abc)
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 ca00152497)
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 e54f0c9b2f)
Tomas Mraz
yangyangtiantianlonglong
Richard Levitte
Matt Caswell
Todd C. Miller
Daniel Fiala
Pauli
Bernd Edlinger
basavesh
Hugo Landau
Dr. Matthias St. Pierre
Todd Short
David Carlier
Nicola Tuveri
Dr. David von Oheimb
Dmitry Belyavskiy
x2018
Tianjia Zhang
Todd Short