Bug #86264

Trusted hosts pattern mismatch with Nginx and HTTP_X_FORWARDED_PORT 443

Added by Peter Kraume 9 months ago. Updated 6 months 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 New 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 9 months ago

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

#2 Updated by Jigal van Hemert 9 months 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 9 months 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 9 months ago

  • Category set to Backend API

#5 Updated by Susanne Moog 9 months ago

  • Assignee deleted (Oliver Hader)

#6 Updated by Susanne Moog 9 months ago

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

#7 Updated by Susanne Moog 9 months ago

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

#8 Updated by Susanne Moog 9 months 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 9 months ago

  • Target version changed from 9 LTS to Candidate for patchlevel

#10 Updated by Oliver Hader 6 months ago

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

Also available in: Atom PDF