|
|
|
|
|
|
by markonen
1219 days ago
|
|
|
I've been trying to shoehorn mTLS into existing infrastructure of Postgres clients and servers. This would be trivial if Postgres used straight-up TLS; as it is, though, you need sidecars that understand the Postgres wire protocol and that limits your choices to things like pgbouncer (which will add not-insignificant overhead) or Envoy (where the Postgres wire protocol support seems alpha quality or so). |
|
|
... does it not? (I really don't know, I've never had to admin postgres myself)
from https://www.postgresql.org/docs/current/ssl-tcp.html#SSL-SET...
> With SSL support compiled in, the PostgreSQL server can be started with support for encrypted connections using TLS protocols enabled by setting the parameter ssl to on in postgresql.conf. The server will listen for both normal and SSL connections on the same TCP port, and will negotiate with any connecting client on whether to use SSL. By default, this is at the client's option
wait so.. if it uses the same port for TLS, does it use STARTTLS?
from https://www.postgresql.org/docs/current/protocol-flow.html#i...
> To initiate an SSL-encrypted connection, the frontend initially sends an SSLRequest message rather than a StartupMessage. The server then responds with a single byte containing S or N, indicating that it is willing or unwilling to perform SSL, respectively. The frontend might close the connection at this point if it is dissatisfied with the response. To continue after S, perform an SSL startup handshake (not described here, part of the SSL specification) with the server. If this is successful, continue with sending the usual StartupMessage. In this case the StartupMessage and all subsequent data will be SSL-encrypted. To continue after N, send the usual StartupMessage and proceed without encryption.
and also from that section
> While the protocol itself does not provide a way for the server to force SSL encryption, the administrator can configure the server to reject unencrypted sessions as a byproduct of authentication checking.
.... that is not great. I mean zero disrespect to the postgres dev team, but why do this? I know (m)TLS has issues, but why would anybody want to have to trust/verify two codebases (the postgres bits before the handoff to openssl/boringssl/whatever) instead of just one (only openssl/boringssl), just to bootstrap to a secure client-server connection?
(this is my complaint about all upgrade-to-TLS schemes)