Question about UNIX socket connections and SSL
It seems that libpq (maybe?) disables SSL when connecting through a UNIX socket to the database.
My setup involves a HA database cluster managed by Patroni. To route RW or RO connections to the correct node(s), we use haproxy, running locally on each application node. In the interest of being as efficient as possible, not using TCP unnecessarily, and having the ability to set appropriate permissions on the socket files which increases security, we had configured the applications to connect to haproxy via local UNIX socket, and then haproxy would of course communicate over the network to the database servers via TCP.
More recently, we've started setting up SSL encryption and CA verification for all database connections going over the network. I discovered when working on this that SSL was being disabled due to the client connecting to haproxy via UNIX socket. After trying a bunch of things, I resigned to having to use TCP, and we changed the connection from the app to haproxy to TCP.
We also have a jump server set up for staff to connect to the database via an SSH tunnel. When this is used, an individual's database connection goes from their client over TCP to the jump server via the SSH tunnel, which directs their connection to an haproxy instance running there via UNIX socket, which then in turn connects to the database using TCP. Interestingly, even though traffic is being routed through a UNIX socket here, SSL encryption *does* work.
So why can't I use SSL when connecting from a client to a UNIX socket? I can understand that verify-full wouldn't work without it, but verify-full doesn't work even when using TCP with haproxy, as "localhost" doesn't match the database hostname. For now, I'm only concerned with the verify-ca sslmode. Is there a workaround possible that doesn't involve using TCP unnecessarily?
--
Thanks,
- Casey
Casey & Gina <cg@osss.net> writes:
So why can't I use SSL when connecting from a client to a UNIX socket?
(1) It'd add overhead without adding any security. Data going through
a UNIX socket will only pass through the local kernel, and if that's
compromised then it's game over anyway.
(2) I'm less sure about this part, but I seem to recall that openssl
doesn't actually work if given a UNIX socket.
Maybe there are reasons why those arguments are obsolete, but you
haven't presented any.
regards, tom lane
On 12 Jun 2024, at 21:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Casey & Gina <cg@osss.net> writes:
So why can't I use SSL when connecting from a client to a UNIX socket?
(1) It'd add overhead without adding any security. Data going through
a UNIX socket will only pass through the local kernel, and if that's
compromised then it's game over anyway.(2) I'm less sure about this part, but I seem to recall that openssl
doesn't actually work if given a UNIX socket.
That indeed used to be the case, at least until 1.0.2 and possibly 1.1.1, but
AF_UNIX is supported in 3+ IIRC. That being said, I agree with your (1).
--
Daniel Gustafsson
On Jun 12, 2024, at 2:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
(1) It'd add overhead without adding any security. Data going through
a UNIX socket will only pass through the local kernel, and if that's
compromised then it's game over anyway.
That's true. My preference would be to have an unencrypted connection via UNIX socket from the application to haproxy, then an encrypted connection using SSL certificate authentication from haproxy to the database. I spent some time attempting this. But that doesn't seem to be possible since haproxy doesn't understand the postgres protocol.
--
Regards,
- Casey
On 12 Jun 2024, at 22:46, Casey & Gina <cg@osss.net> wrote:
..haproxy doesn't understand the postgres protocol.
While not strictly that, there was a patch not too long ago for teaching
postgres the PROXY protocol.
/messages/by-id/165903873765.1168.11139166899805820567.pgcf@coridan.postgresql.org
--
Daniel Gustafsson
On Jun 13, 2024, at 6:47 AM, Daniel Gustafsson <daniel@yesql.se> wrote:
While not strictly that, there was a patch not too long ago for teaching
postgres the PROXY protocol.
As I understand it, PROXY protocol support would be nice if one connects through haproxy on standalone hosts, so that postgres could show the originating app servers as the client_addr / client_hostname. We used to have standalone host haproxies, but moved to haproxy instances on each app node for performance and scalability reasons (many app nodes). I guess it could also help if we were to run pgbouncer on the db nodes?
We're using haproxy to route connections to the appropriate database nodes - RW connections go to the current master in the cluster, and RO are balanced between replicas. It seems that libpq could allow SSL on UNIX sockets which would avoid having to utilize TCP for the local connections from the application to haproxy.
Is there any way to utilize sslmode=verify-full through something routing connections to the appropriate database instances, whether that's with haproxy or something else?
--
Thanks,
- Casey