Bug #86264

Trusted hosts pattern mismatch with Nginx and HTTP_X_FORWARDED_PORT 443

Added by Peter Kraume over 1 year ago. Updated 13 days ago.

Status:
Accepted
Priority:
Should have
Assignee:
-
Category:
Backend API
Start date:
2018-09-15
Due date:
% Done:

0%

TYPO3 Version:
9
PHP Version:
7.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

When the frontend is called via https, there is this error message in the log:

PHP Fatal error:  Uncaught UnexpectedValueException: The current host header value does not match the configured trusted hosts pattern! Check the pattern defined in $GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] and adapt it, if you want to allow the current host header 'ddev105.ddev.local' for your installation. in /var/www/html/public/typo3/sysext/core/Classes/Utility/GeneralUtility.php:2803" 

Install Tools says:

The trusted hosts pattern will be configured to allow all header values. This is because your $SERVER_NAME:[defaultPort] is "ddev105.ddev.local:443" while your HTTP_HOST:SERVER_PORT is "ddev105.ddev.local:80". Check the pattern defined in Admin Tools -> Settings -> Configure Installation-Wide Options -> System -> trustedHostsPattern and adapt it to expected host value(s).

The problem seems to be that the DDEV configuration has no extra SSL configuration and thus there is a mismatch between SERVER_PORT and HTTP_X_FORWARDED_PORT which needs an additional check.

Test environment:
  • DDEV 1.2.0
  • TYPO3 9.4 composer based

HTTP_X_FORWARDED_PORT.png View (102 KB) Peter Kraume, 2018-09-15 16:03


Related issues

Related to TYPO3 Core - Bug #86265: No redirect to install tool on fresh installation with FIRST_INSTALL present Closed 2018-09-15
Related to TYPO3 Core - Bug #32341: $_SERVER['HTTPS'] vs. $_SERVER['HTTP_HTTPS'] nginx Closed 2011-12-06
Related to TYPO3 Core - Bug #29693: Respect HTTP_X_FORWARDED_PROTO in SSL check Rejected 2011-09-12

History

#1 Updated by Peter Kraume over 1 year ago

  • Related to Bug #86265: No redirect to install tool on fresh installation with FIRST_INSTALL present added

#2 Updated by Jigal van Hemert over 1 year ago

HTTP_X_FORWARDED_PORT is not defined in any RFC and there is some documentation of it in certain software projects.
With multiple proxies the X-Forwarded-* headers may contain lists of values, so it's only safe to assume that this will also be the case for the X_FORWARDED_PORT header.
In some cases the port is included in the X-Forwarded-Host header. How this is handled in case of a combination of X-Forwarded-Host and X-Forwarded-Port headers where one or more hosts have the port number included in the X-Forwarded-Host header is unclear to me.
The RFC-documented X-Forwarded-* headers are superseded by the Forwarded field. So, some proxies may also use a port section in the Forwarded header.

All-in-all we may end up with a combination of headers from which we have to extract the correct information. My understanding is the following list of priorities:

1. if multiple values are present in a header the first value is the original request
2. if a Forwarded header is present the use that value
3. if a port number is included in the X-Forwarded-Host header than use that value
4. if X-Forwarded-Port header is present use that value
5. use the default port for the protocol

#3 Updated by Oliver Hader over 1 year ago

  • Status changed from New to Accepted

@Jigal, sounds good to setup up a chain in order to resolve proper combinations of host & port values. Would you have time working on a potential patch/solution for this issue?

In general I can confirm that the issue exists, since I was sitting next to Peter (reporter) when this occurred in DDEV.

#4 Updated by Susanne Moog over 1 year ago

  • Category set to Backend API

#5 Updated by Susanne Moog over 1 year ago

  • Assignee deleted (Oliver Hader)

#6 Updated by Susanne Moog over 1 year ago

  • Related to Bug #32341: $_SERVER['HTTPS'] vs. $_SERVER['HTTP_HTTPS'] nginx added

#7 Updated by Susanne Moog over 1 year ago

  • Related to Bug #29693: Respect HTTP_X_FORWARDED_PROTO in SSL check added

#8 Updated by Susanne Moog over 1 year ago

The old articles (see linked issues and https://review.typo3.org/#/c/4913/) mention that this could be a security issue if implemented in the core - I'm not sure if that will also be the case here because the header might be manipulated by the client.

#9 Updated by Benni Mack over 1 year ago

  • Target version changed from 9 LTS to Candidate for patchlevel

#10 Updated by Oliver Hader about 1 year ago

For new DDEV projects AdditionalConfiguration.php is defined with wildcard host pattern since
https://github.com/drud/ddev/commit/996b8c4d62a12fd4acc7f2828ea7a8b5f654aa39

#11 Updated by Jonas Eberle 6 months ago

This is IMHO solved for normal use. A warning on installation is still present but this seems to be a separate case: https://forge.typo3.org/issues/88846

#12 Updated by Peter Kraume 13 days ago

This issue seems to be solved in the meanwhile. I've just tested it with DDEV v1.12.0 and TYPO3 9.5.13 and everything works fine now.

Also available in: Atom PDF