Certificates with a short validity period (e.g. Let's Encrypt's 6-day
"shortlived" profile, now GA) always tripped the days2warn expiry
thresholds and were shown in red on the "Certificate Validity (UTC)"
line, even seconds after issuance. That red is misleading for a cert
that is intentionally short-lived.
Detect short-lived certificates by their validity period (notAfter -
notBefore) using a new DAYS_VALID_SHORTLIVED threshold (default 10 days,
per the CA/Browser Forum BR 1.6.1 "Short-lived Subscriber Certificate"
definition, which also covers the LE 6-day profile). For such certs:
- show them as good (not red) with a "short-lived cert (N days)" remark
so the short lifespan reads as intended rather than as an error, and
- warn (HIGH) only when less than 24h of validity is left, and only for
certificates whose total lifetime exceeds 24h (a cert whose whole
life is under 24h stays good until it expires rather than being
flagged the entire time).
Regular certificates are unaffected and keep the existing days2warn
behaviour. The threshold is overridable via the DAYS_VALID_SHORTLIVED
env var (documented in doc/testssl.1.md next to DAYS2WARN1/2) and added
to CHANGELOG.md.
Verified end-to-end with local openssl s_server: 5-day fresh (green),
5-day with <24h left (red, "expires < 24h"), 12h fresh (green), 12h
nearly expired (green), and 90-day (unchanged ">= days").
pr_url() and pr_boldurl() interpolated their argument directly into
<a href="$1">$1</a> without HTML escaping. The most notable caller
passes the raw HTTP Location: header from the scanned server, so a
malicious HTTPS target could inject arbitrary HTML/JS into an
operator's --htmlfile report. Route both the href attribute and the
link text through the existing html_reserved() escaper, matching the
pattern already used by every other pr_* HTML-output function.
Revives and rebases #1809 by @tosticated (Jim Blankendaal) onto 3.3dev. When --phone-out is set, run_hsts now queries https://hstspreload.org/api/v2/status and reports whether the domain is on the browser HSTS preload list (preloaded/pending/rejected/unknown), cross-referenced with the served header, the same-domain check and the bulk flag.
Addresses the review comments on #1809: the API-response matching uses native bash string matching instead of forking grep, the JSON quoting is handled inside check_hsts_preloadlist_match() so callers pass plain values, and the value arrays use 'local -a'. The output decision table is kept as-is (per maintainer feedback). Adds t/53_hsts_preload.t. Original design and decision table by @tosticated.
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
Fixes#2833
This does a check for the opossum vulnerability, see https://opossum-attack.com/ .
It uses a separate function to send the payload and retrieve the result via `http_header_printf()`. It doesn't use curl or wget. The latter wouldn't work anyway as according to the manpage as the HTTP header which needs to be sent must not contain LFs. This function was introduced because `http_get_header()` -- which was renamed to `http_head()` -- could use wget if curl is not available. On the way to this PR `http_head()` was improved, so that timeouts were used for curl and wget for better maturity.
`http_header_printf()` now uses bach sockets , strips the URI so that a plaintext request is made. This will be done in the background because not every host will answer.
Done also:
- handling when PROXY is requested (try anyway directly as the payload is not "proxyable")
- print a message when no HTTP service is present
- try hard to use plaintext HTTP when auth is required for HTTPS and service HTTP would not be defined otherwise
- manpages
- help
Also when pwnedkeys are checked a not pwned certificate is labled not neutral but OK=green.
This commit adds support for server certificates that have ML-DSA pubilc keys. It also adds supports for certificates that are signed with ML-DSA or SLH-DSA. The ML-DSA code points for the signature_algorithms extension are taken from https://datatracker.ietf.org/doc/draft-tls-westerbaan-mldsa/ and are the ones used by OpenSSL 3.5.0.
... to avoid redirects on the client side and to make repo migration better visible.
Also amend 'Status' and 'Contributing' in Readme.md. bluesky added, albeit mastodon
seems more interactive. Clarify twitter account is not in use anymore.
This commit adds a check for whether the server supports certificate compression (RFC 8879). If it does, then the list of supprted compression methods is output in the server's preference order.
Eric Gu