a small human has been consuming all my blogging time lately, but I decided to get back into the game with a post full of terrible ideas for how to abuse Certificate Transparency to re-create public key pinning:
Conversation
This is provided by TLSA records, not CAA. TLSA records work well. You can use them to pin the hash of a leaf key, an intermediate key or a root key. You can have multiple valid pins which allows rotation, etc. You can set TTL low to minimize disruption from making mistakes.
TLSA records (DANE) are already widely used for email, and Microsoft is adopting them for Outlook. Google is adopting a much weaker, inherently insecure approach (MTA-STS) for Gmail which works like solely using http URLs with HTTPS redirects + dynamic HSTS, no preloading, no CT.
1
1
Chrome's stated reasoning for not adopting DANE/DNSSEC is that too many networks break DNSSEC.
I've yet to see any reasoning for not working on enforcing it when using DoT/DoH where networks breaking DNSSEC isn't a problem. Any DoT/DoH resolver can be expected to do it right.
1
spent 15 minutes just now trying to get one of these services to print me an appropriate DNS record, no dice. Would love for any of this to be about 10x easier for the standard use-case of having a single SSL root issuer
1
To get the public key hash:
openssl x509 -in public-certificate.pem -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -hex
For leaf keys:
TLSA 3 1 1 5FDBAC0BE6EE09E8B118DF22392F90CC0421EAA05993900DA27B8BE5
Change 3 to 2 for intermediate/root keys.
2
Show replies


