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
Replying to
I disagree that there is no defense against split views. Cert Spotter gossips STHs with Google, so if a log tries to hide a cert from Cert Spotter, it will be detected with 100% probability (assuming Google's end of this is robust). Much more likely for a bad SCT to go undetected
1
4
I don't know of any other monitors that gossip (except for 's defunct monitor), but it's not hard, esp compared to SCT auditing! IMO, ensuring that monitors and browser vendors see the same view of logs is a solved problem, with a de facto spec and running code.
3
3
It's still a reactive rather than preventative mechanism and most organizations don't and won't have any monitoring of CT logs. It only works for organizations like Google that are going to track all their valid certificates and monitor the logs to check for any invalid ones.
1
1
It's still only able to catch something after the fact. That doesn't do much good when it's so hard to remove a CA. It's an incredibly broken system, and WebPKI relies on DNS secure regardless. There's nothing meaningful beyond DV which is based on DNS security anyway.
TLSA records (DANE) + DNSSEC work well. They remove CAs as trusted parties without adding a new one. It's being heavily adopted for non-Gmail SMTP federation already. Microsoft is adopting it for their mail services. Google is adopting an insecure mechanism (MTA-STS) instead.
1
1
2
MTA-STS doesn't even provide WebPKI level security. It only provides comparable security to only using http:// URLs with dynamic HSTS, no HSTS preloading and no Certificate Transparency. It works well for web sites too but browsers have chosen not to provide security to users.
1
Show replies