- 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
This is just to assist debugging of the runners, so that
we can grab in a case needed the screen and stderr .
* there's a script t/03_debug.t.DISABLED which needs to be renamed then
* it utilises IPC::Run3
- also showing the PATH is added for both runners
- Readme amended accordingly
Adds X-Permitted-Cross-Domain-Policies (already highlighted in emphasize_stuff_in_headers() but never reported), Origin-Agent-Cluster, Document-Policy, Clear-Site-Data, Reporting-Endpoints, Report-To and NEL to run_security_headers(), all presence-only/INFO, matching how COOP/COEP/CORP were added in #2619.
When a port was appended to the domain (e.g. "--mx example.com:25"), the suffix was passed straight into the MX DNS lookup, so no MX records were found. Strip a trailing :port off the domain before the lookup and use it as the port to test. Also fix the no-MX message, which printed $1 (the run date) instead of the domain, plus a "records(s)" typo.
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
set_scanning_defaults() reset do_ipv4_only/do_ipv6_only to false. When
no individual test is requested on the command line, count_do_variables
returns 0 and parse_cmd_line() calls set_scanning_defaults() to enable
the standard test suite, which silently wiped out the user's -4/-6
selection. As a result determine_ip_addresses() fell through to its
"scan everything" branch and scanned both the A and AAAA records,
producing one scanResult per IP.
The IP-version flags are connection options, not test-selection state,
and are already initialized in initialize_globals(), so remove the
stray resets from set_scanning_defaults().
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
run_security_headers() listed "Permissions-Policy" twice in its
header_and_svrty checklist: once as OK (since 2020) and again as INFO
(accidentally added in 12036fb). The loop matched the same header on
both iterations, emitting two entries to JSON (headerResponse) and the
terminal output. Remove the duplicate INFO entry, keeping the intended
OK classification.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
... 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
Dirk Wetter