You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If s2n-tls receives a cert with an unsupported curve like secp192k1, it reports S2N_ERR_CERT_UNTRUSTED instead of a more accurate error like S2N_ERR_DECODE_CERTIFICATE, S2N_ERR_CERT_TYPE_UNSUPPORTED or S2N_ERR_CERT_INVALID. This was particularly confusing for a customer that had disabled certificate validation.
Solution:
This line needs to use GUARD instead of ENSURE, so that the actual underlying error is passed up. We'll also want to convert s2n_asn1der_to_public_key_and_type to s2n_result to make sure it's not returning anything non-standard like other functions in x509 have in the past.
Does this change what S2N sends over the wire? If yes, explain.
Does this change any public APIs? If yes, explain.
Which versions of TLS will this impact?
Requirements / Acceptance Criteria:
What must a solution address in order to solve the problem? How do we know the solution is complete?
RFC links: Links to relevant RFC(s)
Related Issues: Link any relevant issues
Will the Usage Guide or other documentation need to be updated?
Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
Will this change trigger SAW changes? Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
Should this change be fuzz tested? Will it handle untrusted input? Create a separate issue to track the fuzzing work.
Out of scope:
Is there anything the solution will intentionally NOT address?
The text was updated successfully, but these errors were encountered:
Problem:
If s2n-tls receives a cert with an unsupported curve like secp192k1, it reports S2N_ERR_CERT_UNTRUSTED instead of a more accurate error like S2N_ERR_DECODE_CERTIFICATE, S2N_ERR_CERT_TYPE_UNSUPPORTED or S2N_ERR_CERT_INVALID. This was particularly confusing for a customer that had disabled certificate validation.
Solution:
This line needs to use GUARD instead of ENSURE, so that the actual underlying error is passed up. We'll also want to convert s2n_asn1der_to_public_key_and_type to s2n_result to make sure it's not returning anything non-standard like other functions in x509 have in the past.
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:
Is there anything the solution will intentionally NOT address?
The text was updated successfully, but these errors were encountered: