... which is initialized with "initt" to distinguish between not being tested yet and no value.
We only display the value once per $NODE for the first IP address being tested.
HTTPS_RR doesn't have to be reset in reset_hostdepended_vars()
Few comments were added / indentation fixed (not relevant to this PR)
- parsing output from old dig versions (Mac) works for almost every svc_key
- for old dig versions: double lined RR work (but output is not nice yet)
- cleaned up comments
- separate function https_rr_raw_parser()
- commented output from claude.ai for ech for later interpretation
- get_mx_record() has a warning when get_https_rrecord returned != 0
- dig needs to be called with $DIG_R
- basic parsing for alpn on Mac should be fine now
- case statement filled with moste of the functions
- port function tested + added, but not called yet
- ipv4hint function tested + added but not called yet
- ipv6hint function tested + added but not called yet. Doesn't do compression of ipv6 address yet
- stub functions dohpath+ech
First implemented and tested working is decode_https_rr_alpn().
Also we use the svk params in a case statement to decipher the
hexstream better.
The hexstream ($line) has now no blanks anymore. They seem to be
arbitrary.
Variables need to be declared in get_https_rrecord() .
- quote vars (hoping it'll resolve the Mac runner issue)
- make sure CNAMEs are properly parsed
- end get_https_rrecord() earlier when there's no record but DNS binaries are "HTTPS record aware"
- while loop was redundant
- better comments
Elsewhere:
make sure get_https_rrecord is called with a trailing dot for the NODE
as there is an inexplicable difference between a real Mac
which passes the run and the one in github
-"DNS_HTTPS_rrecord","testssl.sh/81.169.235.32","443","OK","81.169.235.32","",""
+"DNS_HTTPS_rrecord","testssl.sh/81.169.235.32","443","OK","1 . alpn='h2'","",""
The first line comes from the runner
This is a fresh start for #2484 as the PR wasn't ready yet for 3.2 by the time it was released. And it continues #2866
which was kind of messed up by accident.
The info for the HTTPS RR shows up in the very beginning, i.e. in `service_detection()`. All keys are listed now in bold, values in a regular font.
`get_https_rrecord()` was introduced by copying and modifying `get_caa_rr_record()`.
There's a similar obstacle as with CAA RRs: older binaries show the resource records binary encoded. Thus a new set of global vars is introduced HAS_*_HTTPS which check whether the binaries support decoding the RR directly. As of now raw decoding doesn't work completely.
Todo:
- Add logic in QUIC
- if RR is detected and not QUIC is possible
- add time for QUIC detection when RR is retrieved
- show full HTTPS RR record, at least when having a new DNS client
- coninue with raw decoding, if possible (otherwise problematic for MacOS)
- shorten the comments in `get_https_rrecord()`
- man page
- when ASSUME_HTTP is set and no services was detected: this needs to be handled
- The placement of the output should be reconsidered and/or cached when multiple IPs belong to a FQDN
... 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
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.
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.
... 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 .
This PR fixes#2806 and implements a feature request. TLS >=1.2 MUST support
support the extended_master_secret extension to address an attack resulting
from TLS session parameters not being properly authenticated in a Triple
Handshake scanario (https://ieeexplore.ieee.org/document/6956559).
Only if the extension is missing there will be a medium severity level
finding. JSON output will be generated in any case.
Also in determine_tls_extensions() some documenation about tls extensions
to be send were added.
This fixes#2973.
There was a while back an extra headline when one or a defined other
number of vulnerabilities were checked. The extra headline was removed
n #2967 but some leftover code needed to be removed as well.
In the aforementioned previous PR it seems run_starttls_injection()
and run_rc4() were forgotten. This PR removes extra headlines in
those functions as well.
.. as an UI improvement for the user.
Implemented for Ticketbleed and during startup in determine_optimal_proto() .
For the latter it could be considered later to automagically pick $OPENSSL2 .
Dirk Wetter