... which warns also via file output when not recommended command
line options are used.
This function named issue_cmdline_warnings() is being called in
lets roll after all fileout() functions has been initialized.
It needs to make use of fileout_insert_warning() though because
otherwise the JSON output is not correct.
Besides the previoulsy introduced warning when scanning IP addresses,
warnings of usage of '--fast' and '--ssl-native' will end up also
in a file now which gives ther tools using the machine readable
output to detect bad scan conditions.
Also warnings when scanning the most known IPv4 addresses
from Cloudflare, Google and Quad9, are avoided.
* move message when scanning IP address to the very beginning, inside parse_cmd_line()
* improve message
* just check whether there are no chars a-zA-Z
* move [[ $caa_node =~ '.'$ ]] || caa_node+="." into the while loop
- Skip CAA lookup entirely when NODE is an IP address; show
"not checked (IP address scan)" instead of spuriously querying
IP octets as domain labels and reporting "not offered"
- Force FQDN (trailing dot) on the initial caa_node before the
walk loop so dig does not apply the resolv.conf search domain
to the first query, which could return a false result
- Add a visible warning in the scan header when scanning by IP
address, noting that trust/CAA and other domain-specific checks
may be unreliable and the user should rescan with the hostname
went through a couple of pcap files and determined ja3 + ja4 sums.
- Android 15/16 are the same (previously ja3 taken instead of ja4 and wrong host. One has to use chrome !)
- Edge 101/Chrome 101 are the same (will be deprated next time)
- surprisingly Java 17.0.3 and 21.0.6 were the same.
- Added: Ja3/ja4 for old Apple Mail and Thunderbird
As mentioned in the comment: For Androids ja3 is is not unique, probably because of GREASE.
One can add two handshakes after another and they are different. ja4 seems more consistent here.
This should be kept in mind for all clients "supplying some grease"
The trailing error messages were swapped in the paragraphs /
description for MAX_SOCKET_FAIL + MAX_OSSL_FAIL .
This fixes the confusion for 3.3dev , see #3028 .
This fixes#3003 .
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.
This commit changes the way that TLS 1.3 ciphers are identified by the OpenSSL names. To the degree possible, rather than checking for prefixes that have historically been used in various versions of OpenSSL and LibreSSL, the cipher name being checked against the known list of TLS 1.3 cipher suites that $OPENSSL supports.
In the few places in which the cipher suite name to be checked may not be supported by $OPENSSL, a check for the prefix "TLS_" is also used.
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.
Dirk