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.
2
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
It's mostly verified in practice by mail servers. To enable DANE verification for Postfix, you set up a validating resolver (unbound is nice), set that as your only resolver in /etc/resolv.conf and then enable the 2 settings to have Postfix enforce it.
Quote Tweet
Replying to @encthenet
Enabling it for Postfix simply requires setting up unbound as your resolver and then enabling 2 configuration options:
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
Enables opportunistic dane where it uses it when there are TLSA records and prevents downgrades.
wiki.archlinux.org/title/DANE has a simple summary of the meaning of the fields. In practice, you only need 3 1 1 (leafs) and 2 1 1 (intermediates/roots).
1


