@cdornsife Here is a quick CS PR that should make travis happy. Can you have a look: cdornsife#2

Do we have any chance to test this or is this special envoirment needed?

+1 looks awesome. Tested this with an ELB and seems to be working as described.

Apparently a request header x-forwarded-proto added by client (ie. browser) will be interperted as $_SERVER['HTTP_X_FORWARDED_PROTO'].

See joomla/joomla-framework#212.

If I might suggest:

• WebSec 101: don't blindly trust anything coming from user side. Attack vector: attacker manually sets this header in request. This patch will fool the rest of the Joomla it's now talking HTTPS, while it isn't. MITM attack can begin
  • that's why the patch code should at least also check for a valid loadbalancer IP before considering fooling itself it's HTTPS
• I think enable/disable protocol check and valid loadbalancer IP(s) should be the Global Conf parameters
• if possible, avoid directly poking the superglobal variables, it can easily break any consequent code. (Most) superglobals should be considered as "unclean" (needing sanitization) but left untouched in original state

If SSL offloading is used the web server would be listening on HTTP so yes, a MITM is possible. My guess is if there is a load balancer, the following things would also be likely:

• Using firewall rules to only allow HTTP from the LB.
• The web server(s) are on a private network.

Besides, AWS ELBs don't have IPs that stay the same for very long.

The toggle is a great idea.

Yeah, that would be a perfect setup. But still, a network range filter would be much appreciated.

AWS, Cloudlfare, etc might change IP range from time to time, but the need of updating the IP/-range from time to time shouldn't bother the user if security is important.

Maybe the service provider would give some hints?
I mean, it should be their interest too to provide secure service

Just an additional info, the standartized HTTP Header "Forwarded" has been defined in RFC 7239 (https://tools.ietf.org/html/rfc7239) by the IETF.

Example: Forwarded: for=192.0.2.60; proto=http; by=203.0.113.43

@cdornsife Can you provide test instructions?

@cdornsife @btoplak What is the status of this pull request?

I completely agree with @btoplak you can not blindly trust everything the client sends and just rely on the check.
You need a perfect network setup and Global Config Setting to configure a list of Reverse Proxy and Load Balancing IPs and Network Ranges.
Without this it's easily possible to spoof the information.

The fix to let Joomla check the forward header is correct, but for security improvements it needs to have a extra check which can be configured through the Global Settings from which source the forward is created.

• The joomla server in this scenario is HTTP only, this example is for SSL termination at the load balancer.
• An AWS ELB changes IPs at random, this breaks systems who rely on IPs like NGINX. See this: https://tenzer.dk/nginx-with-dynamic-upstreams/
• What is the point of specifying an IP range that is the entire spectrum of amazon IPs, and then putting that burden onto a CMS system?

I submitted this hoping it will be useful to someone else who get's the redirect loop. This patch has no issues providing it is used in a properly set up VPC with security rules.

@cdornsife why did you close it ? still seems valid to me
it's pretty well documented at https://tools.ietf.org/html/rfc7239#section-5.4 mentioned above.
What would not to be trusted about using an https protocol to the client? 0_o

Some additional data points — first the most basic one, the remote_addr i.e. $_SERVER['REMOTE_ADDR'] contains the IP of the load balancer(s). We've long used the load balancer IP address(es) as a lock variable in other systems.
The IP addresses under ELB (and similar systems) are from your instances VPC i.e. they're in the same IP block.
Finally it's a trivial setup to have your VPC only accessible via the load balancer.

Surely there's a solution in there that Joomla could implement?