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.
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.
I searched for some way to forward to a default backend on ssl failure
but this seems to be no use-case for haproxy and isn't supported.
I also didn't find any other tcp-loadbalancer, which could handle this
type of ssl-failure fallback.
My only option would therefore be to write a custom loadbalancer for
this usecase, which is not really feasible given the amount of features
of haproxy I plan to use.
I have to say the psql ssl handshake procedure is really unique and
challenging :D
The tool stunnel is capable of this protocol but I can't do sni-based
loadbalancing with it so this is kind of a dead end here.
Lukas
Am 11-Dec-20 um 16:44 schrieb Heikki Linnakangas:
> On 11/12/2020 16:46, Lukas Meisegeier wrote:
>> Hey Heikki,
>>
>> thanks for providing feedback :)
>> The traffic between proxy and psql-server is unencrypted thats why I
>> don't need to patch the server.
>
> Ok.
>
>> I tried returning a fixed response on the first plain SSLRequest
>> forwarding it to a psql-server with ssl enabled an tried to switch then
>> on the ssl connection startup but that didn't work out. I guess its
>> because the psql-server won't accept an ssl connection if its not
>> requested via SSLRequest.
>
> Your proxy could receive the client's SSLRequest message, and respond
> with a single byte 'S'. You don't need to forward that to the real
> PostgreSQL server, since the connection to the PostgreSQL server is
> unencrypted. Then perform the TLS handshake, and forward all traffic to
> the real server only after that.
>
> Client: -> SSLRequest
> Proxy: <- 'S'
> Client: -> TLS ClientHello
> Proxy: [finish TLS handshake]
>
> - Heikki
