WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 4 years ago

#28443 closed defect (bug) (duplicate)

SSL behind a load balancer

Reported by: lracicot Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.6
Component: Security Keywords: close needs-patch
Focuses: Cc:
PR Number:

Description

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.

Attachments (1)

functions.diff (483 bytes) - added by lracicot 6 years ago.
The patch.

Download all attachments as: .zip

Change History (10)

@lracicot
6 years ago

The patch.

#1 in reply to: ↑ description @nacin
6 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

#2 @lracicot
6 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

Last edited 6 years ago by lracicot (previous) (diff)

#3 @nacin
6 years ago

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.

#4 @nacin
6 years ago

  • Milestone set to Awaiting Review

#5 @wfaulk
6 years ago

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.

#6 @tellyworth
5 years ago

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.

#7 @helen
5 years ago

  • Version changed from trunk to 2.6

#8 @chriscct7
4 years ago

  • Keywords close needs-patch added

#9 @johnbillion
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from reopened to closed

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

Note: See TracTickets for help on using tickets.