Jacob Champion <pchampion@vmware.com> writes:
> = Implicit TLS =
I think this idea is a nonstarter. It breaks backwards compatibility
at the protocol level in order to fix entirely-hypothetical bugs.
Nobody is going to like that tradeoff. Moreover, how shall the
server know whether an incoming connection is expected to use TLS
or not, if no prior communication is allowed? "TLS is the only
supported case" is even more of a nonstarter than a protocol change.
> = Client-Side Auth Selection =
> The second request is for the client to stop fully trusting the server
> during the authentication phase. If I tell libpq to use a client
> certificate, for example, I don't think the server should be allowed to
> extract a plaintext password from my environment (at least not without
> my explicit opt-in).
Yeah. I don't recall whether it's been discussed in public or not,
but it certainly seems like libpq should be able to be configured so
that (for example) it will never send a cleartext password. It's not
clear to me what extent of configurability would be useful, and I
don't want to overdesign it --- but that much at least would be a
good thing.
> ... Implementations could range from a simple "does the server's
> auth method match the single one I expect" to a full SASL mechanism
> negotation.
Again, any sort of protocol change seems like a nonstarter from a
cost/benefit standpoint, even before you get to the question of
whether a downgrade attack could defeat it. I'm envisioning just
having local configuration (probably in the connection string) that
tells libpq to fail the connection upon seeing certain auth requests.
regards, tom lane
