-
Notifications
You must be signed in to change notification settings - Fork 62
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
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. |
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 |
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:50002
server.To connect in an insecure manner either with
rustls
oropenssl
features, the user can set thevalidate_domain
field in theConfig
to false, this will either set theSslVerifyMode::NONE
when usingopenssl
, or use the customNoCertificateVerification
for therustls::client::danger::ServerCertVerifier
trait 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::SignatureScheme
properly, returning an empty vector at the moment. This PR focuses on fixing this issue by relying on theCryptoProvider
in 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_signature
andrustls::webpki::verify_tls12_signature
and 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
webpki
limitation 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
webpki
limitation instead ?Changelog notice
NoCertificateVerification
implementation for therustls::client::danger::ServerCertVerifier
to use therustls::SignatureScheme
fromCryptoProvider
in use.Checklists
All Submissions:
cargo fmt
andcargo clippy
before committingNew Features:
Bugfixes: