Starting with a few simple patterns, like for checking for non-variables at left hand side like [[ LHS == $value ]]. The file is supposed be amended in the future.
This fixes#3074 for 3.2
This fixes#3003 for 3.2 .
The conversion to proper UTF-8 should have taken place by just using -nameopt RFC2253, see manpage openssl-namedisplay-options(1ssl).
As @dcooper16 suggested removing esc_msb should help. This may look counterintuitive but works.
The trailing error messages were swapped in the paragraphs / description for MAX_SOCKET_FAIL + MAX_OSSL_FAIL .
This fixes the confusion for 3.2 , see #3028 .
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.
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.
`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 .
This PR ist similar to #2905 for 3.3dev . However for the stable brnach it's
important to note that this is a breaking change as it modifies the output.
That happens only tough when `ciphers_by_strength()` is being used --equivalent
to the command line `./testssl.sh -E` = `./testssl.sh --cipher-per-proto`. As
this is seldom used and was basically succeeded by `-P, --server-preference`
this looks acceptable as it provides consistency which was overdue.
Details:
* keys now always with `v`, like `supportedciphers_TLSv1_2` and also ciphers
(e.g. `TLSv1.2 x35 AES256-SHA`)
* add word "server" to file output so that it reads "NOT a server cipher order configured"
Fixes#2884 for 3.2 .
... to avoid repeated failures because of heise.de . Looks like there are
server side measures which made some tests fail. Often the MacOS CI runner
is slower and seems to run into that.
See also 56c1e585
As suggested in #2885 parsing of the server determined HTTP age var wasn't strict enough, this is a backport for 3.2.
https://www.rfc-editor.org/rfc/rfc7234#section-1.2.1 requires the variable to be a non-negative integer but testssl.sh assumed it was like that but did't check whether that really was the case. This was labled as a (potential) security problem. Potential as it didn't look exploitable after review -- the header as a whole was already sanitized.
This PR fixes the typs confusion and the garbled screen by checking the variable early in run_http_header() and reset it to NaN. That will be used later in run_http_date() to raise a low severity finding. Kudos to @Tristanhx for catching this and for the suggested PR.
Also, only when running in debug mode, this PR fixes that during service_detection() parts of the not-yet-sanitized header ended up on the screen. The fix just calls sanitze_http_header() for the temporary variable $TMPFILE.
For 3.2 sanitze_http_header() had to be modified to accept an argument and the callers needed to be changed.
The opossum patch improved http_get() , http_get_header/http_head()
in terms of readability. This was backported to improve maintainability.
Also in pwned keys if not pwned appear now in green/OK and not just
info level.
HAS_UDS2 was renamed to HAS2_UDS.
Dirk Wetter