On Apr 2, 2026, at 10:10 AM, Andrei Popov <[email protected]> wrote: > >> The problem is that, particularly under Windows, it's very easy to get drawn >> into trusting everything Windows trusts, which means in effect any cert >> issued by any public CA anywhere. The example I like to give for this is a >> developer who inadvertently got access to USG systems with a GoDaddy cert >> they'd bought for testing, because what was at the other end trusted >> anything from a CA that Windows trusted. > > Correct, this is the type of issue I've been seeing time and again. > App/service developers use default certificate validation in their TLS stack > (as they are encouraged to do), which is rooted in the system-wide TRP. And > then write custom code that attempts to do some form of additional cert > pinning, which is either brittle (resulting in operational fragility) or just > broken (resulting in security vulnerabilities).
This seems like an opportunity for OS vendors to provide a standard set of APIs to store application-specific roots, and to do application-specific validation. I suspect that many applications have similar requirements. Alan DeKok.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
