see #2325.
"whenever HTTP/1.1 is used then the Accept header uses "text/*" as a MIME type.
This causes some minor issues with some of the checks we are doing"
As noted in #2304, the way that the '&' character is treated in the string part of a pattern substitution changed in Bash 5.2. As a result, the change that was made in #1481 to accommodate older versions of Bash (e.g., on MacOS) now causes testssl.sh to produce incorrect HTML output when run on Bash 5.2.
This commit encodes the '&' characters in the substitution strings in a way that produces correct results on multiple versions of Bash (3.2 on MacOS, 5.2 on Ubuntu 23.10, 5.0 on Ubuntu 20.04).
- If local folder ownership is for example `644` it will fail to handle the `COPY` regardless (while `744` would work).
- Creating the directory with higher permissions in the container does not appear to help.
Create `testssl` user (_and group_) with no password (`-D`) and default their shell to bash (`-s`):
- A group will implicitly be created with the same value as the user. `addgroup testssl` and `-G testssl` are not needed.
- Gecos data (`-g "testssl user"`) doesn't appear relevant to the project to be required? The default gecos value (`Linux User,,,`) should be fine.
There are two different scenarios. x0C is the buffsize reply from openldap-like servers
whereas AD servers probably have x84 and return also the OID. The following is kind of
hackish as ldap_ExtendedResponse_parse() in apps/s_client.c of openssl is kind of hard
to understand. It was deducted from a number of hosts.
Bottom line: We'll look at the 9th byte or at the 17th when retrieving the result code
AD:
30 84 00 00 00 7d 02 01 01 78 84 00 00 00 74 0a 01 34 04 00 04 55 30 30 30 30 30 30 30 30 3a 20 [ failed AD .. LdapErr + OID..]
30 84 00 00 00 28 02 01 01 78 84 00 00 00 1F 0A 01 00 04 00 04 00 8A 16 [.. OID ..]
^^ bufflen ^^ resultcode
30 0C 02 01 01 78 07 0A 01 00 04 00 04 00
^^ bufflen ^^ result code
When a server supports client authentication, extract_calist() extracts the list of supported certification authorities sent by the server. extract_calist() uses different code to extract the list from a TLS 1.3 response than from a TLS 1.2 or earlier response, since the CertificateRequest message was changed for TLS 1.3.
For TLS 1.2 and earlier, extract_calist() assumes that the CertificateRequest message is a sequence of certificate types, signature algorithms, and certification authorities. However, the signature algorithms field was added in TLS 1.2 and does not appear in TLS 1.1 and earlier. So, the current code does not work unless the server supports TLS 1.2 or TLS 1.3.
This commit fixes the problem by checking whether the response is a TLS 1.2 response, and skipping over the extraction of the signature algorithms field if the response is neither TLS 1.2 nor TLS 1.3.
Some servers get confused if the signature_algorithms extension is too large. This commit addresses the problem by:
* For TLS 1.2, generally limiting the signature algoritms to those consistent with the key type being tested.
* For TLS 1.3, breaking the list of signature schemes in two, and testing each half of the list separately.
This commit modifies run_fs() to show the signature algorithms the server supports in the ServerKeyExchange message for TLS 1.2 and in the CertificateVerify message for TLS 1.3.
Signature algorithms are not shown for TLS 1.1 and earlier, since for those protocol versions the signature algorithm to use is specified by the protocol. While the signature algorithm used in TLS 1.1 and earlier is weak, testssl.sh already warns if these protocol versions are supported.
Dirk
Brennan Kinney
David Cooper
David Cooper
Sole
dependabot[bot]
Kali