Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mk-ca-bundle.pl options #6

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

DavidIAm
Copy link

mk-ca-bundle.pl in curl changed in commit may 8th to change trust defaults for inclusion in the generated bundle.

This was specifically noticed because the cert for Verisign known as "Class 3 Public Primary Certification Authority" was not included in the bundle because it is not a 'TRUSTED_DELEGATOR', but also unfortunately happens to be the top of the chain that runs AWS ssl certs for secure communication with their systems

TL;DR: the latest Mozilla::CA does not work with a subset of ssl certificates, this patch fixes the build chain to avoid the problem.

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
mk-ca-bundle.pl in curl changed in commit may 8th to change trust defaults for inclusion in the generated bundle.

This was specifically noticed because the cert for Verisign known as "Class 3 Public Primary Certification Authority" was not included in the bundle because it is not a 'TRUSTED_DELEGATOR', but also unfortunately happens to be the top of the chain that runs AWS ssl certs for secure communication with their systems

TL;DR: the latest Mozilla::CA does not work with a subset of ssl certificates, this patch fixes the build chain to avoid the problem.
@byterock
Copy link

well Ask over on the bug I entered said

'Doing "ALL:ALL" isn't a fix; you might just as well stop verifying the certs then.'

@abh
Copy link
Collaborator

abh commented Mar 31, 2015

I can be convinced otherwise; but that's how I understand it.

@kyanha
Copy link

kyanha commented Mar 31, 2015

Here's the rundown, and the context for this particular bug's patch (I helped @DavidIAm figure this out):

Perl's TLS stack uses OpenSSL libraries under the hood.

The OpenSSL libraries don't do verification the same way that NSS (the Mozilla security/TLS) libraries do. NSS will stop building a verification chain as soon as it finds a certificate in the trust store that has the website trust bit asserted. OpenSSL will continue until it finds a self-signed certificate in the chain, or will fail if it can't find one.

The certificate chain asserted goes like this (certificate PEM data elided from output of the command openssl s_client -showcerts -connect sns.us-east-1.amazonaws.com:443):

Certificate chain

0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com, Inc./CN=sns.us-east-1.amazonaws.com
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

The problem is the issuer of certificate 2. "/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority" still exists in certdata.txt, but it does not assert the proper website trust bits for mk-ca-bundle.pl to express it without this or an equivalent patch.

Perl's TLS stack requires the specific certificate identified above in its ca-bundle.pem in order to authenticate Amazon's web services. It might (but is not truly documented to) be able to use the output of openssl x509 -addtrust to bypass this requirement (by assigning serverAuth trust to the G3 or G5 certificates), and I have not tested it for such. It may (or may not) be the case that the objection against ALL:ALL could be sustained through that mechanism. And this is something that would need to be brought up with the OpenSSL developers in any case, even if it does currently work, in order to ensure that the behavior is not modified in the future.

I also object to the assertion that "ALL:ALL" is as bad as stopping verification of certificates entirely. Certificates would not be in Mozilla's certdata.txt if they hadn't been vetted by Mozilla as belonging to certifiers that adhere to its certificate authority policy. They may reduce the security a bit (by allowing email-only and software-only certifiers to sign website certificates), but that is a far cry from stopping all certificate verification.

@abh
Copy link
Collaborator

abh commented Mar 31, 2015

I'm a reluctant maintainer of this, but you all come across as way too crazy sloppy with this issue.

Years ago it was changed to the current behavior in commit f516a6b ("Do not add untrusted CAs from mozilla certdata.txt (RT#70967)").

A proper patch for this will document how the patch makes the behavior match that of Firefox.

Also, the version of mk-ca-bundle.pl we have doesn't have the -p option, so that has to be put in first. The curl documentation (where that script comes from) says:

Around early September 2014, Mozilla removed the trust bits from the certs in their CA bundle that were still using RSA 1024 bit keys. This may lead to TLS libraries having a hard time to verify some sites if the library in question doesn't properly support "path discovery" as per RFC 4158. (That includes OpenSSL and GnuTLS.)

@kyanha
Copy link

kyanha commented Mar 31, 2015

@abh: The version of mk-ca-bundle.pl you have does support the -p option, according to the text in the help. https://github.com/gisle/mozilla-ca/blob/master/mk-ca-bundle.pl#L166

I don't believe that OpenSSL supports behavior matching that of Firefox. If it does, it's not documented to do so. Something that may short-circuit it is openssl x509 -trustout and its related options... but again, I haven't tested this.

In order to have absolute conformance to Firefox's behavior, the plan would have to be:

  1. Verify that OpenSSL's "trusted certificate" (openssl x509 -trustout) commands output certificates in a form that will short-circuit path building to a self-signed root.
  2. If it doesn't, punt the issue up to the OpenSSL development team to fix.
  3. If it does, then punt the issue up to the OpenSSL development team so that they don't ever alter the behavior, and alter the build script to use the openssl commands necessary to output certificates trusted in that manner.

In Verisign's case, it would be nice if it would issue an updated self-signed/self-issued certificate for its G5 certifier, and distribute those certificates to its customers. However, I think this is an impractical burden (contacting every one of its customers to update the certificate chains their servers send out).

Worst-case, there's also all of the many installed sites that already have OpenSSL installed but would need to build a new version of perl for any upgrades to a version that supports a short-circuit (say, to the latest 1.0.2, when they're still on 0.9.8 or 0.9.9).

@abh
Copy link
Collaborator

abh commented Oct 1, 2021

I apologize for not merging this; but I'm not qualified to choose what's right so I'l reluctant to change it without more input!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants