Re: Introducing SNI in TLS handshake for SSL connections

On 12/13/18 7:43 AM, Pablo Iranzo Gómez wrote:
> haproxy is what is used behind, the idea is that haproxy by default when
> enabled via a 'route' does allow http or https protocol ONLY, BUT
> (https://docs.openshift.com/container-platform/3.9/architecture/networking/routes.html), 
> 
> routers do support TLS with SNI.
> 
> As PSQL by default tries TLS and fallbacks to plain psql protocol the
> idea behind is that we tell OpenShift route to be 'Secure' and
> 'passtrough', in this way, when PSQL does speak to '443' port in the
> route that goes to the 'pod' running postgres using TLS and SNI, the
> connection goes thru without any special protocol change.

Sadly that confirms what I feared. Adding SNI to the PostgreSQL protocol 
wont help with solving your use case because the PostgreSQL protocol has 
its own handshake which happens before the SSL handshake so the session 
will not look like SSL to HA Proxy.

Just like HA Proxy does not support STARTTLS for IMAP[1] I do not think 
that it will ever support SSL for the PostgreSQL protocol, SNI or not.

To solve your use case I recommend using something like stunnel, which 
does support SNI, to wrap the unencrypted PostgreSQL protocol in SSL.

This all makes me very skeptical to if there is any realistic use case 
for adding SNI support to libpq, and just adding SNI support feels like 
adding a trap to people who do not know that they should rather use 
stunnel than PostgreSQL's built-in SSL support of they want to route on 
SNI with HA Proxy.

But I will attach my small patch for this, which I am now opposed to, 
anyway so the code exists if a use case turns up in the future (or if it 
turns out my reasoning above is incorrect).

Notes

1. 
https://www.haproxy.com/documentation/haproxy/deployment-guides/exchange-2010/imap4/

Andreas