SSL_new_session_ticket() support for QUIC #26
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@nibanks I had to tweak the patch a little since the initial version, as it had broken the ability to call |
nibanks
approved these changes
Apr 9, 2021
tmshort
changed the base branch from
openssl-3.0.0-alpha13+quic
to
openssl-3.0.0-alpha14+quic
tmshort
changed the base branch from
openssl-3.0.0-alpha14+quic
to
openssl-3.0.0-alpha13+quic
|
Now that alpha14 is out, can you change the destination to that? New PR is likely required. |
|
Changing the destination works better on bitbucket than on github. :( |
The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data.
Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play.
Document the recently added functionality.
kaduk
changed the base branch from
openssl-3.0.0-alpha13+quic
to
openssl-3.0.0-alpha14+quic
|
I tried changing the base (then force-pushing the rebased branch). |
tmshort
reviewed
Apr 9, 2021
| || !SSL_IS_TLS13(s)) | ||
| return 0; | ||
| s->ext.extra_tickets_expected++; | ||
| if (s->rlayer.wbuf[0].left == 0 && !SSL_in_init(s)) | ||
| ossl_statem_set_in_init(s, 1); |
There was a problem hiding this comment.
This is the same check for "are we at a record boundary" that's already used (for non-QUIC) at the start of ssl3_write_bytes() where we would otherwise be writing the tickets out. The point of this commit is to evaluate the condition when SSL_new_session_ticket() is called instead of waiting until an application-data write to check.
There was a problem hiding this comment.
Just wanted to make sure nothing bad happened in that case!
There was a problem hiding this comment.
It's a good question to ask!
I believe it is fine, though, and the test coverage here is pretty good.
tmshort
approved these changes
Apr 9, 2021
tmshort
pushed a commit
that referenced
this pull request
Apr 12, 2021
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
tmshort
pushed a commit
that referenced
this pull request
May 20, 2021
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality.
tmshort
pushed a commit
that referenced
this pull request
May 20, 2021
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality.
tmshort
pushed a commit
that referenced
this pull request
Aug 24, 2021
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
tmshort
pushed a commit
that referenced
this pull request
Dec 14, 2021
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
tmshort
pushed a commit
that referenced
this pull request
Mar 15, 2022
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
tmshort
pushed a commit
that referenced
this pull request
Mar 15, 2022
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
tmshort
pushed a commit
that referenced
this pull request
May 3, 2022
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
tmshort
pushed a commit
that referenced
this pull request
Jun 21, 2022
This can be reproduced 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=1653520461 ../util/shlib_wrap.sh ./cms-test ./corpora/cms/3eff1d2f1232bd66d5635db2c3f9e7f23830dfd1
log file: cms-3eff1d2f1232bd66d5635db2c3f9e7f23830dfd1-32454-test.out
ERROR_INJECT=1653520461
#0 0x7fd5d8b8eeba in __sanitizer_print_stack_trace ../../../../gcc-trunk/libsanitizer/asan/asan_stack.cpp:87
#1 0x402fc4 in my_realloc fuzz/test-corpus.c:129
#2 0x7fd5d8893c49 in sk_reserve crypto/stack/stack.c:198
#3 0x7fd5d8893c49 in OPENSSL_sk_insert crypto/stack/stack.c:242
#4 0x7fd5d88d6d7f in sk_GENERAL_NAMES_push include/openssl/x509v3.h:168
#5 0x7fd5d88d6d7f in crl_set_issuers crypto/x509/x_crl.c:111
#6 0x7fd5d88d6d7f in crl_cb crypto/x509/x_crl.c:246
#7 0x7fd5d85dc032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#8 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#9 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#10 0x7fd5d85db2b5 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:259
#11 0x7fd5d85dc813 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:611
#12 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#13 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#14 0x7fd5d85dca28 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:633
#15 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#16 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#17 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#18 0x7fd5d85dd7d3 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:494
#19 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#20 0x7fd5d85ddd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#21 0x7fd5d85dde35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#22 0x7fd5d85a77e0 in ASN1_item_d2i_bio crypto/asn1/a_d2i_fp.c:69
#23 0x402845 in FuzzerTestOneInput fuzz/cms.c:43
#24 0x402bbb in testfile fuzz/test-corpus.c:182
#25 0x402626 in main fuzz/test-corpus.c:226
#26 0x7fd5d7c81f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#27 0x402706 (/home/ed/OPC/openssl/fuzz/cms-test+0x402706)
=================================================================
==29625==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fd5d8b8309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fd5d87c2430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fd5d889501f in OPENSSL_sk_new_reserve crypto/stack/stack.c:209
#3 0x7fd5d85dcbc3 in sk_ASN1_VALUE_new_null include/openssl/asn1t.h:928
#4 0x7fd5d85dcbc3 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:577
#5 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#6 0x7fd5d85db104 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:178
#7 0x7fd5d85ddd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#8 0x7fd5d85dde35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#9 0x7fd5d88f86d9 in X509V3_EXT_d2i crypto/x509v3/v3_lib.c:142
#10 0x7fd5d88d6d3c in crl_set_issuers crypto/x509/x_crl.c:97
#11 0x7fd5d88d6d3c in crl_cb crypto/x509/x_crl.c:246
#12 0x7fd5d85dc032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#13 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#14 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#15 0x7fd5d85db2b5 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:259
#16 0x7fd5d85dc813 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:611
#17 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#18 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#19 0x7fd5d85dca28 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:633
#20 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#21 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#22 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#23 0x7fd5d85dd7d3 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:494
#24 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#25 0x7fd5d85ddd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#26 0x7fd5d85dde35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#27 0x7fd5d85a77e0 in ASN1_item_d2i_bio crypto/asn1/a_d2i_fp.c:69
#28 0x402845 in FuzzerTestOneInput fuzz/cms.c:43
#29 0x402bbb in testfile fuzz/test-corpus.c:182
#30 0x402626 in main fuzz/test-corpus.c:226
openssl#31 0x7fd5d7c81f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s).
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from openssl#18391)
(cherry picked from commit e9007e0)
tmshort
pushed a commit
that referenced
this pull request
Jun 21, 2022
This can be reproduced 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=1653520461 ../util/shlib_wrap.sh ./cms-test ./corpora/cms/3eff1d2f1232bd66d5635db2c3f9e7f23830dfd1
log file: cms-3eff1d2f1232bd66d5635db2c3f9e7f23830dfd1-32454-test.out
ERROR_INJECT=1653520461
#0 0x7fd5d8b8eeba in __sanitizer_print_stack_trace ../../../../gcc-trunk/libsanitizer/asan/asan_stack.cpp:87
#1 0x402fc4 in my_realloc fuzz/test-corpus.c:129
#2 0x7fd5d8893c49 in sk_reserve crypto/stack/stack.c:198
#3 0x7fd5d8893c49 in OPENSSL_sk_insert crypto/stack/stack.c:242
#4 0x7fd5d88d6d7f in sk_GENERAL_NAMES_push include/openssl/x509v3.h:168
#5 0x7fd5d88d6d7f in crl_set_issuers crypto/x509/x_crl.c:111
#6 0x7fd5d88d6d7f in crl_cb crypto/x509/x_crl.c:246
#7 0x7fd5d85dc032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#8 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#9 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#10 0x7fd5d85db2b5 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:259
#11 0x7fd5d85dc813 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:611
#12 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#13 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#14 0x7fd5d85dca28 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:633
#15 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#16 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#17 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#18 0x7fd5d85dd7d3 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:494
#19 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#20 0x7fd5d85ddd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#21 0x7fd5d85dde35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#22 0x7fd5d85a77e0 in ASN1_item_d2i_bio crypto/asn1/a_d2i_fp.c:69
#23 0x402845 in FuzzerTestOneInput fuzz/cms.c:43
#24 0x402bbb in testfile fuzz/test-corpus.c:182
#25 0x402626 in main fuzz/test-corpus.c:226
#26 0x7fd5d7c81f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#27 0x402706 (/home/ed/OPC/openssl/fuzz/cms-test+0x402706)
=================================================================
==29625==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fd5d8b8309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fd5d87c2430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fd5d889501f in OPENSSL_sk_new_reserve crypto/stack/stack.c:209
#3 0x7fd5d85dcbc3 in sk_ASN1_VALUE_new_null include/openssl/asn1t.h:928
#4 0x7fd5d85dcbc3 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:577
#5 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#6 0x7fd5d85db104 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:178
#7 0x7fd5d85ddd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#8 0x7fd5d85dde35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#9 0x7fd5d88f86d9 in X509V3_EXT_d2i crypto/x509v3/v3_lib.c:142
#10 0x7fd5d88d6d3c in crl_set_issuers crypto/x509/x_crl.c:97
#11 0x7fd5d88d6d3c in crl_cb crypto/x509/x_crl.c:246
#12 0x7fd5d85dc032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#13 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#14 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#15 0x7fd5d85db2b5 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:259
#16 0x7fd5d85dc813 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:611
#17 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#18 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#19 0x7fd5d85dca28 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:633
#20 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#21 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#22 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#23 0x7fd5d85dd7d3 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:494
#24 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#25 0x7fd5d85ddd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#26 0x7fd5d85dde35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#27 0x7fd5d85a77e0 in ASN1_item_d2i_bio crypto/asn1/a_d2i_fp.c:69
#28 0x402845 in FuzzerTestOneInput fuzz/cms.c:43
#29 0x402bbb in testfile fuzz/test-corpus.c:182
#30 0x402626 in main fuzz/test-corpus.c:226
openssl#31 0x7fd5d7c81f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s).
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from openssl#18391)
(cherry picked from commit e9007e0)
tmshort
pushed a commit
that referenced
this pull request
Jun 21, 2022
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
tmshort
pushed a commit
that referenced
this pull request
Jul 5, 2022
This can be reproduced 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=1656112173 ../util/shlib_wrap.sh ./x509-test ./corpora/x509/fe543a8d7e09109a9a08114323eefec802ad79e2
#0 0x7fb61945eeba in __sanitizer_print_stack_trace ../../../../gcc-trunk/libsanitizer/asan/asan_stack.cpp:87
#1 0x402f84 in my_malloc fuzz/test-corpus.c:114
#2 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#3 0x7fb618ef7561 in bn_expand_internal crypto/bn/bn_lib.c:280
#4 0x7fb618ef7561 in bn_expand2 crypto/bn/bn_lib.c:304
#5 0x7fb618ef819d in BN_bin2bn crypto/bn/bn_lib.c:454
#6 0x7fb618e7aa13 in asn1_string_to_bn crypto/asn1/a_int.c:503
#7 0x7fb618e7aa13 in ASN1_INTEGER_to_BN crypto/asn1/a_int.c:559
#8 0x7fb618fd8e79 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:814
#9 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#10 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#11 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#12 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#13 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#14 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#15 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#16 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#17 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#18 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#19 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#20 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#21 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#22 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#23 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#24 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#25 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#26 0x402afb in testfile fuzz/test-corpus.c:182
#27 0x402656 in main fuzz/test-corpus.c:226
#28 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#29 0x402756 (/home/ed/OPC/openssl/fuzz/x509-test+0x402756)
=================================================================
==12221==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fb61945309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fb618ef5f11 in BN_new crypto/bn/bn_lib.c:246
#3 0x7fb618ef82f4 in BN_bin2bn crypto/bn/bn_lib.c:440
#4 0x7fb618fd8933 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:618
#5 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#6 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#7 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#8 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#9 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#10 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#11 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#12 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#13 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#14 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#15 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#16 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#17 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#18 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#19 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#20 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#21 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#22 0x402afb in testfile fuzz/test-corpus.c:182
#23 0x402656 in main fuzz/test-corpus.c:226
#24 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
Indirect leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7fb61945309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fb618ef7561 in bn_expand_internal crypto/bn/bn_lib.c:280
#3 0x7fb618ef7561 in bn_expand2 crypto/bn/bn_lib.c:304
#4 0x7fb618ef819d in BN_bin2bn crypto/bn/bn_lib.c:454
#5 0x7fb618fd8933 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:618
#6 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#7 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#8 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#9 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#10 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#11 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#12 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#13 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#14 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#15 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#16 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#17 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#18 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#19 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#20 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#21 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#22 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#23 0x402afb in testfile fuzz/test-corpus.c:182
#24 0x402656 in main fuzz/test-corpus.c:226
#25 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from openssl#18633)
(cherry picked from commit be50862)
tmshort
pushed a commit
that referenced
this pull request
Jul 5, 2022
This can be reproduced 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=1656112173 ../util/shlib_wrap.sh ./x509-test ./corpora/x509/fe543a8d7e09109a9a08114323eefec802ad79e2
#0 0x7fb61945eeba in __sanitizer_print_stack_trace ../../../../gcc-trunk/libsanitizer/asan/asan_stack.cpp:87
#1 0x402f84 in my_malloc fuzz/test-corpus.c:114
#2 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#3 0x7fb618ef7561 in bn_expand_internal crypto/bn/bn_lib.c:280
#4 0x7fb618ef7561 in bn_expand2 crypto/bn/bn_lib.c:304
#5 0x7fb618ef819d in BN_bin2bn crypto/bn/bn_lib.c:454
#6 0x7fb618e7aa13 in asn1_string_to_bn crypto/asn1/a_int.c:503
#7 0x7fb618e7aa13 in ASN1_INTEGER_to_BN crypto/asn1/a_int.c:559
#8 0x7fb618fd8e79 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:814
#9 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#10 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#11 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#12 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#13 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#14 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#15 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#16 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#17 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#18 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#19 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#20 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#21 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#22 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#23 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#24 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#25 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#26 0x402afb in testfile fuzz/test-corpus.c:182
#27 0x402656 in main fuzz/test-corpus.c:226
#28 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#29 0x402756 (/home/ed/OPC/openssl/fuzz/x509-test+0x402756)
=================================================================
==12221==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fb61945309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fb618ef5f11 in BN_new crypto/bn/bn_lib.c:246
#3 0x7fb618ef82f4 in BN_bin2bn crypto/bn/bn_lib.c:440
#4 0x7fb618fd8933 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:618
#5 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#6 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#7 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#8 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#9 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#10 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#11 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#12 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#13 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#14 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#15 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#16 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#17 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#18 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#19 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#20 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#21 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#22 0x402afb in testfile fuzz/test-corpus.c:182
#23 0x402656 in main fuzz/test-corpus.c:226
#24 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
Indirect leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7fb61945309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fb618ef7561 in bn_expand_internal crypto/bn/bn_lib.c:280
#3 0x7fb618ef7561 in bn_expand2 crypto/bn/bn_lib.c:304
#4 0x7fb618ef819d in BN_bin2bn crypto/bn/bn_lib.c:454
#5 0x7fb618fd8933 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:618
#6 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#7 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#8 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#9 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#10 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#11 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#12 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#13 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#14 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#15 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#16 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#17 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#18 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#19 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#20 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#21 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#22 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#23 0x402afb in testfile fuzz/test-corpus.c:182
#24 0x402656 in main fuzz/test-corpus.c:226
#25 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from openssl#18632)
tmshort
pushed a commit
that referenced
this pull request
Jul 5, 2022
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
tmshort
pushed a commit
that referenced
this pull request
Oct 11, 2022
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
tmshort
pushed a commit
that referenced
this pull request
Nov 1, 2022
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
wbl
pushed a commit
that referenced
this pull request
Feb 7, 2023
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
wbl
pushed a commit
that referenced
this pull request
May 30, 2023
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
wbl
pushed a commit
that referenced
this pull request
May 30, 2023
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
tmshort
pushed a commit
that referenced
this pull request
Aug 2, 2023
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
tmshort
pushed a commit
that referenced
this pull request
Sep 22, 2023
* Let SSL_new_session_ticket() work immediately The initial implementation always deferred the generation of the requested ticket(s) until the next application write, but this means that the ticket cannot be written at all until there is application data ready to write. In some scenarios this application data may never arrive or may take a long time to arrive, so (when already at a record boundary) allow the application to explicitly call SSL_do_handshake() after SSL_new_session_ticket() to force an immediate write, even when there is no application data available. The default behavior remains to defer the generation of the ticket and coalesce the network traffic for the ticket and application data. * Test new SSL_new_session_ticket() functionality Now that we can become "in init" directly after the call, test the various scenarios where explicit SSL_do_handshake() calls can come into play. * Update SSL_new_session_ticket() manual for triggered send Document the recently added functionality. (cherry picked from commit 4fb1ff7)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Check if we are at a safe place in the record layer when
SSL_new_session_ticket()is called, and enter 'init' immediately in that case, instead of waiting until ssl3_write_bytes() (which is never called for QUIC).This allows the generation of the ticket to be triggered directly by
SSL_do_handshake().Checklist