This one will need careful testing.

@bpeterson69 will you fix this PR?

I believe I have fixed the PR

What do I need to do to get this patch moved into the base branch?

Provide indepth reasoning behind the PR, indepth testing instructions for both setting up a failing infrastructure, and the expected verses actual results and providing accurate and indepth testing instructions.

Cant merge things that no one understands, cant merge things that no one can get up to speed with and test.

The reason behind the PR is to prevent client browsers going into an infinite redirect loop when Joomla is set to require SSL. The problems presents itself when Apache is configured as a reverse proxy (Apple is deploying Apache as a reverse proxy in Server 5.0.15 and later). The $_SERVER array that Apache returns in this case does not have the key 'HTTPS'. The patch adds additional sanity checking to validate against a different key in the $_SERVER (the key is 'HTTP_X_FORWARDED_PROTO ') array to prevent an infinite redirect loop.

The way the problem manifests itself is as follows:

1. Install Joomla on an Apple Server running Server 5.0.15 or later.
2. In the Administration interface, goto Global Configuration->Server.
3. Set Force SSL to Entire Site.
4. Now when you try to browse to the site, you will get a "to many redirects" error in your browser.

The reason you get this error is the current version of uri.php checks for the value of $_SERVER['HTTPS'] to verify if the client is connecting via SSL. Here is what essentially happens at this point:

The user loads the website, doesn't matter if it is HTTPS or HTTP. The uri.php file checks the variable $_SERVER['HTTPS'] to validate if the user has arrived at the site over SSL or not. Since the $_SERVER array does not have the key "'HTTPS', uri.php decides that the user has not arrived via HTTPS and forces the user to reload the page over SSL, again, the $_SERVER array does not have the key 'HTTPS' so again, Joomla assumes the user has not arrived via HTTPS and does the redirect again. This continues until the browser gives up and gives the error "To many redirects".

The patch I have created leaves the original code in place for the validation of the $_SERVER['HTTPS']. It adds additional validation against the key the reverse proxy is returning in the $_SERVER array that indicated SSL or not. You can look at the contents of the $_SERVER array in the comment I made on Dec 22.

I have received reports that Cloudflare uses reverse proxy as well and this patch resolves the issue.

Please let me know if you need more information.

Here are two messages I received on the patch (not sure why they aren't listed here).

The example code is kindly specified above by line number, in place of pre--- & post+++ change notation.

The issue raised is more frequent than suggested.

Test latest Joomla using CloudFlare and enable their SSL. Put the debugger on and review your site in HTTPS and you will see the lockups + database down issues with too many redirects = refused connection in some MySQL configs. Circular hits are throttled at the database connection level on some servers or the browser stops on multiple redirects. Also see the page reference javascript code being rejected then make this change to core as suggested ... (sorry folks, core change not recommended but to prove a point).

CloudFlare + SSL works after applying this amendment.

My site now runs in CloudFlare SSL: https://broadbandwithoutaphoneline.com/

SSL "free as in beer..."

My thanks to bpeterson69.

Anton
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/7916.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

and

Fixed the issue for me on J 3.6.2, also when using Cloudflare free SSL. Clearly something that needs implemented.

This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/7916.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Those comments are on your older issue of #7916

On 27 October 2016 at 00:02, bpeterson69 notifications@github.com wrote:

Here are two messages I received on the patch (not sure why they aren't
listed here).

The example code is kindly specified above by line number, in place of
pre--- & post+++ change notation.

The issue raised is more frequent than suggested.

Test latest Joomla using CloudFlare and enable their SSL. Put the debugger
on and review your site in HTTPS and you will see the lockups + database
down issues with too many redirects = refused connection in some MySQL
configs. Circular hits are throttled at the database connection level on
some servers or the browser stops on multiple redirects. Also see the page
reference javascript code being rejected then make this change to core as
suggested ... (sorry folks, core change not recommended but to prove a
point).

CloudFlare + SSL works after applying this amendment.

My site now runs in CloudFlare SSL: https://broadbandwithoutaphoneline.
com/

SSL "free as in beer..."

My thanks to bpeterson69.

Anton
This comment was created with the J!Tracker Application at
issues.joomla.org/joomla-cms/7916.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

and

Fixed the issue for me on J 3.6.2, also when using Cloudflare free SSL.
Clearly something that needs implemented.

This comment was created with the J!Tracker Application at
issues.joomla.org/tracker/joomla-cms/7916.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#8690 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8W3qwxYVCTjCuTrktdeKl47XzBh_ks5q39wFgaJpZM4G1TRr
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

Is this the same thing as https://www.simbunch.com/products/free-extensions/cloudflare-for-joomla

Im not saying this is not needed - as I have seen this many times and I fully understand the issue

But, basically you have an insecure site, running on http/80 and SSL termination is done by a remote proxy, which then sends the data in clear text to your origin server on http/80 ... hardly secure... especially if the origin server still accepts direct requests and has not been firewalled to accept traffic ONLY from the proxy.

Is this the same thing as https://www.simbunch.com/products/free-extensions/cloudflare-for-joomla

Dunno - was unable to register on their site to download the free extension :(

I was asking if the issue was the same more than is the solution the same

But not installed it etc - its late but here you are
http://i.tee.mn/cloudflareunissl_system.zip (I already had an account)

On 27 October 2016 at 00:08, Phil Taylor notifications@github.com wrote:

Is this the same thing as https://www.simbunch.com/
products/free-extensions/cloudflare-for-joomla

Dunno - was unable to register on their site to download the free
extension :(

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#8690 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8ZUM3D7RFX9eKKMj1iR3CTWnM8cgks5q3910gaJpZM4G1TRr
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

So the answer is yes the issue is the same, but no the solution is not exactly the same

That plugin uses CloudFlare SPECIFIC headers to turn on ssl

if ( isset( $_SERVER['HTTP_CF_VISITOR'] ) && strpos( $_SERVER['HTTP_CF_VISITOR'], 'https' ) !== false ) {
            $_SERVER['HTTPS'] = 'on';
            $uri = JFactory::getURI();
            $uri->setScheme('https');
        }

I have tested this item ✅ successfully on af3aad6

I have tested this locally with a local set up just to test this issue, and Im happy it works as expected. Other projects have implemented the same logic to prevent the same issue. There is a security issue in that HTTP_X_FORWARDED_PROTO headers can be forged, but as we are not relying on anything other than just switching on https for the site, and we are not evaluating or processing this user provided data without sanitation, then this can be ignored (again just like other PHP Projects)

We could think about applying the same logic to vendor specific headers like the CloudFlare HTTP_CF_VISITOR however I dont believe that we should... no matter how big CloudFlare are :-)

I understand the concern. In this case, not implementing the patch protects people from creating a security issue that they my not be aware of if they don't deploy it properly.

Exactly - unless the origin server is firewalled and only accepts incoming connections from the proxy then the infrastructure is insecure. However this is beyond the scope of the Joomla core code to educate people of that.

This is a good guide to setting up this kind of secure setup
https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-load-balancing-with-ssl-termination

In an insecure set up the User could bypass the proxy and access the origin servers with no https... MITM attacks, and DNS Spoofing could cause data loss... but again thats much more detail than Joe Bloggs and his Joomla site will ever care about, he just wants to use CloudFlare's free ssl termination and not have a redirect loop - well, this PR resolves that for CF and other SSL Terminating Proxy servers.

I have tested this item ✅ successfully on af3aad6

I have deployed this item across 5 Joomla Sites for several months (every time a new version of Joomla comes out). I understand the concern about security when using a reverse proxy, however, many software packages can be insecure if deployed improperly. There has to be a certain level of responsibility on the user to do his/her homework and Deploy there solution in a secure fashion.

I have tested this item ✅ successfully on af3aad6

The test was successful with no errors.

I have tested this item ✅ successfully on af3aad6

Would this be better deployed in a plugin similar to the cloudflare plugin? That plugin could be modified very easily to cover the $_SERVER key "HTTP_X_FORWARDED_PROTO".

I have tested this item ✅ successfully on af3aad6

RTC