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
