Are end-entity certificates without basic constraints extension vulnerable?

Question

Public certificate authorities seem to always include the basic constraints extension. Why is this a best practice? What is the risk for a PKI to issuing end-entity certificates that don't have ‘certificate signing’ in the key usage list but lack the basic constraints extension?

I have read parts of https://www.ietf.org/rfc/rfc5280.txt. From what I understand, CA certificates must have the keyCertSign bit and critical basic constraints extension. I still wonder if certificates for TLS or Code Signing must have the basic constraints extension, because the key usage bits already seem to prevent misuse. If it is because of certain legacy implementations, I would like to know which ones.

As experiment, I issued a certificate from an intermediate certificate without the basic constraints extension and with key usage ‘Digital Signature, Key Encipherment (a0)’. For this invalid certificate in the chain, Windows certificate viewer says 'This certificate does not appear to be valid for the selected purpose'. So, I can't find a specific exploit for this certificate in the current Windows implementation, but am not sure if it is vulnerable for other uses.

Answer 1

The vulnerability is implementation specific; some implementations will conservatively check key usage, some will not. Failure by CAs to complete the basic constraints field and failure by browsers to check the field was famously exploited by Moxie Marlinspike and his sslsniff tool (see the slides from his BlackHat talk in 2009). Since that talk a great deal more effort goes into ensuring these fields are validated and checked, however anyone using a legacy browser is potentially still vulnerable (Marlinspike mentions IE, Konqueror and OpenSSL as initially vulnerable and ominously adds "You'd be surprised who still doesn't check basic constraints.").