For what it's worth.. I think you are overcomplicating your setup here.
Unless your last "leg" of the connection between haproxy and the backend https server is running over an unsecure network (ie. internet or large LAN with no absolute control of the flowing traffic on the LAN) why insist that the connections really are encrypted? I mean - from the client to haproxy there's a pretty obvious reason for it, but as you must be in full control of what happens with the traffic as soon as it hits haproxy, there is no need for the overhead in talking https to the backends. I fully understand that your application requires logins etc to be encrypted, but as long as the connection between the client and haproxy has come through stunnel (you already have the listener on port 81 in place), you can have haproxy add a header that tells the backend that this request really was secure, and then have your app check that header instead of insisting on an SSL connection. And.. even if you had no control of the last leg, I wouldn't nessecarily rely on yet another stunnel encrypting every request to the backend. Why not use a SSL-based VPN connection like OpenVPN? That way your - perhaps far-away (network-wise) - backend would be quite local to haproxy with no risk of any middlemen intercepting the individual connections or content. Yes there is an overhead with any VPN, but so has stunnel. Regards, Jens Dueholm Christensen ________________________________ From: Tulga Kalayci [[email protected]] Sent: 22 February 2012 19:25 To: [email protected]; [email protected]; [email protected]; [email protected] Subject: RE: HAProxy Support Hi Cyril (& Baptiste), My name is Tulga, I work with Erick for our haproxy / stunnel implementation. As Erick mentioned before we are trying to achieve following: a) https client -> stunnel -> haproxy -> stunnel -> https server b) http client -> haproxy -> http server At the end; if page customer wants to visit is a https based page like login, traffic should flow based on option (a). For regular http pages traffic should flow based on option (b). I understand from your answer, flow (a) can be achieved using stunnel as a client. However we are not very sure how to configure stunnel for this scenario. Our current implementation is based on examples on the internet. Basically: stunnel listens 443, and sends stripped traffic to local port 81. haproxy listens local ports 80 & 81, and after inserting cookies send traffic remote ports 80 and 81 However since we lost SSL at the stunnel level, our IIS web server does not behave correctly for SSL required pages like login etc. Current configuration of stunnel as is follows: --------------------------------------------------------------- ; Protocol version (all, SSLv2, SSLv3, TLSv1) sslVersion = SSLv3 ; Some security enhancements for UNIX systems - comment them out on Win32 chroot = /var/lib/stunnel4/ setuid = stunnel4 setgid = stunnel4 pid = /stunnel4.pid ; Some performance tunings socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ;compression = zlib ; Some debugging stuff useful for troubleshooting #debug = 7 output = /var/log/stunnel4/stunnel.log ; Use it for client mode ;client = yes ;Service-level configuration [https] cert=/etc/stunnel/wildcard_com.crt key=/etc/stunnel/wildcard_com.key accept=443 connect=81 xforwardedfor=yes TIMEOUTclose = 0 ============================================= and our haproxy config is as follows: ============================================= global log /dev/log user debug maxconn 20000 #chroot /usr/share/haproxy user haproxy group haproxy daemon #debug #quiet defaults log global retries 3 option redispatch maxconn 2000 option dontlognull balance leastconn clitimeout 60000 srvtimeout 60000 contimeout 5000 listen http 0.0.0.0:80 mode http cookie WEBSERVERID insert #option httplog option tcplog balance source option forwardfor except 192.168.192.5 option httpclose option redispatch maxconn 10000 reqadd X-Forwarded-Proto:\ http server FE04 192.168.20.30:80 cookie A maxconn 5000 listen https 0.0.0.0:81 mode http cookie WEBSERVERID insert #option httplog option tcplog balance source option forwardfor except 192.168.192.5 option httpclose option redispatch maxconn 10000 reqadd X-Forwarded-Proto:\ https server FE04 192.168.20.30:81 cookie A maxconn 5000 -------------------------------------------------------- if you can provide some assistance, maybe an example about how to use stunnel as a client (and a server in the same time I guess), we will greatly appreciate. Thank you Tulga, Erick ----- Original Message ----- From: Erick Chinchilla Berrocal [mailto:[email protected]] To: [email protected] Sent: Wed, 22 Feb 2012 10:40:08 -0600 Subject: Fwd: Re: HAProxy Support -------- Original Message -------- Subject: Re: HAProxy Support Date: Wed, 22 Feb 2012 12:29:07 +0100 From: Baptiste <[email protected]><mailto:[email protected]> To: Cyril Bonté <[email protected]><mailto:[email protected]> CC: [email protected]<mailto:[email protected]>, Erick Chinchilla Berrocal <[email protected]><mailto:[email protected]> Hi Cyril, I was not available last days and I'm happy you were available to help people:) Let me keep on helping Erick. Basically, this kind of configuration is doable with stunnel. Stunnel has a "client" mode and so can be used to get connected to a backend server over SSL and keep on using all the layer 7 smart stuff from haproxy while providing SSL connections from client to server. cheers On Tue, Feb 21, 2012 at 10:36 PM, Cyril Bonté <[email protected]><mailto:[email protected]> wrote: > Hi all, > > Le 21/02/2012 21:10, Erick Chinchilla Berrocal a écrit : > >> Hi >> Thanks for your reply >> I made this change but the problem continues >> any other idea > > > OK, after discussing with Erick, it appears that the configuration worked, > but Erick had the need to reencode the haproxy output into HTTPS. > > Not sure it will still be a requirement, but in case it is, I oriented him > on stunnel client mode for such a "complex" case : > https client -> stunnel -> haproxy -> stunnel -> https server > > I won't be able to help him those next days, but maybe someone else can take > the relay, if he needs more help ;-) > > > -- > Cyril Bonté >
