Please see #7439

I think, we should not change a value of a super global variable $_SERVER['https']. All we need to do is to prevent infinite rederect loops and blocking of external resources by browsers as insecure (Joomla! sets wrong links because of that). For those, who are looking for a workaround, I can suggest Apache mod_rewrite directives:

RewriteCond %{HTTP:X-FORWARDED-PROTO} =https [NC] 
RewriteRule .? - [E=HTTPS:on]

But it would be better if it works out-of-the-box.

i agree with @addondev, the $_SERVER['HTTPS'] super global variable shouldn't be changed by Joomla. So, IMHO, this PR is more correct than #7439.

@addondev please check the code style issues

FILE: /home/travis/build/joomla/joomla-cms/libraries/joomla/uri/uri.php
--------------------------------------------------------------------------------
FOUND 2 ERROR(S) AFFECTING 2 LINE(S)
--------------------------------------------------------------------------------
66 | ERROR | Whitespace found at end of line
67 | ERROR | Each line in a multi-line IF statement must begin with a boolean operator
--------------------------------------------------------------------------------

agree about the global variables, but check this comment

@piotr-cz,
Do you mean a possible MITM attack? But this code affets only the class JUri. Joomla! will build links with a protocol http or https, according to the variable $_SERVER['HTTP_X_FORWARDED_PROTO']. How can an attacker take advantage of this?

@addondev In the request attacker will set the X_FORWARDED_PROTO header, which will translate to HTTP_X_FORWARDED_PROTO in the $_SERVER variable.

There is no good solution here, maybe a switch in the global configuration such as:

https support

• auto (based on $_SERVER['HTTPS'])
• on: forced
• on: for loadbalancer IPs whitelisted below

@piotr-cz,
An attacker sets the X_FORWARDED_PROTO header, and the JUri class returns https links instead of http links? I agree with you, but I can't understand the profit for an attacker.

In the MITM attack, attacker could sniff sensitive information, if application would be tricked in being in SSL connection based on the JUri instance:

if (JUri:::getInstance()->getScheme() == 'https')
{
    // Secure checkout
}
else
{
    // Redirect to https
}

@piotr-cz
Now I agree. I think, your argument is good enough for closing this PR and the other PRs on this issue as well. We need a strong concept. By now I resolve this issue by a verification in the httpd.conf

RewriteCond %{REMOTE_ADDR} =127.0.0.1
RewriteCond %{HTTP:X-FORWARDED-PROTO} =https
RewriteRule .? - [E=HTTPS:on]

There is no information about a solution in manuals, may be we could write it for the public.

So you think it's better to not support SSL termination at all just so you prevent a theoretical MITM attack when it's setup incorrectly (i.e. when HTTP access is still possible)?

RewriteCond %{HTTP:X-FORWARDED-PROTO} =https [NC]
RewriteRule .? - [E=HTTPS:on]
its not work in PHP CGI mode

@denverkurt, your hosting provider must set a header in NGINX proxy_set_header X-Forwarded-Proto https in order to make it work.

no

i use one provider
if use PHP as fastCGI - it work
if use PHP as CGI - not work

header isset X-Forwarded-Proto

@denverkurt proxy_header is not the same as fastcgi_param.

header set in NGINX proxy_set_header X-Forwarded-Proto https !!!

Perhaps, CGI module is old enough and does not recieve headers from a load balancer. CGI protocol was introduced in the 1990’s.