-
Notifications
You must be signed in to change notification settings - Fork 68
fix(insecure-tls): NoCertificateVerification implementation
#150
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
fix(insecure-tls): NoCertificateVerification implementation
#150
Conversation
17a4152 to
a445252
Compare
NoCertificateVerification implementationNoCertificateVerification implementation
|
I also think we should update |
It updates the `NoCertificateVerification` implementation of `rustls::client::danger::ServerCertVerifier` trait, it keeps the usage of both `ServerCertVerified::assertion()` and `HandshakeSignatureValid::assertion()` usage, but now instead of having an empty vector vector of supported `SignatureScheme`, it uses the ones supported by the used `CryptoProvider`.
a445252 to
05771a8
Compare
|
I didn't really understand the nuance here but we should validate domains by default and then have an opt out I think. |
ValuedMammal
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 05771a8
This looks to be an improvement over what was there before and it fixes an issue that prevented connecting to an electrum server with a self-signed cert using rustls. I tested setting validate_domain = false and was able to get a response from each of blockstream's esplora, the server at "ssl://testnet.aranguren.org:51002" (fulcrum), and an electrs instance on my local network.
In the previous state, when using
Ideally, we SHOULD properly implement the verification on both Do you think it's fine to have this tradeoff? And, any thoughts on changing the parameter to |
notmandatory
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 05771a8
|
ACK 05771a8 I think we should change how this works soon but ACK this for now. People should not be using |
fixes #149 bitcoindevkit/bdk#1598
Description
It has been noticed some issues by both users and developers, as reported in #149, bitcoindevkit/bdk#1598 and wizardsardine/liana#1300, when using the library with
use-rustls-{ring}feature to connect to electrum servers that use self-signed certificates, there are even some issues when trying to connect tossl://electrum.blockstream.info:50002server.To connect in an insecure manner either with
rustlsoropensslfeatures, the user can set thevalidate_domainfield in theConfigto false, this will either set theSslVerifyMode::NONEwhen usingopenssl, or use the customNoCertificateVerificationfor therustls::client::danger::ServerCertVerifiertrait when usingrustls, that said it should ignore the certificate verification when used.At the current library state, it's failing because we didn't set up the supported
rustls::SignatureSchemeproperly, returning an empty vector at the moment. This PR focuses on fixing this issue by relying on theCryptoProviderin usage to get the correct and supported signature schemes.As part of the research to understand the problem, I've noticed that ideally, we should still use both the
rustls::webpki::verify_tls12_signatureandrustls::webpki::verify_tls12_signatureand only rely onrustls::client::danger::ServerCertVerified::assertion()to ignore the certificate verification, however, it would still fail in scenarios such as bitcoindevkit/bdk#1598 which uses X.509 certificates with any version other than 3 (it uses version 1), see here.I kept the current behavior to also ignore the TLS signature, but I still would like to bring this to the discussion, should we validate it properly and update the documentation to mention the
webpkilimitation instead ?Notes to the reviewers
I kept the current behavior to also ignore the TLS signature, but I still would like to bring this to the discussion, should we validate it properly and update the documentation to mention the
webpkilimitation instead ?Changelog notice
NoCertificateVerificationimplementation for therustls::client::danger::ServerCertVerifierto use therustls::SignatureSchemefromCryptoProviderin use.Checklists
All Submissions:
cargo fmtandcargo clippybefore committingNew Features:
Bugfixes: