OpenSSL 3.0.8 "SSL routines internal error (s3_enc.c:354)" #21422
Labels
triaged: bug
The issue/pr is/fixes a bug
Comments
That error is a fundamental very low-level "should not happen" failure: Lines 352 to 356 in 31157bc
I don't know if you are able to do some debugging to figure out what is causing it to fail? |
mattcaswell
added
triaged: bug
Sure. Server is mine. Just provide some direction. Thanks. |
|
Let's start with some simple checks. If you can set a breakpoint on the SSLfatal line above and discover the value of |
|
Matt, this is pre- built and packaged OpenVMS release of OpenSSL. Such requests are difficult (but not entirely impossible) for me. This one needs to be considered accessible from the outside if at all possible. I could at a pinch obtain the appropriate OpenSSL tarball and build from scratch but it will be a long and drawn-out process on a 20 year old architecture. The code reporting
is from a callback that is expressed If the error could be detected in there and the relevant measurement initiated from there, that would be eminently doable. Note: that underlying bio is essentially used an a (convoluted) asynch mode. The above report example is itself called from so the underlying pointer to SSL struct is available for access (1) and use (2). |
|
OK, I have obtained the 3.0.8 tarball (equivalent to original reported issue release) and built local libraries, adding the debug statement: and issued the previously documented s_client request with the corresponding output in the server log I am now in a position to add debug statements as requested. |
|
Hmmm....and you still see the |
|
Here's a fresh one, just generated Matt. with associated log entries What does this one represent then? |
|
Ah...sorry. Somehow I missed that important line. The 0 len/ret value does look suspicious Does the debugging log output correspond to exactly one handshake? |
|
Please also add this additional logging: diff --git a/ssl/statem/statem_lib.c b/ssl/statem/statem_lib.c
index bcce73bcdc..0268ffa144 100644
--- a/ssl/statem/statem_lib.c
+++ b/ssl/statem/statem_lib.c
@@ -57,11 +57,13 @@ int ssl3_do_write(SSL *s, int type)
*/
if (!SSL_IS_TLS13(s) || (s->statem.hand_state != TLS_ST_SW_SESSION_TICKET
&& s->statem.hand_state != TLS_ST_CW_KEY_UPDATE
- && s->statem.hand_state != TLS_ST_SW_KEY_UPDATE))
+ && s->statem.hand_state != TLS_ST_SW_KEY_UPDATE)) {
+ printf("++++++ In ssl3_do_write. written is %u, init_num is %u\n", (unsigned int)written, (unsigned int)s->init_num);
if (!ssl3_finish_mac(s,
(unsigned char *)&s->init_buf->data[s->init_off],
written))
return -1;
+ }
if (written == s->init_num) {
if (s->msg_callback)
s->msg_callback(1, s->version, type, s->init_buf->data,
@@ -1305,6 +1307,7 @@ int tls_get_message_body(SSL *s, size_t *len)
/* Feed this message into MAC computation. */
if (RECORD_LAYER_is_sslv2_record(&s->rlayer)) {
+ printf("++++++ In tls_get_message_body (SSLv2 record). init_num is %u\n", (unsigned int)s->init_num);
if (!ssl3_finish_mac(s, (unsigned char *)s->init_buf->data,
s->init_num)) {
/* SSLfatal() already called */
|
|
|
Please could you try applying the patch below? diff --git a/ssl/statem/statem_lib.c b/ssl/statem/statem_lib.c
index 0268ffa144..0fd71f3d4b 100644
--- a/ssl/statem/statem_lib.c
+++ b/ssl/statem/statem_lib.c
@@ -49,7 +49,7 @@ int ssl3_do_write(SSL *s, int type)
s->init_num, &written);
if (ret < 0)
return -1;
- if (type == SSL3_RT_HANDSHAKE)
+ if (type == SSL3_RT_HANDSHAKE && written > 0)
/*
* should not be done for 'Hello Request's, but in that case we'll
* ignore the result anyway |
|
BINGO!! |
mattcaswell
added a commit
to mattcaswell/openssl
that referenced
this issue
Jul 12, 2023
A BIO is documented to return -1 on write retry - but sometimes they return 0. ssl3_do_write() was incorrectly handling a 0 response. Fixes openssl#21422
mattcaswell
added a commit
to mattcaswell/openssl
that referenced
this issue
Jul 12, 2023
A BIO is documented to return -1 on write retry - but sometimes they return 0. ssl3_do_write() was incorrectly handling a 0 response. Fixes openssl#21422
mattcaswell
added a commit
to mattcaswell/openssl
that referenced
this issue
Jul 12, 2023
A BIO is documented to return -1 on write retry - but sometimes they return 0. ssl3_do_write() was incorrectly handling a 0 response. Fixes openssl#21422
|
PR to fix this in #21434 (master) and #21435 (3.1/3.0). I was able to reproduce this problem locally after a bit of experimentation. It turns out to be quite tricky to hit. The scenario where I could get this to happen was:
There might be other scenarios where this occurs but this was the only one I found. In the end I went with a slightly different fix to the one I originally proposed above. |
|
It was noted in opening the issue, "(problem exhibited also when build against OpenSSL 1.1.1t)", but I see mention of "3.1/3.0 only (master is not affected)", nothing of the 1.1.1 branch. I know it's reaching EOL but with LTS. Just a thought. |
|
In the last year of LTS support we only typically accept security fixes. Since this isn't a security fix it isn't eligible for backport to 1.1.1. |
bernd-edlinger
pushed a commit
to bernd-edlinger/openssl
that referenced
this issue
Jul 19, 2023
A BIO is documented to return -1 on write retry - but sometimes they return 0. ssl3_do_write() was incorrectly handling a 0 response. Fixes openssl#21422 Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#21435) (cherry picked from commit 034ea1d)
bernd-edlinger
pushed a commit
to bernd-edlinger/openssl
that referenced
this issue
Jul 19, 2023
A BIO is documented to return -1 on write retry - but sometimes they return 0. ssl3_do_write() was incorrectly handling a 0 response. Fixes openssl#21422 Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#21435) (cherry picked from commit 034ea1d)
bernd-edlinger
pushed a commit
to bernd-edlinger/openssl
that referenced
this issue
Aug 1, 2023
A BIO is documented to return -1 on write retry - but sometimes they return 0. ssl3_do_write() was incorrectly handling a 0 response. Fixes openssl#21422 Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#21435) (cherry picked from commit 034ea1d)
bernd-edlinger
pushed a commit
to bernd-edlinger/openssl
that referenced
this issue
Aug 19, 2023
A BIO is documented to return -1 on write retry - but sometimes they return 0. ssl3_do_write() was incorrectly handling a 0 response. Fixes openssl#21422 Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#21435) (cherry picked from commit 034ea1d)
bernd-edlinger
pushed a commit
to bernd-edlinger/openssl
that referenced
this issue
Sep 12, 2023
A BIO is documented to return -1 on write retry - but sometimes they return 0. ssl3_do_write() was incorrectly handling a 0 response. Fixes openssl#21422 Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#21435) (cherry picked from commit 034ea1d)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
SSL3 for OpenVMS V3.0(8) Apr 10 2023 (Library: SSL3 for OpenVMS V3.0(8) Apr 10 2023)
(problem exhibited also when build against OpenSSL 1.1.1t)
The server, for TLSv1.2, uses renegotiation for requesting a client certificate be provided (for authentication/authorisation).
I have been chasing the the reason for the above error and it appears to be related to the server certificate in use! A current Let's Encrypt issued server cert results in the above error very early in the renegotiation. A self-signed server cert does not. I have no third alternative to try.
Using the s_client to make the request:
$ openssl s_client -cert clientl.pem -tls1_2 -state -nbio -connect host-name:443and the server reports:
I have sought a way to reproduce this using s_server (to make the investigation platform-neutral) but cannot seem to trigger the renegotiation to include the client cert.
Just to repeat, this works with no other change than the server cert from LE to self-signed.
TLSv1.3 also works without issue with both server certs but of course that is via the entirely separate PHA mechanism.
The text was updated successfully, but these errors were encountered: