-
-
Notifications
You must be signed in to change notification settings - Fork 9.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERR_reason_error_string()
returns NULL
for no_application_protocol
alert
#24300
Comments
The alert message seems to be correct to me. From the TLS 1.3 RFC The alert message is one of the values (1,2) (representing warning, fatal), concatenated with the actual message value, in this case no application protocol (defined as 120, both in the rfc, and in the code as TLS1_AD_NO_APPLICATION_PROTOCOL). this matches the value reported in the error you see in your report The 1 in the 1120 values you are referencing I believe are pre-concatenated values showing both the severity value and the alert value I believe SSL_R_NO_APPLICATION_PROTOCOL is a library internal error encoding value. As to the reason this got reported, there is only one reason: The peer on your connection sent an alert message with that value in the alert field. Its a bit odd that you would receive that message while doing an ssl_read, as nominally the ALPN is exchanged as part of the client hello message during the handshake. I suppose its feasible that a peer would allow for no ALPN to be negotiated during the handshake and then error out when none is established during data exchange, but again, odd. Edit: As for the lack of reason string with the error, it appears there is not number->string mapping that exists inlibssl. there is one in one of the test libraries, but generally speaking tls alerts appear to be reported in the error stack as their numerical values. |
Right, this is the focus of my report.
As far as I can tell, many other alerts get correctly mapped to their reason strings. My patch appears to fix that for this case. (But whether the fix is the correct approach, I don't know.) |
Ok, fair enough, can you open a PR with the changes reference for review please? |
Attempts to fix openssl#24300. The current SSL_R_NO_APPLICATION_PROTOCOL value doesn't allow for a correct lookup of the reason string. TODOs: - what should we do with SSL_R_NO_APPLICATION_PROTOCOL? - what's the most straightforward way to test this? - how should this be ported to HEAD in light of openssl#19950?
Fixes openssl#24300. The current SSL_R_NO_APPLICATION_PROTOCOL value doesn't allow for a correct lookup of the reason string. TODOs: - what's the most straightforward way to test this? - what should we do with SSL_R_NO_APPLICATION_PROTOCOL? - how should this be ported to HEAD in light of openssl#19950? CLA: trivial
@nhorman Done; I've moved my open questions into that PR. Thanks! |
Fixes openssl#24300. The current values of SSL_R_NO_APPLICATION_PROTOCOL and SSL_R_PSK_IDENTITY_NOT_FOUND don't allow for a correct lookup of the corresponding reason strings. CLA: trivial
Fixes openssl#24300. The current values of SSL_R_NO_APPLICATION_PROTOCOL and SSL_R_PSK_IDENTITY_NOT_FOUND don't allow for a correct lookup of the corresponding reason strings. CLA: trivial
Fixes #24300. The current values of SSL_R_NO_APPLICATION_PROTOCOL and SSL_R_PSK_IDENTITY_NOT_FOUND don't allow for a correct lookup of the corresponding reason strings. CLA: trivial Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #24351) (cherry picked from commit a401aaf)
Fixes #24300. The current values of SSL_R_NO_APPLICATION_PROTOCOL and SSL_R_PSK_IDENTITY_NOT_FOUND don't allow for a correct lookup of the corresponding reason strings. CLA: trivial Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #24351) (cherry picked from commit a401aaf)
Fixes #24300. The current values of SSL_R_NO_APPLICATION_PROTOCOL and SSL_R_PSK_IDENTITY_NOT_FOUND don't allow for a correct lookup of the corresponding reason strings. CLA: trivial Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #24338) (cherry picked from commit 9e33c9c)
Thanks everybody! |
Fixes openssl#24300. The current values of SSL_R_NO_APPLICATION_PROTOCOL and SSL_R_PSK_IDENTITY_NOT_FOUND don't allow for a correct lookup of the corresponding reason strings. CLA: trivial Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#24351)
Hello all,
OpenSSL 3.0 doesn't correctly report a reason string when handling the
no_application_protocol
alert; instead,ERR_reason_error_string()
returnsNULL
.ERR_print_errors()
and friends are similarly unhelpful:From inspection, later versions of OpenSSL 3.x also have this issue, but I haven't tested with all of them.
To my eyes, it looks like the lookup machinery expects the reason code to be 1120 (that is,
SSL_AD_REASON_OFFSET + TLS1_AD_NO_APPLICATION_PROTOCOL
), butSSL_R_NO_APPLICATION_PROTOCOL
is defined to be 235.I'm suspicious that the
unknown_psk_identity
alert may have the same issue, sinceSSL_R_PSK_IDENTITY_NOT_FOUND
is defined as 223 and not 1115.Here is a sample patch. If this looks close to right, I can open a pull request, but I'm unsure what to do with the existing
SSL_R_NO_APPLICATION_PROTOCOL
code.Thanks!
The text was updated successfully, but these errors were encountered: