[lamps] Re: [EXTERNAL] [TLS] Re: Re: Re: Re: TLS Client Certificates; a survey

[Peter Gutmann <[e-mail]>]

Nico Williams <[e-mail]> writes:

>Recall that we're talking about constraining client certificate use here to
>just dNSName SAN certificates.  Since KB5014754 at least the mapping of those
>to machine accounts from Active Directory should not be trivial to spoof by
>WebPKI CAs anymore.

I'm not sure whether proposing AD (or some other equivalent, if there is one)
as a means of managing certificate access control is going to help or if it'll
just make things worse.  There was an OWASP talk a year or two back by someone
who worked for a large pen-testing company who pointed out that, apart from
"nobody ever got hacked by running TLS 1.0", and later on "nobody gets
breached because they didn't score an A with SSL Labs", that all the
exploitable vulns they found were from certificate issues or
misconfigurations, typically in AD CS (Active Directory Cert Services).  The
talk was mostly just an hour-long smorgasbord of all the ways things can go
wrong, starting with the ESC1 to ESC8 catalogue and going from there to all
the very-common misconfigurations they'd found, a mixture of both the way that
AD CS does things (sometimes bugs, sometimes unexpected quirks) and how easy
it is to shoot yourself in the foot with it.  It's such a big problem that the
Five Eyes agencies have official guidance on how to (try to) set it up, e.g.
https://www.cyber.gov.au/business-government/detecting-responding-to-threats/detecting-and-mitigating-active-directory-compromises
(scroll down to "Active Directory Certificate Services (AD CS) compromise"
although it's not compromising AD CS itself but just exploiting the way it
works, and it looks like the guidance only covers the ESC1 stuff, there's a
lot more there than that).

Absolutely not trying to bash AD CS here, it's just the most widely-used means
of managing cert-based access control by far and because of this it's a great
real-world example of all the ways that things will go wrong.

Peter.