Problem:
The ASN.1 stack in AWS-LC is old and full of attack surface. While most of the bugs have hopefully been fixed by now, it would be better to minimize its exposure. Also, the current code accepts tons of completely invalid certificates that are not DER-encoded.
Solution:
Use the new ASN.1 stack to validate all X.509 certificates before parsing them. This is easy to do for TLS, but harder to check for d2i_X509 because of the layers of macros.
- Does this change any public APIs? Certificates that are not valid DER will be rejected. The exact error codes may change.
- Which algorithm(s) will this impact? None.
Requirements / Acceptance Criteria:
What must a solution address in order to solve the problem? How do we know the solution is complete?
- RFC links: https://rfc-editor.org/info/rfc5280
- Related Issues: None
-
- Will the Usage Guide or other documentation need to be updated? Yes, to cover that AWS-LC is stricter than OpenSSL when it comes to certificates.
- Testing: Existing tests of the code should suffice, as long as they cover the entry points that have been ported.
- Will this change trigger AWS LibCrypto Formal Verification changes? No
- Should this change be fuzz tested? Existing fuzz tests should (hopefully) suffice.
Out of scope:
Replacing the old ASN.1 stack entirely.
Problem:
The ASN.1 stack in AWS-LC is old and full of attack surface. While most of the bugs have hopefully been fixed by now, it would be better to minimize its exposure. Also, the current code accepts tons of completely invalid certificates that are not DER-encoded.
Solution:
Use the new ASN.1 stack to validate all X.509 certificates before parsing them. This is easy to do for TLS, but harder to check for
d2i_X509because of the layers of macros.Requirements / Acceptance Criteria:
What must a solution address in order to solve the problem? How do we know the solution is complete?
Out of scope:
Replacing the old ASN.1 stack entirely.