This commit fixes a few places where new signature schemes were not added:
1) It adds ECDSA with the Brainpool curves for TLS 1.3 (0x081a, 0x081b, and 0x081c) to get_server_certificate(), certificate_transparency(), and prepare_tls_clienthello().
2) It adds rsa_pss_pss (0x0809, 0x080a, 0x080b) to certificate_transparency().
3) It adds the signature schemes for EdDSA (0x0807, 0x0808) and ML-DSA (0x0904, 0x0905, 0x0906) to certificate_transparency().
When $OPENSSL s_client supports the "-sigalgs" option, get_server_certificate() uses $OPENSSL rather than tls_sockets() to obtain the server's certificate, but only for certificates with RSA and ECDSA public keys.
With OpenSSL 3.5 and newer the list command can be used to get a list of supported TLS signature algorithms.
With this commit, if OpenSSL 3.5 or newer is being used, the list of supported TLS signature algorithms is obtained and get_server_certificate() uses $OPENSSL s_client rather than tls_sockets() whenever $OPENSSL supports the relevant signature scheme.
In addition to making the code a bit faster, this may be helpful if a server has a certificate with an SM2 public key and it only supports curveSM2 for key exchange, since tls_sockets() can not decrypt server responses if curveSM2 is used.
It seems that OpenSSL 4.0.0 allows for the possibility that a server's response to the status request extension may include more than one OCSP response (presumably one for each certificate in the certification path).
As a result, the line indicating that the server does not provide status information was changed from "OCSP response: no response sent" to "OCSP responses: no responses sent". If a response was included, "OCSP responses:" is followed by an indication of the number of responses included.
This commit addresses the change from "response" to "responses".
I do not know of any servers that provide more than one OCSP response, so I have not tried to make any changes to handle more than one response.
This commit cleans up the initialization of TLS13_KEY_SHARES and TLS13_PUBLIC_KEY_SHARES in etc/tls_data.txt. With this commit, each index in the array that is to be initialized is prefixed with "[0xXX]=". This allows all of the current placeholders to be deleted.
The commit adds support for RFC 8998 and draft-yang-tls-hybrid-sm2-mlkem. This includes support for the TLS_SM4_GCM_SM3 and TLS_SM4_CCM_SM3 cipher suites, the key exchange groups curveSM2 and curveSM2MLKEM768, and SM2 public keys and signatures.
While this commit adds support to tls_sockets() to decrypt server responses encrypted under SM4 GCM or CCM, OpenSSL does not support performing key derivation using curveSM2. So, tls_sockets() can not decrypt server responses if the key exchange was performed using curveSM2 or curveSM2MLKEM768.
When checking early for date flavors, there might be an edge case when
a directory with a referred file (for the date command) isn't readable
which might cause testssl.sh to not detect the date flavor correctly.
This fixes that by cd'ing to / in a subshell which should be cd'able
and readable under every platform.
This commit addresses two issues created by changes in certificate printing in OpenSSL 4 (based on testing with OpenSSL 4.0.0-alpha1).
With OpenSSL 4, the public key type for ML-DSA keys is now shown with a string (e.g., ML-DSA-44) rather than an OID. The first change in this commit ensures that the public key size is set correctly in this case.
Second, different information is printed about the size of elliptic curve public keys. All previous versions of OpenSSL (and LibreSSL) just provided the size of the public key:
Public-Key: (256 bit)
OpenSSL 4.0.0-alpha includes additional information:
Public-Key: (256 bit field, 128 bit security level)
The second change in this commit removes this additional information.
... which may led to false positives
Also in a number of tests the timeout was re-adjusted so that the robot check
performs ~25% faster -- on MacOS. On Linux it's about the same.
The commit 51a35b0344 changed variable names but there were leftovers. Also
before the tiemout values were reduced, so that the check may run faster. What was left were that some
timeout values were still too long. Thus MAX_WAITSOCK is now completely changed to ROBOT_TIMEOUT .
Also when the ROBOT check identified something as potentially vulnerable, the timeout value ist increased to
8 seconds which is less than in 3.2 . Tests however showed so far that there were no false positives or
negatives.
Moreover it changes the local variable robottimeout to robot_timeout.
This PR fixes#2983 for 3.3dev .
