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.
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 not to detect the date flavor correctly.
This fixes that (#3009) 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.
The commit 6753a95c939359f9e06fb9f3dd199a0 changed some variables however for consistency
MAX_WAITSOCK should have been completely changed to ROBOT_TIMEOUT .
This PR suggests that. Moreover it changes the local variable robottimeout to robot_timeout.
This fixes#2983 for 3.2 .
As reported a longer while back in #2083 there were trailing bytes when receiving a TLS alert by the ROBOT check.
This PR corrects and thus normalizes the length of the TLS alert message to the correct value, supposed the length in the TLS alert is two bytes and it is an TLS alert. PR for 3.3dev was #2969 .
Also this PR now uses a separate variable for the timeout. Using a separate global variable may offer some possibility for tuning the check when the latency to the target is high. This is still subject of research.
The variable is 10 seconds here to be in line with MAX_WAITSOCK which (name) was used previously.
We missed somehow to add in the big while loop to add the fact that ROBOT is a vulnerability which became
apparent with #2967 (3.3dev).
This PR adds that for 3.2 also. See #2968.
This commit fixes#2959 by modifying TLS12_CIPHER, TLS12_CIPHER_2ND_TRY, and TLS12_CIPHER_3RD_TRY so that they each have 118 ciphers (including "00,ff"). It also modifies run_cipherlists(), run_server_defaults(), and run_beast() so that, when $SERVER_SIZE_LIMIT_BUG is true, no more than 125 ciphers are sent.
`grep -w` matches also `string1-whatsoever` so that entries like
```
192.168.0.10 anystring anystring-apache
192.168.0.11 anystring-tomcat
```
matched 3 entries over 2 lines.
This PR fixes#2937 for 3.2 by improving the pattern, so that `string1` needs a trailing whitespace or an EOL -- besides a leading whitespace..
The new block making sure that rust coreutils work properly (PR #2913)
introduced a new check in order to determine which date functions
to use.
The function however parsed only for English error messages ("No such file").
This PR fixes#2929 that for 3.2 by setting LC_ALL to C.
Ubuntu 25.10 has transitionned from GNU Core-utils to Rust Core-utils. That changes the testing
results which date version to use for displaying / conversion of dates like in certificates.
Probably more Linux distriutions will follow. See also #2909 .
For maintenance reasons it is advised also the stable version will get this patched. For
3.3dev, see #2913 .
