For this specific case of http to https redirect I use the
X-Forwarded-Proto header. In the ssl frontend I do this:

http-request set-header X-Forwarded-Proto https

and in the plain http frontend I do this:

http-request redirect scheme https if !{ req.hdr(X-Forwarded-Proto)
https }

The problem here is that one could set that in a plain http request as
well and would avoid some redirects and whatnot, depending on what you
do based on what decision. You may also want the other SSL data, cipher,
version etc. Since 1.6 you can set variables, ok, but somehow passing
that kind of information could be really useful I guess.

I'd like to note that protecting headers like X-Forwarded-Proto from being sent by clients is a typical task for any kind of setup like this, especially in webservers.

What has to be done is simply to make sure that the component/backend/system that is supposed to receive and interpret the X-Forwarded-Proto header is *only* reachable from frontends, and that all of these frontends either set the header, make sure the header is not present, or do something with the request other than forwarding it to the backend (like rejecting the request outright).

Best regards,

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to