SSL behind a load balancer

[lracicot]

The 'is_ssl()' function does not support the X-Forwarded-Proto, which is the right way to verify if the request is https behind a load balancer.

The solution suggested in the codex (​http://codex.wordpress.org/Function_Reference/is_ssl) is to manually set the php server variable 'HTTPS', but this is not a good practice.

[lracicot]

The patch.

[nacin]

Replying to lracicot:

The solution suggested in the codex (​http://codex.wordpress.org/Function_Reference/is_ssl) is to manually set the php server variable 'HTTPS', but this is not a good practice.

I'd argue it's not a bad practice to keep the application ignorant of the overall proxying setup. This is ultimately an environment configuration issue; the application shouldn't need to figure out how the headers are forwarded (X-Forwarded-* is a de facto standard, but I've seen SSL in particular be forwarded in a number of ways), or whether they can be trusted (an X-* header can simply be set by the client, with no way of knowing if it came from a proxy).

Security aside (which is a dealbreaker), there is also a risk of infinite redirects for suddenly obeying these fields.

See also: #9235, #15009, #15733, #19337, #24394, etc.

[lracicot]

What I hear is that wordpress does not support and will not support ssl behind a load balancer. The reality here is that wordpress can be installed in a server without ssl, but with an https url (because it's behind a load balancer for example).

If the proposed solution isn't good enough, I'm still awaiting for a better one.

[nacin]

WordPress.org itself runs on SSL behind a load balancer. Our environment is such that the application layer is passed information about the requesting client, not the load balancer's UA, IP, or protocol.

The only thing we could consider is something like ​http://symfony.com/doc/current/components/http_foundation/trusting_proxies.html.

[wfaulk]

I would like to point out that the thing that you said you would consider explicitly says that "By default, the following proxy headers are trusted: … X-Forwarded-Proto", which is exactly what you rejected.

[tellyworth]

I agree with Andrew. There's simply no way to know if X-Forwarded-Proto can be trusted, and doing so naively opens the possibility of bugs and mischief.

The only reliable way to fix this is to ensure that the load balancer and server config accurately sets the PHP server vars.

[johnbillion]

Closing as a dupe of #31288 which is wontfixed. Note specifically comments 11, 13, and 17 on that ticket.