Conversation
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
drwetter
changed the title
|
An HTTPS record can be long, do we need a double space after |
|
@Delicates : CNAME for DNS HTTPS RRs ? you have an example? |
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
www.defo.ie has an HTTPS record that sits behind one CNAME (there could be multiple CNAMEs though). This site also has a lot of ECH RFC 9849 test servers. |
|
yeah, www.defo.ie kinda works with standard DNS dig binary. The only difference I spot as opposed to defo.ie (where the CNAME points to) is that the output needs some work (line feeds) Also for long entries that's an issue which need to be addressed. ECH: yup, saw that on cloudflare-ech.com long before (see code). Comes later though when this is done. Atm I'd be happy when a) all data is presented b) properly c) and Macs don't fall behind. For the latter one get's a hexstream which needs to be intepreted with testssl.sh. For now it shows the svcpriority as ascii fine and alpn . |
- 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
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() .
2 participants
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 modifyingget_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:
get_https_rrecord()Describe your changes
Please refer to an issue here or describe the change thoroughly in your PR.
What is your pull request about?
If it's a code change please check the boxes which are applicable
help()