Executive summary: Forgive me if I have overlooked something, but I could not find any discussion of the nameConstraints bypass bug on openssl.org. Is everybody aware of this? Do we need to add it to the request tracker?
======================== On the cryptography list, on 07/19/2014 02:37 PM, Tony Arcieri wrote: > If only X.509 name constraints actually worked. Indeed. If name constraints actually worked, they would be important. Right now, almost nobody is using nameConstraints in conjunction with openssl. That is because they don't work reliably ... not because they are intrinsically unimportant. In particular, it would be a huge mistake to let this become a chicken-and-egg problem. That is, it would be a huge mistake to think nameConstraints are not worth fixing, because nobody is using them (yet). As Fred Smith once said, when you are designing a new bridge, you don't size it according to the number of people who travel across the river today, in the absence of any bridge. You size it according to the number of people who will travel across the bridge /after it is fully functional/. Right now I have a bunch of web servers. Rather than giving each one its own self-signed snake-oil certificate, I have my own CA. Each web server has its own CA-signed certificate. This gives me more flexibility and more convenience. It is a trust model I can believe in: I trust the certificate because I issued it. My CA is subject to name constraints. If name constraints actually worked, this would confer an advantage on me, insofar as it would make me less of juicy target. That is, it would make my root CA private key much less worth stealing. By the same token, if name constraints actually worked, they would make it easier for me to convince /other/ people to trust my CA, because it is far less open to abuse. However, at present, it is pathetically easy to trick openssl into bypassing nameConstraints. All you need to do is put some evil DNS name in the common name and not provide any subjectAltName list. I checked; this bug is present in openssl-1.0.1i; openssl s_client happily connects to bypass.jdenker.com in defiance of my CA's nameConstraints. This affects widely-used apps including curl, lynx, and wget, although I only checked them as of 1.0.1f. If you want a live demonstration, try the following: wget http://www.av8n.com/av8n.com_Root_CA.pem echo bde600da763f4105ceb64913d0ed5838 av8n.com_Root_CA.pem | md5sum -c - SSL_CERT_FILE=av8n.com_Root_CA.pem curl https://bypass.jdenker.com:444/hello.txt Observed behavior: Command succeeds, prints "Hello, world!" Desired behavior: Should fail, due to violation of nameConstraints. Compare and contrast: firefox behavior below. Also compare: The following succeeds, as it should: SSL_CERT_FILE=av8n.com_Root_CA.pem curl https://cloud.av8n.com/hello.txt Also: The following succeeds, but should not: :| openssl s_client -CAfile av8n-root-ca-cert.pem -connect bypass.jdenker.com:444 If anybody is interested, I can provide the config files that generate the certificates in question. You can easily find additional discussion of this bug; https://www.google.com/search?q=x509+%22name+constraints%22+bypass leads to http://www.openwall.com/lists/oss-security/2013/08/12/4 As long as openssl remains vulnerable, nobody should rely on v3 nameConstraints to be effective. In particular, in accordance with the Golden Rule, I cannot in good conscience ask anybody to trust my root CA unless they trust me so completely that they accept it to sign anything in the world, without regard to the constraints ... or unless they trust it only on platforms that do not use openssl or other vulnerable packages. ============ Note that in contrast, the bypass bug has been fixed in Mozilla NSS. https://bugzilla.mozilla.org/show_bug.cgi?id=394919 When I try the bypass trick on firefox 31.0, it throws an appropriate error. >>> firefox https://bypass.jdenker.com:444/hello.txt > Secure Connection Failed > > An error occurred during a connection to bypass.jdenker.com:444 > The Certifying Authority for this certificate is not permitted > to issue a certificate with this name. > > (Error code: sec_error_cert_not_in_name_space) The user is not even given the option of continuing past the error. So evidently this is considered more serious than a run-of-the-mill problem with an unrecognized issuer. =========== It is my understanding that the RFC has been repaired to deal with this issue: http://www.rfc-editor.org/rfc/rfc5280.txt This is yet more proof, if any were needed, why RFCs should never be treated as Holy Scripture. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
