-
Notifications
You must be signed in to change notification settings - Fork 660
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
Working around invalid self-signed certificates #772
Comments
You can see here what the client does after receiving the server certificate: https://github.com/ctz/rustls/blob/main/rustls/src/client/tls13.rs#L724 In general, not doing hostname or expiration checking sounds like a really bad idea, where you essentially shift blame for any security issues that come up to your users. |
@djc I believe not checking hostname and probably also expiration is fine in this case. The short version is that if the certificate located on client is invalid (compromised) no additional check can help. If you have a bit of time I'd appreciate reviewing my detailed explanation of why I believe it is the case and letting me know if you see any mistake. If you don't I can understand. |
@Kixunil if you are asserting that you received the exact certificate, byte-for-byte, that you know the server is supposed to be sending, then it's irrelevant whether you check hostname or expiry in terms of preventing a MITM from impersonating the server. But as @djc says, you're pushing responsibility onto the user of your app/library to securely transfer that certificate out-of-band and store it, and things like revocation (e.g. if the server cert is compromised) become more complex and error-prone. IMO the automatic certificate generation of LND is a bit of an anti-feature for a production deployment. I helped with a deployment of LND where security was a concern, and we removed its automatic certificate generation and used cert-manager in CA mode to generate a certificate for it. It injects the cert + key on the LND side, and the cert-manager CA cert on the client side, where it's added as a trusted root. This way renewal and revocation can be handled sensibly too. You might consider something similar. |
I think I understand. I will add the option to use CAs instead then. I believe the direct verification still has its merits:
So despite allowing other forms of verification I do not intend to remove this feature nor stop using it myself. |
As Brian already locked the webpki thread, this is also off-topic for this repo. Please take further discussion to some other venue. |
I'm working on a project that uses rustls with tonic to connect to LND. By default, LND creates a self-signed end-entity certificate with no CA.
From reading other issues, in particular briansmith/webpki#114, we gather that such certificates can't be used with webpki, and thus rustls with the default configuration.
We don't have control of the certificates that LND generates, so we're trying to find a way to work around this.
Our hacky solution is have the user pass in LND's certificate, and pass it to a
ServerCertVerifier
implementation,SingleCertVerifier
, whoseverify_server_cert
function checks that the certificate presented by the server is byte-for-byte equal to the certificate that the user passed in. We aren't planning on doing hostname or expiration checking, because this cert was given to us by the user.Here is the current version of
SingleCertVerifier
: single_cert_verifier.rsOur assumption is that when using
SingleCertVerifier
,rustls
, during other parts of the TLS handshake, will still make sure that the server has the private key that matches the presented certificate, e.g. by verifying a signature from the server, so man-in-the-middle attacks are not possible.Is that assumption correct?
The text was updated successfully, but these errors were encountered: