Support

I believe you could add

SetEnvIf X-Forwarded-Proto "https" HTTPS=on

in the "Custom .htaccess rules at the top of the file". Otherwise you have to edit your .htaccess file every time you regenerate it.

Well, that's what I thought would happen, as I explained in the closing paragraph of my previous post. We cannot let you add stuff to the .htaccess file before the HSTS block since that would allow bypass of HTTPS in some cases which can be used for a successful cookie-stealing attack. That was a real issue that we fixed a few months ago. This is why the rules at the top of the file are added just below the rules which enforce HTTPS for all requests. We cannot reverse that decision, it creates an unsafe situation. Between making a change that addresses one broken hosts but puts hundreds of thousands of other sites at risk and keeping a change that requires you to manually edit your file but keeps hundreds of thousands of other sites safe I will choose the latter any day of the week, hands down, without any regret whatsoever.

The problem seems to be your host. They are not sending X-Forwarded-Proto at all for HTTP requests. This is wrong. Your host needs to fix it. I don't know what kind of SSL terminator they use in front of Varnish (I'd guess NginX) so I can't tell you what to tell them. If it's NginX they have two configuration blocks, one for HTTPS and one for HTTP. They need to edit the "location /" block in both places and add proxy_set_header X-Forwarded-Proto https; to the HTTPS one and proxy_set_header X-Forwarded-Proto http; to the plain HTTP one. This fixes the issue.

Meanwhile, you will have to edit the file by hand every time you generate it.

You may wonder why not change

RewriteCond %{HTTP:X-Forwarded-Proto} =http

with

RewriteCond %{HTTP:X-Forwarded-Proto} !https

It's because the latter allows spoofing of the HTTP header on hosts which do not use a cache or proxy in front of them, putting them at risk.

All right! If they give you more details about their stack (SSL terminator, any Varnish configuration we should know about and which X-Forwarded-Proto header is added when) I can see if I can do something more :)

I think something got lost in the translation.

If you are behind a proxy which sets the X-Forwarded-Proto HTTP header either rule set works fine.

However! Admin Tools is not written for your site or your host only. It's not even written only for sites which are behind a proxy. The overwhelming majority (think 95%+) of sites using Admin Tools DO NOT use a proxy AT ALL.

The way I've written my rule the site will have to be served by HTTPS. It cannot be manipulated and the site remains sage.

The rule set your host wrote allows attackers to send the HTTP header X-Forwarded-Proto set to "http" in the request. This makes Apache think that everything runs under HTTPS when it's not. As a result Joomla! thinks it's running under HTTPS and will happily serve HTTPS-only cookies to an unsecured connection. Therefore an attacker can use this for a connection downgrade attack and impersonate you as long as they can trick you to click a malicious link.

Again, this attack won't work on your particular host or any host behind a reverse proxy because the X-Forwarded-Proto header is guaranteed to be coming from a trusted source and, besides, there's an SSL terminator in front of the proxy which is in front of the web server, making a downgrade attack a moot point. It would work on the overwhelming majority of our clients, though. My job is to protect the many, not please the special one-off case to the detriment of the many. So, you have no choice but to be editing your .htaccess every time since your host doesn't understand why what they are doing is suboptimal and don't want to fix it.