-
Notifications
You must be signed in to change notification settings - Fork 595
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
tls-server-end-point channel binding #1624
Comments
I don't think we'll want to maintain the logic for hash algorithm fallback that you link to in this crate. It's also not obvious to me that it makes sense for rustls connection types to always hang on to the certificate that is sent to the peer, when this is something that can be fairly straightforwardly implemented by the caller. |
My suggestion was to hang on only to the digest of the certificate, sorry if that wasn't clear.
I don't think this was too straightforward. It took me a while to determine how to arrange the certificate resolver. For single certificate services it's trivial. For multi certificate services it isn't so. It's also impossible to construct a |
@conradludgate: A nice ticket :) It is important to have the support with RFC9266 too. |
Checklist
Is your feature request related to a problem? Please describe.
Implementing
SCRAM-SHA-256-PLUS
authentication for a postgres proxy server. Postgres only supports thetls-server-end-point
channel binding method.On the client, there is the peer_certificates API that gives the server certificate bytes that can be digested. Unfortunately, there's still room to make mistakes here.
tokio-postgres-rustls
only uses the sha256 digest even though the specification says that you should use the signatureAlgorithm hash in the certificatepostgres-openssl
gets this correct.It's possible that rustls only supports signature algorithms using sha256, but that's an implementation detail and shouldn't be assumed.
Additionally, on the server side, there's no API to get the certificate used in that ServerConnection. For now, I've kept a copy of the CertResolver and resolved the certificate afterwards.
Describe the solution you'd like
ConnectionState
has a new method:tls_server_end_point()
that returns a type similar toOption<ring::digest::Digest>
. Have this be an opt-in feature in the Server/ClientConfig as this will require extra runtime performance to calculate these digestsThe text was updated successfully, but these errors were encountered: