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

Make TrustAnchor::try_from_cert_der less of an attractive nuisance #294

Open
briansmith opened this issue Oct 13, 2023 · 4 comments
Open

Comments

@briansmith
Copy link
Owner

Originally TrustAnchor::try_from_cert_der existed as a standalone function in the trust_anchor_utils submodule. During the time where we were trying to make the webpki API more idiomatic, we moved it to be TrustAnchor::try_from_cert_der. That makes it very visible and very easy to call; perhaps too easy. A normal user of webpki would not use it; it's really only for things that construct trust anchors stores, whereas the rest of webpki is designed for people who need to validate certificates given a trust anchor store from a trustworthy source.

A name like try_from_cert_der_from_trustworthy_source and/or moving it to a submodule that's more clearly labeled for its specialized target demographic would make it less of a hazard.

@briansmith
Copy link
Owner Author

One absolutely MUST NOT treat an end-entity certificate as a TrustAnchor, because a TrustAnchor is trusted for issuing other certificates; i.e. a TrustAnchor is a "root CA" and so it would be trusted to issue certificates for other websites. The way to implement "certificate error overrides" and TOFU and similar is NOT to do anything with TrustAnchor.

To further clarify, constructing a TrustAnchor from a self-signed certificate for the purpose of "accepting self-signed certificates" is absolutely NOT a safe way to implement such things.

@briansmith
Copy link
Owner Author

Any time you are thinking of using "self-signed certificate" or "end-entity certificate" and TrustAnchor together, you are almost surely on the verge of something that is very dangerous. webpki (and similar things, AFAICT) does not provide any facilities for helping with self-signed certificates or certificate error overrides.

@briansmith
Copy link
Owner Author

"Trust anchor" is defined in RFC 5280, in https://datatracker.ietf.org/doc/html/rfc5280#section-6.1.1 and other parts.

@est31
Copy link

est31 commented Oct 20, 2023

Any time you are thinking of using "self-signed certificate" or "end-entity certificate" and TrustAnchor together, you are almost surely on the verge of something that is very dangerous. webpki (and similar things, AFAICT) does not provide any facilities for helping with self-signed certificates or certificate error overrides.

What would be your recommendation for webpki users who want to use TOFU approaches for their app or similar?

Maybe if the Certificate is found as user-added exception, they should skip doing the verify_is_valid_tls_server_cert check and only do verify_is_valid_for_dns_name and verify_signature? Is there a security benefit for such users in not doing verify_is_valid_tls_server_cert?

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

No branches or pull requests

2 participants