Add more SSL options to Config

[uce]

I was wondering whether you would be open to extending Config as follows:

• Add variants VerifyCa and VerifyFull to SslMode
• Add options sslcert, sslkey, sslrootcert

For context: We allow users to specify a connection string that we then pass directly to the client and we would like it to behave in a similar way as psql. We currently have to provide the above options "out-of-band".

I would understand if this is rejected since it does not affect the client directly, but only how to configure TLS support (which is the responsibility of the client user and not the client in the current design).

If you don't have any concerns with this, feel free to assign it to me.

cc @sfackler

[sfackler]

How would those options actually be consumed?

[uce]

@sfackler Thanks for asking! The sslcert, sslkey, sslrootcert options will actually have to stay "out-of-band" for us, so I'll ignore those (and update the ticket description).

The goal would be to mimic psql behaviour by configuring the SslConnector accordingly. For instance, we currently disable cert verification, because that's how psql behaves:

let mut builder = SslConnector::builder(SslMethod::tls_client())?;
// Currently supported sslmodes (disable, prefer, require) don't verify peer certificates
builder.set_verify(SslVerifyMode::NONE);
Ok(MakeTlsConnector::new(builder.build()))

If we had the additional modes verify-ca and verify-full, we would use those to decide when to enable cert verification. Within rust-postgres, the new modes would behave like require.

What do you think?

[sfackler]

But there is no interface to pass that configuration down to the TLS implementation currently.

[nyurik]

I was trying to implement same ssl options as available in psql, e.g. verify-full. Is there a path forward with this issue? It seems the issues with #774 were never resolved.

Ideally rust-postgres would handle TLS internally - via rustls by default, or for backward compatibility -- via openssl (feature flags), but at the moment the structure of the lib seems to delegate all TLS configuration to the user, which creates multiple fairly complex and sometimes buggy implementations.

[nyurik]

I did another, much simpler take on solving this in #988, hopefully this is more palatable to everyone, while it will unblock all those who want to use this functionality.

[WGH-]

If we wish to do it the same way as libpq and other libraries do - well I think we do - then in my opinion we should change MakeTlsConnect trait to something roughly like this:

pub trait MakeTlsConnect<S> {
    type Stream: TlsStream + Unpin;
    type TlsConnect: TlsConnect<S, Stream = Self::Stream>;
    type Error: Into<Box<dyn Error + Sync + Send>>;

    // Required method
    fn make_tls_connect(
        &mut self,
        cfg &tokio_postgres::Config,
        domain: &str
    ) -> Result<Self::TlsConnect, Self::Error>;
}

libpq connection strings specify whether TLS is desired/required, where CA lies, what client certificate to use, etc. So we can't really build a connector without the config/connection string.

This would be a breaking change, but I don't see a way to do this without changing the trait.

If this change looks OK, I can try to make a PR.