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 :D
>
> Yeah. 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
