Two things this time: a new compliance report for post-quantum cryptography, and a redesigned weekly PDF report.
Attackers can record encrypted traffic today and decrypt it once quantum computers are powerful enough. This is called "harvest now, decrypt later", and it is the reason quantum-safe encryption matters now, not in ten years. The new Post-Quantum Cryptography Readiness report shows for each of your servers whether its encryption is quantum-safe.
We check web encryption (TLS) and remote login (SSH) on every server. Each server gets one of five statuses: Quantum-safe, Partly quantum-safe, Outdated version, Not quantum-safe, or Not checked yet. It also gets a score from A+ to F. Those scores are averaged into one score for your organisation.
Addresses behind a service like Cloudflare show that service's settings, not your own server's. The report marks these, and gives a separate score for your own servers, so a CDN doesn't hide (or inflate) your real position.
You can get the report with the query $post_quantum_cryptography_report, or activate it from the report library. More details are in the documentation.
The weekly PDF report that lands in your inbox on Monday morning has a new format. It now includes a summary of:
The goal is a more actionable report with better insight into how to reduce your risk. The previous format had too many long rows of results, which for some of you made it hard to see where to start. The new format gives you the overview first. The full detail is still one click away in ShadowTrackr, and you can still use the individual reports to get every row.
The weekly PDF is still the only report that is emailed by default, and you can add as many recipients as you like. They don't need a ShadowTrackr account.
Please let us know what you think. If something is missing, unclear or just not useful, send us feedback. We use it to decide what to improve next.
Until now, all of the internet.nl-style checks (IPv6, DNSSEC, TLS, HTTP security headers, RPKI, and so on) only lived inside the $internet_standards_report overview. That was fine for a weekly summary, but it meant you couldn't query or alert on a single check without pulling the whole report.
That's changed. internet_standards is now its own index, with one row per url and one field per check. Each check comes back as good, failed, recommended, optional, error or not_tested, so you can search or alert on any individual check directly, for example:
index=internet_standards dnssec_valid=failed
index=internet_standards tls_version=failed OR tls_ciphers=failed
index=internet_standards hsts!=good
That last one is handy if you want to catch anything that isn't fully green, not just outright failures, since recommended and optional verdicts won't show up as failed. You can also alert on the overall score dropping:
index=internet_standards score<70
Note that urls where nothing could be tested at all (dead domain, no webserver) don't appear in this index, since it only holds scan results, not every url you track. See Internet Standards for the full field list, including the points_* fields if you want to see exactly how a partial score was earned.
The $internet_standards_report magic query is still there and works exactly as before, it's still the easiest way to get a full overview across all your assets, and it now pulls from this same index under the hood, so the two stay in sync.
Alongside this, there's a dnssec_chains index. Where internet_standards just gives you a pass/fail on dnssec_exists and dnssec_valid, dnssec_chains runs a full validating resolve and records the actual chain of trust, so you can see exactly where it breaks instead of just getting a red X:
index=dnssec_chains status=bogus
index=dnssec_chains status=indeterminate
The status field is one of secure, insecure, partial, bogus or indeterminate, and raw_error fills in with the resolver error when a check can't be completed at all. DNSSec chains are monitored for all your urls by default. Full details at DNSSEC Chains.