Sprinkle some DNSSEC on the CAA record too, if you'd like.
[0]: https://developers.cloudflare.com/ssl/edge-certificates/caa-...
Is that true? My read of Section 1.2.1 in [1] suggests CAA checking has been mandatory since 2017‐09‐08.
[1] https://cabforum.org/working-groups/server/baseline-requirem...
To get complete control with DNSSEC, you also need the accounturi and validationmethod extensions (which you need to guarantee only your account can issue, and only with the DNS validation type).
Those aren't yet mandatory, but you can restrict to a CA today which implements them, like Let's Encrypt.
It is too fragile (multiple point of failure). It is high volume (=it need be cacheable).
Puting authentication cert in dns sounds good in theory, but we have never get that reliability
If your DNS isn't working, you're not going to be making connections anyway. And if you can't keep DNSSEC running, you can't keep certs up to date either. DNSSEC is actually much simpler, with fewer failure points, once you set it up.
> It is high volume (=it need be cacheable).
It is. Unlike certificates. And the cache lifetimes are much shorter than typical certificate lifetimes.
https://www.feistyduck.com/newsletter/issue_137_acme_caa__ex...
You either need to disable PFS on the server, or export TLS master keys for each session in some way, or MiTM.
Parallel *Re*construction is a play on words I wrote related to a lot of the nuance at play I wasn’t able to cover in the blog without making it very long.
This has been upheld as lawful, but also can unfortunately be used to disguise unlawful behavior.
Reverse engineering is not related to parallel construction.
Its really not that difficult to not grant excessive privileges - at the very least for recurring ("cron") runs, once filesystem structure, cache invalidation triggers and web server configuration are in place. Its a shame this is still taught in the "just run as admin" style.
acme-client on OpenBSD does this, using privilege separated processes that each in turn use pledge and unveil. You wouldn't know without looking at the source code because it's entirely transparent.
Maybe what people get upset about is catchy misleading [0] summaries like this, which suggest [0] a CA - nation state collusion, despite the actual story going in a completely different [0] direction? The thing that would be actually big news [0]?
[0] in the eye of the beholder of course, as always
On a related note, Let's Encrypt also issued the presumably-interception certificates. This can be possibly something that requires interception at the VPS level (otherwise we already detected the BGP leaks). Presumably, Hetzner was forced to do a raw interception and then redirecting all relevant ports to a middlebox for inspection and CA issuance (and since that the ACME spec is well-defined, they can simply check if the handshake contains the TLS ALPN challenge and then redirect them to special code that will reply with the correct things).
By breaking the software facilitating https via ACME itself, no anomalous certificate transparency logs would have needed to have been created at all.
The front door is locked quite tightly with a watchful security camera, but the window has been left unlocked. Also no one is watching the camera feed.
The most striking thing about these types of conspiracy theories is people seem to completely forget that whoever you imagine you can threaten generally doesn't have the ability to do the thing you want them to do: they'd have to delegate it.