Re: Introducing SNI in TLS handshake for SSL connections

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Introducing SNI in TLS handshake for SSL connections

Pablo Iranzo Gómez
Hi,

> On 4/24/17 22:26, Florin Asavoaie wrote:
> > If there's nobody against this, I can try to do the patch myself,
> > doesn't look too difficult (I expect it to simply work by
> > calling SSL_set_tlsext_host_name(SSL_context, PQhost(conn))) somewhere
> > in initialize_SSL in fe-secure-openssl.c.
>
> I had to look up what SNI is:
> https://en.wikipedia.org/wiki/Server_Name_Indication
>
> This seems useful.
>
> If you have a patch, please add it here:
> https://commitfest.postgresql.org/14/
>
> --
> Peter Eisentraut              http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
I came to this old thread while trying to figure out on how to setup postgres replication behind OpenShift/Kubernetes behind a route (which only forwards 80 or 443 traffic), but could work if SNI is supported on the client using it.

I haven't found any further follow-up on this, but based on the number of posts and questions on many sites on accessing postgres on OpenShift/Kubernetes it could be something good to have supported.

Any further information or plans?

Thanks,
Pablo


--

Pablo Iranzo Gómez ([hidden email])          GnuPG: 0x5BD8E1E4
Senior Software Engineer - Solutions Engineering           iranzo @ IRC
RHC{A,SS,DS,VA,E,SA,SP,AOSP}, JBCAA        #110-215-852    RHCA Level V

Blog: https://iranzo.github.io                     https://citellus.org

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Introducing SNI in TLS handshake for SSL connections

Andreas Karlsson
On 12/11/18 3:52 PM, Pablo Iranzo Gómez wrote:> I came to this old
thread while trying to figure out on how to setup
> postgres replication behind OpenShift/Kubernetes behind a route (which
> only forwards 80 or 443 traffic), but could work if SNI is supported on
> the client using it.
>
> I haven't found any further follow-up on this, but based on the number
> of posts and questions on many sites on accessing postgres on
> OpenShift/Kubernetes it could be something good to have supported.
>
> Any further information or plans?

I am pretty sure nobody is working on this.

It seems like it would be easy to implement (basically just call
SSL_set_tlsext_host_name() with the right hostname) with the only issue
being that we may need to add a new connection string parameter[1]
because I doubt all users would want SNI enabled by default since
PostgreSQL itself cannot do anything useful with the hostname, only some
kind of TLS proxy can. Hopefully there wont be much bike shedding about
the new connection parameter. :)

Feel free to write a patch if you have the time and submit it to the
next commitfest[2] for review.

Notes:

1. List of current options:
https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PARAMKEYWORDS
2. https://wiki.postgresql.org/wiki/CommitFest

Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Introducing SNI in TLS handshake for SSL connections

Pablo Iranzo Gómez
+++ Andreas Karlsson [11/12/18 18:18 +0100]:

>On 12/11/18 3:52 PM, Pablo Iranzo Gómez wrote:> I came to this old
>thread while trying to figure out on how to setup
>>postgres replication behind OpenShift/Kubernetes behind a route
>>(which only forwards 80 or 443 traffic), but could work if SNI is
>>supported on the client using it.
>>
>>I haven't found any further follow-up on this, but based on the
>>number of posts and questions on many sites on accessing postgres on
>>OpenShift/Kubernetes it could be something good to have supported.
>>
>>Any further information or plans?
>
>I am pretty sure nobody is working on this.
>
>It seems like it would be easy to implement (basically just call
>SSL_set_tlsext_host_name() with the right hostname) with the only
>issue being that we may need to add a new connection string
>parameter[1] because I doubt all users would want SNI enabled by
>default since PostgreSQL itself cannot do anything useful with the
>hostname, only some kind of TLS proxy can. Hopefully there wont be
>much bike shedding about the new connection parameter. :)
>
>Feel free to write a patch if you have the time and submit it to the
>next commitfest[2] for review.
Unfortunately I do not consider myself a coder, so if there is any way
to 'list' this as a 'nice to have' thing so that someone can take the
task and move it forward.

Thanks,
Pablo

>
>Notes:
>
>1. List of current options: https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PARAMKEYWORDS
>2. https://wiki.postgresql.org/wiki/CommitFest
>
>Andreas
>

--

Pablo Iranzo Gómez ([hidden email])          GnuPG: 0x5BD8E1E4
Senior Software Engineer - Solutions Engineering           iranzo @ IRC
RHC{A,SS,DS,VA,E,SA,SP,AOSP}, JBCAA        #110-215-852    RHCA Level V

Blog: https://iranzo.github.io                     https://citellus.org

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Introducing SNI in TLS handshake for SSL connections

Andreas Karlsson
In reply to this post by Pablo Iranzo Gómez
On 12/11/18 3:52 PM, Pablo Iranzo Gómez wrote:
> I came to this old thread while trying to figure out on how to setup
> postgres replication behind OpenShift/Kubernetes behind a route (which
> only forwards 80 or 443 traffic), but could work if SNI is supported on
> the client using it.

Hm ... while hacking at a patch for this I gave your specific problem
some more thought.

I am not familiar with OpenShift or Kubernetes but I want you to be
aware of that whatever proxy you are going to use will still need to be
aware of, at least a subset of, the PostgreSQL protocol, since similar
to SMTP's STARTTLS command the PostgreSQL client will start out using
the plain text PostgreSQL protocol and then request the server to switch
over to SSL[1]. So it would be necessary to add support for this to
whatever proxy you intend to use.

Do you know if adding such custom protocol support is easy to do to the
proxies you refer to? And do you have any links to documentation for
these solutions?

Notes

1. https://www.postgresql.org/docs/11/protocol-flow.html#id-1.10.5.7.11

Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Introducing SNI in TLS handshake for SSL connections

Pablo Iranzo Gómez
Hi Andreas

+++ Andreas Karlsson [13/12/18 01:30 +0100]:
>On 12/11/18 3:52 PM, Pablo Iranzo Gómez wrote:
>>I came to this old thread while trying to figure out on how to setup
>>postgres replication behind OpenShift/Kubernetes behind a route
>>(which only forwards 80 or 443 traffic), but could work if SNI is
>>supported on the client using it.
>
>Hm ... while hacking at a patch for this I gave your specific problem
>some more thought.

Thanks for this!

>
>I am not familiar with OpenShift or Kubernetes but I want you to be
>aware of that whatever proxy you are going to use will still need to

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.

>be aware of, at least a subset of, the PostgreSQL protocol, since
>similar to SMTP's STARTTLS command the PostgreSQL client will start
>out using the plain text PostgreSQL protocol and then request the
>server to switch over to SSL[1]. So it would be necessary to add
>support for this to whatever proxy you intend to use.
>
>Do you know if adding such custom protocol support is easy to do to
>the proxies you refer to? And do you have any links to documentation
>for these solutions?

I found some diagrams and other links to SSL and HAProxy in:

https://www.haproxy.com/fr/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/

Probably: https://tools.ietf.org/html/rfc6066#page-6

Let me know if this is not helpful, and thanks again for your time on
this.

Pablo


>
>Notes
>
>1. https://www.postgresql.org/docs/11/protocol-flow.html#id-1.10.5.7.11
>
>Andreas

--

Pablo Iranzo Gómez ([hidden email])          GnuPG: 0x5BD8E1E4
Senior Software Engineer - Solutions Engineering           iranzo @ IRC
RHC{A,SS,DS,VA,E,SA,SP,AOSP}, JBCAA        #110-215-852    RHCA Level V

Blog: https://iranzo.github.io                     https://citellus.org

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Introducing SNI in TLS handshake for SSL connections

Andreas Karlsson
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

ssl-sni-v1.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Introducing SNI in TLS handshake for SSL connections

Chapman Flack
On 12/13/18 08:07, Andreas Karlsson wrote:
> 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).

Here's the same patch with one small copy-pasto fixed.

-Chap

ssl-sni-v1a.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Introducing SNI in TLS handshake for SSL connections

Pablo Iranzo Gómez
In reply to this post by Andreas Karlsson
Hi,

+++ Andreas Karlsson [13/12/18 01:30 +0100]:

>On 12/11/18 3:52 PM, Pablo Iranzo Gómez wrote:
>>I came to this old thread while trying to figure out on how to setup
>>postgres replication behind OpenShift/Kubernetes behind a route
>>(which only forwards 80 or 443 traffic), but could work if SNI is
>>supported on the client using it.
>
>Hm ... while hacking at a patch for this I gave your specific problem
>some more thought.
>
>I am not familiar with OpenShift or Kubernetes but I want you to be
>aware of that whatever proxy you are going to use will still need to
>be aware of, at least a subset of, the PostgreSQL protocol, since
>similar to SMTP's STARTTLS command the PostgreSQL client will start
>out using the plain text PostgreSQL protocol and then request the
>server to switch over to SSL[1]. So it would be necessary to add
>support for this to whatever proxy you intend to use.
>
>Do you know if adding such custom protocol support is easy to do to
>the proxies you refer to? And do you have any links to documentation
>for these solutions?
I saw that they did incorporate some changes like SPDY support and other
http related things.

Let me try to find an answer (now sure how long will it take) and come
back.

I've did some basic search at
https://git.haproxy.org/?p=haproxy.git;a=summary but nothing evident
(for me).

I'll keep you updated.
Pablo


>
>Notes
>
>1. https://www.postgresql.org/docs/11/protocol-flow.html#id-1.10.5.7.11
>
>Andreas

--

Pablo Iranzo Gómez ([hidden email])          GnuPG: 0x5BD8E1E4
Senior Software Engineer - Solutions Engineering           iranzo @ IRC
RHC{A,SS,DS,VA,E,SA,SP,AOSP}, JBCAA        #110-215-852    RHCA Level V

Blog: https://iranzo.github.io                     https://citellus.org

signature.asc (235 bytes) Download Attachment