Expose unverified server certificate chains

[Mark-Simulacrum]

Security issue notifications

If you discover a potential security issue in s2n we ask that you notify
AWS Security via our vulnerability reporting page. Please do not create a public github issue.

Problem:

Applications using s2n-tls currently cannot access the server's certificate chain when certificate validation fails. The existing s2n_connection_get_peer_cert_chain API requires validation to have succeeded (S2N_ERR_CERT_NOT_VALIDATED is returned otherwise), which prevents applications from inspecting the certificate chain for logging or diagnostics when a handshake fails due to an untrusted or invalid certificate. This makes it harder to debug certificate validation failures, which currently return an opaque ("Certificate is untrusted") error which is not useful for debugging.

This would complement the existing s2n_connection_get_client_cert_chain API, which already provides this functionality for client-sent certificates.

Need By Date:

Sooner is better.

Solution:

A description of the possible solution in terms of S2N architecture. Highlight and explain any potentially controversial design decisions taken.

• Does this change what S2N sends over the wire? no
• Does this change any public APIs? yes, new public API
• Which versions of TLS will this impact? all versions

Possible problems to think through:

• How can we avoid increasing memory usage for all connections? Perhaps the chain can be removed after a successful handshake (since it's then available in the get_peer_cert_chain method? Or maybe we need an opt-in mechanism on the connection to enable collecting this information?
• What format is the cert chain in? Directly what is received on the wire? Are there any TLS version differences in that format?
• Can we improve the error message instead of or in addition to exposing the raw cert chain?

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links: n/a
• Related Issues: n/a
• Will the Usage Guide or other documentation need to be updated? just documentation on the new function
• Testing: How will this change be tested?
  • Will this change trigger SAW changes? probably no
  • Should this change be fuzz tested? Hopefully, no net-new surface area for untrusted input. Applications would need to deal safely with the untrusted output from the new function, but this shouldn't be a meaningful shift from what they already need to cope with for the client cert chain.

This will need to get exposed in the Rust bindings, so that it can then be exposed in s2n-quic (cc aws/s2n-quic#3037).

Out of scope:

• Safely parsing the returned chain is in customer hands.

[Mark-Simulacrum]

After some offline discussion, extending this issue with more related API surface area. For all of these we will want the information exposed via s2n-quic events as part of the delivery (can be unstable):

Local configuration

1. [Client + server local certificate chain] Expose the configured local certificate chain from an s2n-tls Connection. This would introspect what was configured on the Config, and return the default certificate chain. The certificate chain should roughly correspond to s2n_connection_get_selected_cert. selected_cert looks likely to be sufficient for this but I don't see tests for the handshake failure case, so adding/confirming test coverage may be the only s2n-tls ask.
2. [Client + server local trust store] Expose the configured trust store from an s2n-tls Connection. This could use the same 'serialization' as the cert_authorities extension (i.e., return distinguished names for each contained certificate). This should always be accessible, even if the particular connection didn't use the trust store.

Remote information

1. unverified_client_cert_chain exposed in s2n-quic
2. unverified_server_cert_chain added (the original ask in this issue)
3. server-sent certificate_authorities persisted out of the CertificateRequest as an s2n-quic event / s2n-tls accessor
4. client-sent certificate_authorities in ClientHello (new feature) also accessible