Correctly validate leaf certificate trust #173
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
HashiCorp Vault v1.14.10 reports fixing the following security vulnerability:
From this, we can deduce that there is an issue with validating the authenticity of leaf certificates. Luckily there is only one code path so the fix location is obvious.
Note that the issue lies in how the check is performed: a client may present an arbitrary certificate from an arbitrary CA (even a self-signed one if it contains an
AuthorityKeyId
extension), which will be accepted, assuming it matches the AKID and Serial Number of a present, explicitly trusted leaf certificate.In particular, while the authenticity of the TLS connection is verified (insofar as the presented certificate matches the TLS channel via valid signature), the authorization check is malformed as it does not correctly tie the channel's connection key to the key contained in the certificate.
This check is sufficient to differentiate certificates from different CAs, say, for the purpose of chain building, but is not strong enough for authentication and authorization.
In the past, several CAs (such as the production grade Dogtag PKI or a manual OpenSSL CA) have defaulted to sequential serial numbers, though, AKIDs would likely still be unique unless key material was reused between different CAs (typically unlikely unless an intermediate CA was re-issued with the same key material but longer expiration).
However, most CAs correspond to the CA/BF's guidelines which require at least 20 bits of entropy, and thus would be less likely to run into this organically, even with reused CA public keys.
See also: https://github.com/hashicorp/vault/releases/tag/v1.14.10
See also: https://cabforum.org/working-groups/server/baseline-requirements/documents/
Resolves: #172
Target Release
Alpha