Bug #29693
closedRespect HTTP_X_FORWARDED_PROTO in SSL check
Added by Michael Stucki about 13 years ago. Updated about 11 years ago.
0%
Description
If the webserver runs behind a proxy server which takes care of the SSL encryption, it may forward the HTTP_X_FORWARDED_PROTO header.
However, TYPO3 ignores the header when checking for SSL using t3lib_div::getIndpEnv('TYPO3_SSL').
The header value seems to be a de-facto-standard according to Wikipedia (similar to HTTP_X_FORWARDED_FOR):
http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
Updated by Michael Stucki about 13 years ago
- Status changed from New to Accepted
- Assignee set to Michael Stucki
Updated by Mr. Hudson about 13 years ago
Patch set 1 of change I3db6cf6faab11718083709cfe6fc9b5df71812b4 has been pushed to the review server.
It is available at http://review.typo3.org/4913
Updated by Mr. Hudson about 13 years ago
Patch set 1 of change I3db6cf6faab11718083709cfe6fc9b5df71812b4 has been pushed to the review server.
It is available at http://review.typo3.org/4916
Updated by Mr. Hudson about 13 years ago
Patch set 1 of change Id248bf4a9b83703f3a8cdc4df6c43c1c8a7ec105 has been pushed to the review server.
It is available at http://review.typo3.org/4921
Updated by Andreas Wolf about 13 years ago
- Category set to Backend API
- Status changed from Accepted to Under Review
Updated by Mr. Hudson about 13 years ago
Patch set 2 of change I3db6cf6faab11718083709cfe6fc9b5df71812b4 has been pushed to the review server.
It is available at http://review.typo3.org/4913
Updated by Michael Stucki about 13 years ago
- Status changed from Under Review to Rejected
This feature should not be used because the HTTP_X_FORWARDED_PROTO header can be forged by clients. The solution is to use "HTTPS=on" instead.
Won't fix.
Updated by Christian Kuhn over 11 years ago
This was discussed and denied again with https://review.typo3.org/#/c/21853/
Updated by Christian Kuhn over 11 years ago
The only way to support this for people who know what they are doing is a possible hook in getIndPEnv, see issue #39016 ... I would suggest such a patch now.
Updated by Christian Ludwig over 11 years ago
Adding a hook (only) seems to me more risky because there will be an extension soon, that handles HTTP_X_FORWARDED_PROTO without any extra checks. And this will make TYPO3 more insecure than offering the right solution with the core (and making such an extension dispensable).
Please see my comment at https://review.typo3.org/#/c/4913/ on how to make this patch secure!
At the moment the only dirty (and insecure) workaround seems to me in adding these lines to index.php (due to Issue #37467)
if ($_SERVER['X-Forwarded-Proto'] == 'https') { $_SERVER['HTTPS'] = 'on'; }
Updated by Helmut Hummel over 11 years ago
Christian Ludwig wrote:
Adding a hook (only) seems to me more risky because there will be an extension soon, that handles HTTP_X_FORWARDED_PROTO without any extra checks. And this will make TYPO3 more insecure than offering the right solution with the core (and making such an extension dispensable).
I totally agree!
At the moment the only dirty (and insecure) workaround seems to me in adding these lines to index.php (due to Issue #37467)
You can simply configure your web server correctly for example like this in case it's an apache with mod_env:
SetEnvIf HTTP_X_FORWARDED_PROTO "^https$" HTTPS=on SetEnvIf HTTP_X_FORWARDED_PROTO "^http$" HTTPS=off
All problems solved transparently for all applications in this virtual host configuration. Ano specific patch or software needed. The idea to do it this way is mentioned in the abandoned patch : http://www.fabrizio-branca.de/nginx-varnish-apache-magento-typo3.html
Please see my comment at https://review.typo3.org/#/c/4913/ on how to make this patch secure!
your suggestion does not make anything more secure. The reason is that it cannot be reliably secured on application level in such a scenario because the terminating proxy must set the HTTP_X_FORWARDED_PROTO header for every request making sure to overwrite all requested variants (case insensitively). If that is not the case, the application can be tricked to act like a https request has been sent.
We decided to not handle this scenario on application side (TYPO3) because:
- It can be more elegantly solved with server configuration
- It would introduce unneeded complexity (getIndpEnv already is too complex which leads to bugs you mentioned above)
- Leave all configuration for such a scenario in one "domain" which is the domain of the server admin. This makes the bahviour clearer and avoids misunderstandings between people of different domains.
But I agree that we should add this to our documentation. Feel free to add a ticket in the according tracker and contribute different configurations for different web servers running TYPO3 (e.g. Nginx)
Hope that makes the reasoning a bit clearer. Feel free to add further comments. Thank you.
Updated by Philipp Müller about 11 years ago
Hi Helmut
The "SetEnvIf"-solution does not run with fcgi and suexec ( http://bit.ly/14LtRMH ). That means we need any other solution, maybe in TYPO3. You have an idea?
Philipp
Updated by Michael Stucki about 11 years ago
- Is Regression set to No
Hi Philipp,
The "SetEnvIf"-solution does not run with fcgi and suexec ( http://bit.ly/14LtRMH ). That means we need any other solution, maybe in TYPO3. You have an idea?
Try this instead:
SetEnvIf X-Forwarded-Proto "^https$" HTTPS=on
I prefer to refer to the port instead (needs nginx adjustment):
SetEnvIf X-Forwarded-Port "443" HTTPS=on
Updated by Sybille Peters over 7 years ago
- Related to Bug #81837: SSL mixed content issues in backend when HTTPS server var is not set added
Updated by Susanne Moog about 6 years ago
- Related to Bug #86264: Trusted hosts pattern mismatch with Nginx and HTTP_X_FORWARDED_PORT 443 added
Updated by Christian Kuhn about 4 years ago
- Related to Bug #92187: HTTP/HTTPS not correctly determined behind reverseProxy added