18422: if [[ $tmp_result -eq 1 ]] && [[ loop_reneg -eq 1 ]]; then
19633: [[ aaa == bbb ]] # provoke return code=1
450:TRUSTED1ST="" # Contains the `-trusted_first` flag, if this version of openssl supports it
The latter check be amended/corrected later, so that backticks in comments are allowed.
Staring with a simple pattern for checking for non-variables at left hand
side like [[ LHS == $value ]]. The file is supposed be amended in the future.
This fixes#3074 .
Upon commit it fails first as there are two instances which will be detected
(one is deliberate but will be changed too) .
When scanning hosts which offer only TLS 1.3 under some circumstances (e.g. using
MacOS) the scan stopped and prompted the user . It happened always when $OPENSSL
supported TLS 1.3. It did not when this was not the case.
This fixes that (see #3083) for 3.3dev by just skipping the rest in determine_optimal_proto()
when TLS13_ONLY is true.
Also it fixes missing line feeds for servoce detecttion and order in which DNS HTTPS
RR are displayed.
... also improve error handling by adding return values in
*https_rr functions.
The error for ~Macs occured because for interpretation of
raw TYPE65 DNS data it was just 1 returned instead of 0
--for empty records.
... 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)
- AI generated code becomes more important, so we add a new section (albeit bash support is not really as good as for other languages).
- streamlined comment, which is a comment
- 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
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
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
