[wp-trac] [WordPress Trac] #31288: IS_SSL should check return true for SSL Terminated load balancing

[WordPress Trac]

#31288: IS_SSL should check return true for SSL Terminated load balancing
-----------------------------+------------------------------
 Reporter:  bretterer        |       Owner:
     Type:  defect (bug)     |      Status:  reopened
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Security         |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:  has-patch close  |     Focuses:
-----------------------------+------------------------------

Comment (by dd32):

 Replying to [comment:10 chaoix]:
 > What about in addition to checking the X-Forwarded-Proto header we also
 check Remote-Addr
 > ...
 > It is not possible for the web server to be access via port 80 directly.

 In some configurations, it's possible for the server to be accessed
 directly which is a valid angle, for example, a server using a cloudflare
 front-end proxy.

 The
 [https://plugins.trac.wordpress.org/browser/cloudflare/trunk/cloudflare.php#L41
 cloudflare plugin] for example correctly updates the `REMOTE_ADDR` field
 if it's coming from the CF ip ranges.

 As has been rehashed in the many threads prior (and i'm doing again), the
 method to define it programmatically in a way that's useful for everyone,
 is almost certainly longer and more complex than simply fixing it
 according to the current environment, for example, to define it
 programmatically, it'd need something similar to this (with associated
 logic to handle all the wonderful edge cases)
 {{{
 define( 'HTTP_TRUSTED_HOSTS', '10.0.0.1' );
 define( 'HTTP_TRUSTED_HOST_PROTOCOL_HEADERS', 'HTTP_HTTPS' ); // on | off
 define( 'HTTP_TRUSTED_HOST_REMOTE_ADDR', 'HTTP_X_ORIGINATING_IP' ); //
 1.2.3.4
 or
 define( 'HTTP_TRUSTED_HOSTS', '10.0.0.5,10.0.0.6' );
 define( 'HTTP_TRUSTED_HOST_PROTOCOL_HEADERS', 'HTTP_X_FORWARDED_PROTO' );
 // http | https
 define( 'HTTP_TRUSTED_HOST_REMOTE_ADDR', 'X_FORWARDED_FOR' ); // "1.2.3.4,
 4.3.2.1, 10.0.0.5" (client, proxy, lb)
 }}}

 In contrast, for a server that isn't publicly accessible, these are the
 simple lines which you use in either `wp-config.php` or in nginx (to fix
 it reliable for every PHP application out there, WordPress included)
 (varied according to the environment of course, and you'd also have the
 downstream proxy setup to discard/overwrite conflicting headers)
 {{{
 $_SERVER['HTTPS'] = !empty( $_SERVER['HTTP_HTTPS'] ) ?
 $_SERVER['HTTP_HTTPS'] : 'off';
 $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_ORIGINATING_IP'];
 }}}
 or in nginx (which also provides modules to do this automatically when
 you're setting up a proxied environment - ngx_http_realip_module)
 {{{
 map $http_x_forwarded_proto $https {
     default off;
     https on;
 }
 fastcgi_param  HTTPS        $https;
 fastcgi_param  REMOTE_ADDR  $http_x_forwarded_for;
 }}}

--
Ticket URL: <https://core.trac.wordpress.org/ticket/31288#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform