feedc0de/wolfssl
1
0
Fork 0
forked from wolfSSL/wolfssl
Code Pull Requests Activity

Consider downgrade to TLS 1.2 when parsing CKS.

Browse Source
This commit is contained in:
Anthony Hu
2024-10-30 16:50:59 -04:00
parent 57a5895d0e
commit 69f2529aa5
1 changed files with 12 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
src/tls.c
View File

@@ -9957,6 +9957,16 @@ int TLSX_CKS_Parse(WOLFSSL* ssl, byte* input, word16 length,
}
}
/* This could be a situation where the client tried to start with TLS 1.3
* when it sent ClientHello and the server down-graded to TLS 1.2. In that
* case, erroring out because it is TLS 1.2 is not a reasonable thing to do.
* In the case of TLS 1.2, the CKS values will be ignored. */
if (!IsAtLeastTLSv1_3(ssl->version)) {
ssl->sigSpec = NULL;
ssl->sigSpecSz = 0;
return 0;
}
/* Extension data is valid, but if we are the server and we don't have an
* alt private key, do not respond with CKS extension. */
if (wolfSSL_is_server(ssl) && ssl->buffers.altKey == NULL) {
@@ -15038,9 +15048,8 @@ int TLSX_Parse(WOLFSSL* ssl, const byte* input, word16 length, byte msgType,
#ifdef WOLFSSL_DUAL_ALG_CERTS
case TLSX_CKS:
WOLFSSL_MSG("CKS extension received");
if (!IsAtLeastTLSv1_3(ssl->version) ||
(msgType != client_hello &&
msgType != encrypted_extensions)) {
if (msgType != client_hello &&
msgType != encrypted_extensions) {
WOLFSSL_ERROR_VERBOSE(EXT_NOT_ALLOWED);
return EXT_NOT_ALLOWED;
}