Re: Proposal: sslmode=tls-only

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