John Denker via RT
2014-10-13 05:45:52 UTC
This bug report and patch concern the way openssl responds to CA
certificates that have leading dots in the nameConstraints lists.
Thousands of certificates of this type are in use, issued by the
HARICA_2011 CA and perhaps others. Given that both Mozilla and
Ubuntu ship HARICA_2011 as a trusted root CA, this is not a trivial
matter.
This issue applies to root CAs and intermediate CAs alike.
Point of comparison: pk11-kit tolerates leading dots:
lynx -source -head https://www.auth.gr/ |& head -1
HTTP/1.1 200 OK
Similarly: Mozilla NSS tolerates leading dots:
firefox https://www.auth.gr/
Furthermore, virtually all of the user-oriented instructions
found on the web today call for the use of leading dots. The
instructions suggest the dots are mandatory, although in fact
they are not; both pk11-kit and Mozilla NSS tolerate the dotted
and dotless forms equally.
Observed openssl behavior, alas:
wget https://www.auth.gr/ -O /dev/null |& tail -2
permitted subtree violation
To connect to www.auth.gr insecurely, use `--no-check-certificate'.
Similarly, alas:
curl https://www.auth.gr/ |& grep curl:
curl: (60) SSL certificate problem: permitted subtree violation
Similarly, alas:
:| openssl s_client -verify 10 -CApath /etc/ssl/certs -connect www.auth.gr:443 |& grep Verify.return.code
Verify return code: 47 (permitted subtree violation)
Desired behavior: Openssl should tolerate constraint items with
and without leading dots, just like NSS and pk11-kit do.
:| fixed/openssl s_client -verify 10 -CApath /etc/ssl/certs -connect www.auth.gr:443 |& grep Verify.return.code
Verify return code: 0 (ok)
Short of patching openssl, no reasonable workaround for this problem
has been found. Less-than-reasonable options include:
☠ Re-issuing thousands of certificates. This would be prohibitively
disruptive and expensive.
☠ Rewriting all applications to use pk11-kit instead of openssl.
A patch is available: https://www.av8n.com/openssl/leading-dot.diff
The patch applies to openssl-1.0.1i.
Priority: The bug as it stands is a denial-of-service for anybody
who wants to use openssl in connection with thousands of already-issued
certs.
There is probably not much point in fixing this unless we also
fix the nameConstraints bypass bug, i.e. [openssl.org #3502]
The security risk associated with applying the patch is exceedingly
small. It's a very minor change to the code. It makes the code in
some ways better and in no ways worse. The semantics of the leading-
dot form is not seriously open to question.
The counterargument that the RFC does not require us to tolerate
leading dots is bogus. The way I read it, the RFC does require it.
http://www.rfc-editor.org/rfc/rfc5280.txt (page 40)
Furthermore, common sense requires it and certainly the RFC does
not forbid it. Besides, RFCs are not gospel anyway. This RFC
has already been patched to fix horrific errors.
At one point there was talk of treating the leading-dot forms
differently from the dotless forms, but this suggestion has
been withdrawn.
Additional info: To test the dotless form, to make sure it
continues to work:
wget http://www.av8n.com/av8n.com_Dotless_Root_CA.pem
echo 00453924426f1cbb69c0ea9b62d8f2fd av8n.com_Dotless_Root_CA.pem | md5sum -c -
:| openssl s_client -verify 10 -CAfile av8n.com_Dotless_Root_CA.pem -connect dotless.av8n.com:1443 |& grep Verify.return.code
Verify return code: 0 (ok)
Also: To see the structure of the HARICA-2011 CA certificate,
including the leading dots:
openssl x509 -text -noout -in /usr/share/ca-certificates/mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org
certificates that have leading dots in the nameConstraints lists.
Thousands of certificates of this type are in use, issued by the
HARICA_2011 CA and perhaps others. Given that both Mozilla and
Ubuntu ship HARICA_2011 as a trusted root CA, this is not a trivial
matter.
This issue applies to root CAs and intermediate CAs alike.
Point of comparison: pk11-kit tolerates leading dots:
lynx -source -head https://www.auth.gr/ |& head -1
HTTP/1.1 200 OK
Similarly: Mozilla NSS tolerates leading dots:
firefox https://www.auth.gr/
Furthermore, virtually all of the user-oriented instructions
found on the web today call for the use of leading dots. The
instructions suggest the dots are mandatory, although in fact
they are not; both pk11-kit and Mozilla NSS tolerate the dotted
and dotless forms equally.
Observed openssl behavior, alas:
wget https://www.auth.gr/ -O /dev/null |& tail -2
permitted subtree violation
To connect to www.auth.gr insecurely, use `--no-check-certificate'.
Similarly, alas:
curl https://www.auth.gr/ |& grep curl:
curl: (60) SSL certificate problem: permitted subtree violation
Similarly, alas:
:| openssl s_client -verify 10 -CApath /etc/ssl/certs -connect www.auth.gr:443 |& grep Verify.return.code
Verify return code: 47 (permitted subtree violation)
Desired behavior: Openssl should tolerate constraint items with
and without leading dots, just like NSS and pk11-kit do.
:| fixed/openssl s_client -verify 10 -CApath /etc/ssl/certs -connect www.auth.gr:443 |& grep Verify.return.code
Verify return code: 0 (ok)
Short of patching openssl, no reasonable workaround for this problem
has been found. Less-than-reasonable options include:
☠ Re-issuing thousands of certificates. This would be prohibitively
disruptive and expensive.
☠ Rewriting all applications to use pk11-kit instead of openssl.
A patch is available: https://www.av8n.com/openssl/leading-dot.diff
The patch applies to openssl-1.0.1i.
Priority: The bug as it stands is a denial-of-service for anybody
who wants to use openssl in connection with thousands of already-issued
certs.
There is probably not much point in fixing this unless we also
fix the nameConstraints bypass bug, i.e. [openssl.org #3502]
The security risk associated with applying the patch is exceedingly
small. It's a very minor change to the code. It makes the code in
some ways better and in no ways worse. The semantics of the leading-
dot form is not seriously open to question.
The counterargument that the RFC does not require us to tolerate
leading dots is bogus. The way I read it, the RFC does require it.
http://www.rfc-editor.org/rfc/rfc5280.txt (page 40)
Furthermore, common sense requires it and certainly the RFC does
not forbid it. Besides, RFCs are not gospel anyway. This RFC
has already been patched to fix horrific errors.
At one point there was talk of treating the leading-dot forms
differently from the dotless forms, but this suggestion has
been withdrawn.
Additional info: To test the dotless form, to make sure it
continues to work:
wget http://www.av8n.com/av8n.com_Dotless_Root_CA.pem
echo 00453924426f1cbb69c0ea9b62d8f2fd av8n.com_Dotless_Root_CA.pem | md5sum -c -
:| openssl s_client -verify 10 -CAfile av8n.com_Dotless_Root_CA.pem -connect dotless.av8n.com:1443 |& grep Verify.return.code
Verify return code: 0 (ok)
Also: To see the structure of the HARICA-2011 CA certificate,
including the leading dots:
openssl x509 -text -noout -in /usr/share/ca-certificates/mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org