{"id":908,"date":"2024-11-30T20:44:25","date_gmt":"2024-12-01T04:44:25","guid":{"rendered":"https:\/\/unmitigatedrisk.com\/?p=908"},"modified":"2024-12-01T19:30:28","modified_gmt":"2024-12-02T03:30:28","slug":"another-ca-fails-the-turing-test","status":"publish","type":"post","link":"https:\/\/unmitigatedrisk.com\/?p=908","title":{"rendered":"Another CA Fails the Turing Test?"},"content":{"rendered":"\n

In a concerning development, yet another Certificate Authority (CA) has issued what is likely a man-in-the-middle (MITM) certificate\u2014something strictly prohibited by all root programs. This particular case is unique because the CA is trusted only by Microsoft, making the situation both frustratingly familiar and uniquely problematic. Details are emerging in this Bugzilla thread<\/a>.<\/p>\n\n\n\n

A Familiar Pattern<\/h4>\n\n\n\n

Back in 2011, I wrote about Microsoft\u2019s trust in government-run CAs and the inherent risks (read here<\/a>). More than a decade later, it\u2019s clear little has changed. Browser distrust events happen with disappointing regularity\u2014roughly every 1.25 years, according to my analysis (source<\/a>). While MITM certificate issuance is far rarer, it\u2019s far more serious, and a disturbing trend is evident: Many of the CAs responsible are government-run or affiliated.<\/p>\n\n\n\n

Why This Matters to You<\/h4>\n\n\n\n

For Windows users, this is particularly relevant. Windows browsers like Edge (and others) rely on the Microsoft Root Program, which has unfortunately historically been overly permissive and slow to respond to incidents. You can learn more about the program and its requirements here<\/a>. In the recent past, I can\u2019t recall a CA responsible for willfully issuing an MITM certificate surviving, but the the timeline for Microsoft\u2019s response is unclear. That said, when Microsoft does act, their AutoRoot Update feature\u2014which I was the product manager for in the early 2000s\u2014allows them to respond swiftly.<\/p>\n\n\n\n

In the meantime, you can protect yourself by identifying and distrusting the offending certificate. Enterprises, in particular, can take a proactive stance by using the Microsoft distrust store. Through group policy, IT administrators can preemptively distrust the problematic CA across their organization, mitigating the risk before Microsoft formally acts.<\/p>\n\n\n\n

The Lack of Technical Controls<\/h4>\n\n\n\n

It\u2019s worth noting there are no technical controls that inherently prevent CAs from issuing MiTM certificates (though some browsers do have technical controls for some classes of misissuance). Instead, the WebPKI ecosystem relies on Certificate Transparency (CT) logs and a dedicated community of people closely monitoring CA issuance for violations of requirements. In a way, this incident serves as a smoke test for the system\u2014but when it comes to these MITM certificates, it\u2019s an awfully expensive test, with significant risks both for users of the web and reputational risks for the root programs, as well as questions about the trustworthiness of the WebPKI in general.<\/p>\n\n\n\n

Predictable Chaos<\/h4>\n\n\n\n

If you\u2019re following this story, keep an eye on the Bugzilla thread<\/a>. Based on past experience, I\u2019d wager the CA in question will bungle its incident response. MITM certificate issuance often reflects systemic issues, and such organizations typically don\u2019t have the maturity to handle these crises well.<\/p>\n\n\n\n

If this topic interests you, here\u2019s some further reading:<\/p>\n\n\n\n