HAProxy community

Ha proxy as reverse proxy as WA for tlsv1.2->tlsv1

Hello,

I’m looking for a haproxy configuration which will allow me to implement the scheme bellow.

client --(https tlsv1.2)–> haproxy --(https tlsv1)–> legacy server

The current configuration doesn’t work. I hope someone will help me update it for my requirements.

global
log 127.0.0.1 local2
tune.ssl.default-dh-param 2048

defaults
log global
option httplog

timeout connect 10s
timeout client 30s
timeout server 30s
maxconn 1000

frontend https-frontend
mode http
option forwardfor
bind *:8899 ssl crt /root/cert/rootcert.pem
default_backend https-backend

backend https-backend
balance source
mode http
option forwardfor header X-Client
server endpoint 172.30.129.207:8443 check ssl verify none

As per your issue report and my response:

You are using the wrong curl call.

curl --verbose --insecure --proxy localhost:8899 -X GET 'https://www.google.com:8443'

This is wrong, because haproxy is not a forwarding, but a reverse proxy.

This is what your request needs to look like:
curl --verbose --insecure 'https://localhost:8899'

The site https://www.google.com:8443 was provided as example. In the real configuration, I used the internal sever - server1.local

The curl call works properly if I use http protocol
curl --verbose --insecure --proxy localhost:8899 -X GET ‘http://internal.server:8443
and in configuration I have
bind *:8899
and doesn’t work for
bind *:8899 ssl crt /root/cert/rootcert.pem

I can’t understand why. The issue happens if I use https and bind crt on the front end side.

--proxy localhost:8899 means a forward proxy without SSL at port 8899 on localhost; you’d have to use --proxy https://localhost:8899 to use SSL. That’s the reason the behavior changes when your drop the SSL keyword from port 8899 in the haproxy configuration.

You can find more about this in the curl manpage:

https://curl.haxx.se/docs/manpage.html#-x

However it is important to understand that this is NOT what you are supposed to use haproxy for. Haproxy is a reverse proxy and you SHOULD NOT be using the --proxy command in curl AT ALL.

I’m not exactly sure what you are trying to achieve here, but either your are just testing it wrong with curl, you are have the wrong expectation of what haproxy will do for you in the first place.

@lukastribus

You are right. I should not use the --proxy with curl for testing. Thank you for your support.

Could you give a suggestion how to configure a reverse proxy? Is configuration which I provided correct for scenario (client api) – (tls 1.2) --> (reverse proxy) – (tls 1) --> (legacy web service api)

Yes, the configuration is correct.

It could be that your backend server requires additional things though. For example, it could be possible that your server expects a certain Host header and maybe even SNI in the SSL handshake (however the latter is rather unlikely if we are talking about an old TLSv1.0 backend).

To rewrite the Host header you can do something like this in the backend:

http-request set-header Host api.example.org

To set the SNI value you need to add it to the server line:

server endpoint 172.30.129.207:8443 check ssl verify none sni str(api.example.org)

@lukastribus

Thank you for your support. Everything works properly as required.

Which the latest version of haproxy supports tlsv1.0 - tlsv1.3?

That depends on the OpenSSL version haproxy is linked against. Only OpenSSL 1.1.1 supports TLSv1.3.