On 08.07.2014 10:14, Baptiste wrote: > On Mon, Jul 7, 2014 at 12:17 PM, Dennis Jacobfeuerborn > <[email protected]> wrote: >> On 07.07.2014 08:57, Baptiste wrote: >>> On Mon, Jul 7, 2014 at 3:48 AM, Dennis Jacobfeuerborn >>> <[email protected]> wrote: >>>> Hi, >>>> I'm experimenting with the SSL capabilities of haproxy and I'm wondering >>>> if there is a way to detect if the client connected using SSL? >>>> >>>> The background is that I have two frontends one for SSL and one for >>>> regular http. In the SSL frontend I forward the requests to the http >>>> frontend via send-proxy. This part works well. >>>> The problem I have happens when I want to redirect non-SSL requests to SSL. >>>> The common way seems to be to put this in the http frontend: >>>> redirect scheme https if !{ ssl_fc } >>>> >>>> However since ALL requests arriving there are regular http requests >>>> (either received via port 80 or accept-proxy) this obviously ends in a >>>> redirect loop since ssl_fc only checks if the request received by the >>>> current frontend is a SSL one and not if the original request is. >>>> >>>> What seems to work is this: >>>> redirect scheme https if { dst_port eq 80 } >>>> >>>> This works around the problem but now I have to make sure that the port >>>> I check here matches the port in the bind statement. >>>> A cleaner way would be if I could check if the original request is a SSL >>>> one or not. Is this possible somehow? >>>> >>>> Regards, >>>> Dennis >>>> >>> >>> >>> Hi Dennis, >>> >>> You should not point your SSL frontend to your clear one. >>> Just use the clear one with a simple redirect rule to SSL one and make >>> the SSL one point to your backend. >>> And you're done. >> >> This makes sense but what I forgot to mention is that I use a >> configuration trick posted here a while ago where I bind SSL frontend to >> several cores to do the SSL offloading and then proxy the requests to >> the http frontend which is bound to a single core to do the >> load-balancing/ha/stats. If I remember correctly then doing the actual >> handling of that stuff on multiple cores is not recommended. >> This is the frontend config I use currently: >> >> listen front-https >> bind-process 2-4 >> bind 10.99.0.200:443 ssl crt /etc/pki/tls/certs/testcert.chain.pem >> ciphers >> ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM >> no-sslv3 >> reqadd X-Forwarded-Proto:\ https >> server clear abns@ssl-proxy send-proxy >> >> frontend front1 >> bind-process 1 >> bind 10.99.0.200:80 >> bind abns@ssl-proxy accept-proxy >> redirect scheme https if { dst_port eq 80 } >> default_backend back1 >> >> Regards. >> Dennis >> > > Hi Dennis, > > The answer stands in your frontend definition. > You properly set a X-Forwarded-Proto headers. > So to take your redirect decision, just look for it! > > Note that I moved your configuration to the new http-request rules. > > listen front-https > [...] > http-request set-header X-Forwarded-Proto https > server clear abns@ssl-proxy send-proxy > > frontend front1 > [...] > http-request redirect scheme https if { req.hdr(X-Forwarded-Proto) https } >
Well duh, I should have thought of that. Thanks! With this everything works as intended (just had to negate the condition for the redirect). Regards, Dennis
