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