-
Notifications
You must be signed in to change notification settings - Fork 114
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
Rustls support #1182
base: main
Are you sure you want to change the base?
Rustls support #1182
Conversation
this allows for future TLS providers to be added
also change some reference to SSL to TLS where relevant
otherwise the error shows up too late in a non-terminal way whereas the error is terminal
See the following report for details: cargo semver-checks output
|
@nrxus, please let us know the next time when you are planning to create a PR with nontrivial changes, so that we discuss it first. We've already started working on this issue; being in-sync could have brought benefit to both of us and avoid work duplication. Apart from that, we're happy to see another contribution from you! I'm going to review it soon and compare it to our intended solution. |
That's my bad, I totally meant to message on the old PR first but I was first waiting to see if I could even do this PR on my own or not (I am no TLS expert) and once it worked I got triggered happy on making the PR. I'll definitely contact you all first when I see a change becoming non-trivial. Feel free to close this PR if taking it in is more work than just finishing what you all already had in mind (: |
impl TlsInfo { | ||
fn from_pem(cert: &[u8], key: &[u8]) -> Result<Self, TlsError> { | ||
#[cfg(feature = "openssl")] | ||
{ | ||
let cert = openssl::x509::X509::from_pem(cert)?; | ||
let key = openssl::pkey::PKey::private_key_from_pem(key)?; | ||
Ok(TlsInfo::OpenSsl { key, cert }) | ||
} | ||
|
||
#[cfg(all(not(feature = "openssl"), feature = "rustls"))] | ||
{ | ||
use rustls::pki_types::pem::PemObject; | ||
let key = rustls::pki_types::PrivateKeyDer::from_pem_slice(key)?; | ||
let cert_chain: Vec<_> = rustls::pki_types::CertificateDer::pem_slice_iter(cert) | ||
.collect::<Result<_, _>>()?; | ||
Ok(TlsInfo::Rustls { cert_chain, key }) | ||
} | ||
} | ||
} |
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.
💭 This seems to work. In case of both openssl
and rustls
features being enabled, openssl is chosen. Fortunately, as this is the creation of TlsInfo
, it's the only place where we have to do such logic based on features; in other places we're just matching on TlsInfo
.
@nrxus Will it be OK for you if I just cherry-pick your commits and rework them more or less for our implementation? This is a valuable work for us! |
Yeah that's absolutely okay! I am glad it's useful, I look forward to all the nice changes in the next release |
@nrxus Could you please elaborate on the following:
? What did you observe under what circumstances? |
I had done something wrong in the creation of the certs if I remember correctly (the CN didn't match the IP of the nodes and the self-signed CA didn't have the root CA extension marker). Then when connecting my program would not immediately show up the error but instead it would show errors as it attempted to retry every so often, but it wasn't even an error log (I don't remember if it was a debug or info log though). Once I stopped ignoring the error then the error was a lot more clear and it in fact immediately failed when creating the session ( as expected). |
Fixes #293
This is based on the work and discussion on #911
Movement on that PR seems to have stalled but it seemed like you all wanted to do this as part of the other breaking changes for v1.0 so I wanted to get this PR into your eyes prior to that.
Main breaking changes are:
ssl
items that were meant to be generic over the TLS drivers o betls
instead as that is more accurate (although I know they are sometimes used interchangeably) (e.g.,ssl_context
totls_context
)ssl
feature flag to beopenssl
cloud
feature flag no longer auto-enablesopenssl
. This is done so users can choose if they want to enableopenssl
and/orrustls
. We could add a check in the code that says that ifcloud
is enabled and there is no tls-related feature flag then hard compile error. It currently will already not compile but the error won't be as nice I think.Other caveats:
For the
cloud
feature, if bothopenssl
andrustls
are enabled, the current code defaults to usingopenssl
to keep it slightly more consistent with the old code. I think defaulting torustls
may provide a slightly better experience since it doesn't require any linking (dynamic nor static) but I wasn't sure what you all would prefer, it's easy enough to change.For non-cloud, if both
openssl
andrustls
are enabled, the user has a choice at runtime of whatTlsContext
to pass.I do not have a cloud account for scylla so I have not manually tested the cloud changes.
The certificates in the test directory use a version that
rustls
does not support so they are not useful for therustls
example. I was unable to create new certs from the existing self-signed CA in the test directory because I do not know the passphrase. I have, however, tested that it works using my own certificates in a self-hosted 3-node Scylla instance in AWS that has TLS enabled for client-node communication.The existing tests only test when using
openssl
, we could (and probably should) add tests for therustls
feature but that requires making the right certs thatrustls
can use.Pre-review checklist
./docs/source/
.Fixes:
annotations to PR description.