On 12/24/21 09:08, Keith Burdis wrote: > From 53.2.9. SSL Session Encryption: > > > When SSL encryption can be performed, the server is expected to > send only the single S byte and then wait for the frontend to > initiate an SSL handshake. If additional bytes are available to > read at this point, it likely means that a man-in-the-middle is > attempting to perform a buffer-stuffing attack (CVE-2021-23222). > Frontends should be coded either to read exactly one byte from the > socket before turning the socket over to their SSL library, or to > treat it as a protocol violation if they find they have read > additional bytes. > > > An initial SSLRequest can also be used in a connection that is > being opened to send a CancelRequest message. > > > 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. > > > Has consideration been given to having something like > ssl-mode=tls-only where the SSLRequest message is skipped and the TLS > handshake starts immediately with the protocol continuing after that? > > This has several advantages: > 1) One less round-trip when establishing the connection, speeding this > up. TLS 1.3 removed a round-trip and this was significant so it could > help. > 2) No possibility of downgrading to non-TLS. (Not sure this is an > issue though.) > 3) Connections work through normal TLS proxies and SNI can be used for > routing. > > This final advantage is the main reason I'd like to see this > implemented. Postgres is increasingly being run in multi-tenant > Kubernetes clusters where load-balancers and node ports are not > available, cost or don't scale and it is currently difficult to > connect to databases running there. If it was possible to use normal > ingress TLS proxies, running Postgres in Kubernetes would be much > easier and there are other use cases where just using TLS would be > beneficial as well. > > Questions about TLS SNI support have been asked for several years now > and this would be a big usability improvement. SNI support was > recently added to the client-side and this seems like the next logical > step. > > Thoughts? > >
Isn't that going to break every existing client? How is a client supposed to know which protocol to follow? cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
