I liked the idea with separate ports for ssl and non ssl requests and tried it with haproxy. The psql-client connects with haproxy and receives the fixed 'S' byte response. After that he tried to continue on the same connection and doens't open a new one. This crashes the connection because haproxy expects a new tcp connection.
psqlClient: opens connection (ARP: SYN)
haproxy: accepts connection (ARP: SYN ACK)
psqlClient: confirmes the connection (ARP: ACK)
psqlClient: sends SSLRequest
haproxy: sends confirmation (ARP: ACK)
haproxy: sends fixed byte response ('S')
haproxy: closes connection (ARP: FIN, ACK)
psqlclient: confirmed fixed byte response (ARP: ACK)
psqlclient: sends ssl hello request --> error connection already
closed("psql: error: SSL SYSCALL error: No error (0x00000000/0))
In my eyes the problem lies in upgrading the connection rather then
opening a new one.
Am 14-Dec-20 um 14:50 schrieb Heikki Linnakangas:
On 12/12/2020 13:52, Lukas Meisegeier wrote:Thanks for the provided ideas :) I use HaProxy for my load-balancing and unfortunately I can't define that I want to listen on a port for both ssl and non ssl requests.Could you configure HaProxy to listen on separate ports for SSL and non-SSL connections, then? And forward both to the same Postgres server.That means if I try to return a fixed response 'S' on the SSLRequest it fails with an SSL-Handshake failure cause the server expects a ssl message.That doesn't sound right to me, or perhaps I have misunderstood what you mean. If you don't send the SSLRequest to the Postgres server, but "eat" it in the proxy, the Postgres server will not try to do an SSL handshake.I have to say the psql ssl handshake procedure is really unique and challenging :DYeah. IMAP and SMTP can use "STARTTLS" to switch an unencrypted connection to encrypted, though. That's pretty similar to the 'SSLRequest' message used in the postgres protocol. - Heikki
