Hello all, Now that the MITM CVEs are published [1], I wanted to share my wishlist of things that would have made those attacks difficult/impossible to pull off.
= Implicit TLS = The frontend/backend protocol uses a STARTTLS-style negotiation, which has had a fair number of implementation vulnerabilities in the SMTP space [2] and is where I got the idea for the attacks to begin with. There is a large amount of plaintext traffic on the wire that happens before either party trusts the other, and there is plenty of code that touches that untrusted traffic. An implicit TLS flow would put the TLS handshake at the very beginning of the connection, before any of the frontend/backend protocol is spoken on the wire. (You all have daily experience with this flow, by way of HTTPS.) So a verify-full client would know that the server is the expected recipient, and that the connection is encrypted, before ever sending a single byte of Postgres-specific communication, and before receiving potential error messages. Similarly, a clientcert=verify-* server would have already partially authenticated the client before ever receiving a startup packet, and it can trust that any messages sent during the handshake are received without tampering. This has downsides. Backwards compatibility tends to reintroduce downgrade attacks, which defeats the goal of implicit TLS. So DBAs would probably have to either perform a hard cutover to the new system (with all-new clients ready to go), or else temporarily introduce a new port for the implicit TLS mode (similar to HTTP/HTTPS separation) while older clients are migrated. And obviously this doesn't help you if you're already using a different form of encryption (GSSAPI). I'm ignorant of the state of the art for implicit encryption using that method. But for DBAs who are already deploying TLS as their encryption layer and want to force its use for every client, I think this would be a big step forward. = 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). Auth negotiation has been proposed a couple of times on the list (see for example [3]), and it's already been narrowly applied for SCRAM's channel binding, since allowing a server to sidestep the client authentication defeats the purpose. But I'd like to see this applied generally, so that if the server sends an authentication request that my client hasn't been explicitly configured to use, the connection fails. Implementations could range from a simple "does the server's auth method match the single one I expect" to a full SASL mechanism negotation. WDYT? Are these worth pursuing in the near future? --Jacob [1] https://www.postgresql.org/about/news/postgresql-141-135-129-1114-1019-and-9624-released-2349/ [2] https://www.feistyduck.com/bulletproof-tls-newsletter/issue_80_vulnerabilities_show_fragility_of_starttls [3] https://www.postgresql.org/message-id/flat/CAB7nPqS-aFg0iM3AQOJwKDv_0WkAedRjs1W2X8EixSz%2BsKBXCQ%40mail.gmail.com
