Bug #81837
closed
SSL mixed content issues in backend when HTTPS server var is not set
100%
Description
Using SSL in the backend of Typo3 8.7.x is causing mixed content errors in javascript when the $_SERVER['HTTPS'] variable is not available. As a result, the Install tool is not accessible anymore and you can't use the close button when editting a record. Somehow the form action reverts to http:// even while everything else is in https. However, if you open the right panel (list) in a new browser window, everything is fine and it does work.
The cause of the problem is that $_SERVER['HTTPS'] is hardcoded in the TYPO3_SSL and if this check fails (in our case because we don't have the HTTPS server variable but we are using a custom variable X-ClientHTTPS) some scripts revert to http (like FormEngine.js which somewhere seems to change your https URL to http) .
See line 3016 in GeneralUtility):
case 'TYPO3_SSL':
$proxySSL = trim($GLOBALS['TYPO3_CONF_VARS']['SYS']['reverseProxySSL']);
if ($proxySSL === '*') {
$proxySSL = $GLOBALS['TYPO3_CONF_VARS']['SYS']['reverseProxyIP'];
}
if (self::cmpIP($_SERVER['REMOTE_ADDR'], $proxySSL)) {
$retVal = true;
} else {
$retVal = $_SERVER['SSL_SESSION_ID'] || strtolower($_SERVER['HTTPS']) === 'on' || (string)$_SERVER['HTTPS'] === '1';
}
break;
Setting "lockSSL" to true causes an endless loop as our server is already configured for https, but because the TYPO3_SSL returns false (see above) it assumes you are still in http and thus it redirects.
We fixed it by setting the variable based on our own variable using .htaccess, but better solution would be to make the server variable configurable, so it is possible to use your own variable in the TYPO3_SSL check.
Our fix:
RewriteCond "%{HTTP:X-ClientHTTPS}" 1
RewriteRule .* - [E=HTTPS:on]
Updated by Benni Mack almost 7 years ago
- Status changed from New to Needs Feedback
Are you using a proxy actually? Or are you using apache itself but not using "HTTPS=on"?
Updated by Ronald Kools almost 7 years ago
Benni Mack wrote:
Are you using a proxy actually? Or are you using apache itself but not using "HTTPS=on"?
The latter: in our case Apache is not returning "HTTPS=on". So by checking the alternative variable that we do have, we now set the HTTPS=on using the .htaccess (see solution above).
However I heard from Andreas Fernandez in the Slack Typo3 channel (typo3-cms-backend-js) that Nginx doesn't set this variable by default either, so that might give similar problems.
Updated by Sybille Peters over 6 years ago
- Related to Bug #32341: $_SERVER['HTTPS'] vs. $_SERVER['HTTP_HTTPS'] nginx added
Updated by Sybille Peters over 6 years ago
- Related to Bug #29693: Respect HTTP_X_FORWARDED_PROTO in SSL check added
Updated by Sybille Peters over 6 years ago
I added some related issues to this one because there have already been discussions before. (Not exactly the same scenario but similar).
It is not clear to me: Why is the server variable HTTPS not set on your Apache httpd configuration? What speaks against setting it on the server side (as you are already doing)?
IMHO I would configure this on the server-side to the de facto HTTPS server variable. I would not add hooks and configuration variables unless really necessary but instead try to adhere to the standards or de facto standards.
As far as I know other CMSs also rely on the HTTPS variable and most info I found online goes in that direction. Newer Nginx versions apparently set it by default. If not, you can add it to the configuration very easily.
Updated by Sybille Peters over 6 years ago
In any case, I think to comply with the PHP documentation the check could be changed to check if $_SERVER['HTTPS'] exists and is non empty (instead of checking if equals "on" or '1'). Except for the mentioned exception for IIS.
For example:
if ( ... || (!empty($_SERVER['HTTPS'] && strtolower($_SERVER['HTTPS']) !== 'off'))
see docs:
"_'HTTPS'
Set to a non-empty value if the script was queried through the HTTPS protocol._Note: Note that when using ISAPI with IIS, the value will be off if the request was not made through the HTTPS protocol."
Updated by Ronald Kools over 6 years ago
Yes, that check would be perfect.
The reason we don't have the $_SERVER['HTTPS'] variable has to do with our loadbalancer rules in combination with a Varnish caching layer. These rules apply certain redirects based on this special X-ClientHTTPS variable because we have a couple of sites on the same IP.
Changing the check to your suggestion would be perfect. ;-)
Updated by Frank Nägler over 6 years ago
- Category changed from Backend JavaScript to System/Bootstrap/Configuration
Updated by Gerrit Code Review about 6 years ago
- Status changed from Needs Feedback to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/55750
Updated by Gerrit Code Review about 6 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/55750
Updated by Gerrit Code Review about 6 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/55750
Updated by Gerrit Code Review about 6 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/55750
Updated by Gerrit Code Review about 6 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/55750
Updated by Gerrit Code Review about 6 years ago
Patch set 1 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/55764
Updated by Alexander Opitz about 6 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 2b6a19eaee185ddc4a1745a113d7e025934cdf0b.
Updated by Urs Braem about 6 years ago
We had a similar error that matched the behaviour exactly: "As a result, the Install tool is not accessible anymore and you can't use the close button when editting a record."
For the record, we could solve it without the patch using the following params
Disable Apache mod_remoteip
$GLOBALS['TYPO3_CONF_VARS']['SYS']['reverseProxyIP'] = '127.0.0.1';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['reverseProxyHeaderMultiValue'] = 'last';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['reverseProxySSL'] = '*';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] = 'www.mysite.com';
Caveat: this setting will move the client IP to HTTP_X_FORWARDED_FOR instead of REMOTE_ADDR in the request.