tls-server-end-point channel binding

[conradludgate]

Checklist

• I've searched the issue tracker for similar requests

Is your feature request related to a problem? Please describe.

Implementing SCRAM-SHA-256-PLUS authentication for a postgres proxy server. Postgres only supports the tls-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 certificate

postgres-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 to Option<ring::digest::Digest>. Have this be an opt-in feature in the Server/ClientConfig as this will require extra runtime performance to calculate these digests

[djc]

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.

[conradludgate]

rustls connection types to always hang on to the certificate

My suggestion was to hang on only to the digest of the certificate, sorry if that wasn't clear.

when this is something that can be fairly straightforwardly implemented by the caller.

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 ClientHello struct so I had to expose an alternative inherent method rather than call ResolvesServerCert::resolve as one might expect

[Neustradamus]

@conradludgate: A nice ticket :)

It is important to have the support with RFC9266 too.