Hi Peter, I imagine this also (finally) opens up the possibility for the server to present a different certificate for each hostname based on SNI. This eliminates the requirement for wildcard certs where the cluster is running on a host with multiple (typically two to three) hostnames and the clients check the hostname against SAN in the cert (sslmode=verify-full). Am I right? Is that feature on anybody's roadmap?
Cheers, Jesse On Mon, Feb 15, 2021 at 6:09 AM Peter Eisentraut <peter.eisentr...@enterprisedb.com> wrote: > > A customer asked about including Server Name Indication (SNI) into the > SSL connection from the client, so they can use an SSL-aware proxy to > route connections. There was a thread a few years ago where this was > briefly discussed but no patch appeared.[0] I whipped up a quick patch > and it did seem to do the job, so I figured I'd share it here. > > The question I had was whether this should be an optional behavior, or > conversely a behavior that can be turned off, or whether it should just > be turned on all the time. > > Technically, it seems pretty harmless. It adds another field to the TLS > handshake, and if the server is not interested in it, it just gets ignored. > > The Wikipedia page[1] discusses some privacy concerns in the context of > web browsing, but it seems there is no principled solution to those. > The relevant RFC[2] "recommends" that SNI is used for all applicable TLS > connections. > > > [0]: > https://www.postgresql.org/message-id/flat/CAPPwrB_tsOw8MtVaA_DFyOFRY2ohNdvMnLoA_JRr3yB67Rggmg%40mail.gmail.com > [1]: https://en.wikipedia.org/wiki/Server_Name_Indication > [2]: https://tools.ietf.org/html/rfc6066#section-3
