[JackRabbitSlim]

X509 as a whole is fine and this isn't so much arbitrary MITM of any web server. It's specific to ECC public keys(not specifically X509 certs) that validate from cryptoAPI which is a fairly limited but devastating scope. EG Code signing.

Firefox uses its own NSS libraries not cryptoAPI to verify certs and is completely unaffected. I assume every major browser uses NSS or their own APIs as well. And of course RSA and AES certificates remain unaffected.

[trulyrandom]

TLS supports ECC certificates, so any web client using crypt32 to verify those is affected. That includes web browsers and lots of other types of services, so it's not primarily code signed executables.

Does Firefox still use NSS when using the Windows Certificate Store for the source of trusted root certs? What about Chrome?

You're right that RSA certificates are unaffected. There's no such thing as AES certificates, though.

[tialaramex]

> Does Firefox still use NSS when using the Windows Certificate Store for the source of trusted root certs?

Yes. When enabled this feature in Firefox just effectively copies certificates from one of the Windows trust stores but continues to use its own (NSS) logic for trust decisions. Note also that Firefox's config switch only looks at your local changes - a corporate CA, a MITM proxy on a dev's workstation, something like that. Firefox continues to rely on Mozilla's judgement not Microsoft's for global trust policy.

> What about Chrome?

Chrome is probably affected. Chrome uses the platform (in this case crypt32.dll) trust decisions and then layers on additional rules from Google, such as the requirement for proof of CT logging. So unless an additional rule is blocking the weird curves they'll pass on Chrome on Windows.

[tptacek]

A CERT person on Twitter was explicit about this impacting all of X.509.