> 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. At least on Windows, all of this exists. Some apps/services get it right, others don't. Easy to just rely on the TRP roots, with detrimental results, as Peter points out.
Regardless, I think EKR's suggestion may be practical, although it's not pretty. Cheers, Andrei -----Original Message----- From: Alan DeKok <[email protected]> Sent: Thursday, April 2, 2026 2:14 PM To: Andrei Popov <[email protected]> Cc: Peter Gutmann <[email protected]>; Nico Williams <[email protected]>; David Adrian <[email protected]>; Mike Ounsworth <[email protected]>; Salz, Rich <[email protected]>; Tls <[email protected]>; [email protected] Subject: Re: [lamps] [EXTERNAL] [TLS] Re: Re: Re: Re: TLS Client Certificates; a survey 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. _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
