Error message for transparent proxy

Failed DNS resolution for transparent proxy with HTTPS

New article with version: 12.1.9 (12.2021)

notempty

This article refers to a Resellerpreview

-

Situation

UTM with active transparent HTTP proxy for HTTP and HTTPS.
SSL interception running in "Web Filter Based" mode.

Error message in the browser

ERROR_SSL_PROTOCOL_ERROR

or

ssl_error_rx_record_too_long

Log message in the UTM

Log message of Squid (menu ) in the UTM:

2021-09-15T16:50:20.003+02:00|squid|8933|1631717419.981 1 192.0.2.192 NONE/200 0 CONNECT 104.96.47.5:443 - HIER_NONE/- -
2021-09-15T16:50:20.007+02:00|squid|8933|1631717420.007 27 192.0.2.192 NONE_ABORTED/409 12387 CONNECT loadbalancing.ttt-point.de:443 - HIER_NONE/- text/html
2021-09-15T16:50:20.007+02:00|squid|8933|1631717420.007 27 192.0.2.192 NONE_ABORTED/409 12387 CONNECT loadbalancing.ttt-point.de:443 - HIER_NONE/- text/html
2021-09-15T16:50:22.652+02:00|squid|8933|SECURITY ALERT: Host header forgery detected on local=192.0.2.22:443 remote=192.168.175.10:28144 FD 9 flags=33 (local IP does not match any domain IP)
2021-09-15T16:50:22.654+02:00|squid|8933|SECURITY ALERT: on URL: loadbalancing.ttt-point.de:443

Meaning

The client starts a TCP connection to an HTTPS server
The connection is intercepted by the UTM → Transparent Proxy
The HTTP proxy (Squid) checks the connection and analyzes the TLS handshake
The information obtained, such as the SNI, is thereby resolved and compared with the original IP address
In this case, the original IP and the resolved IP for the SNI (hostname) do not match and are therefore blocked by the HTTP proxy, resulting in the above mentioned error message

Cause

This behavior can be observed for hostnames with intensive load balancing.
If the provider gives different responses to DNS queries in a short period of time, the results in DNS resolution may differ between the client and the UTM.

This behavior can be caused by:

different DNS servers on client and UTM.
Hostnames that are resolved differently by UTM and client with a very small TTL due to intensive load balancing.
Use of DNS servers at different geographical locations.
In this case, a different IP address can be returned via the remote location for the called host names than at the local location of the UTM. (Geographic DNS Routing)

Solution

On the client, the UTM is entered as the global proxy server and, if necessary, as the proxy server for each application.

Workaround: The same DNS servers are entered on the client and UTM.

This procedure minimizes the error rate, but cannot reliably prevent the problem, especially with servers that use load balancing with very short TTLs. In addition, it must be ensured that no DNS servers are used that are themselves already addressed via Geographic DNS Routing.
The Google servers, for example, differ despite identical IP address depending on the region from which they are called!

Einfach, aber unsicher:
Unter Applications HTTP Proxy Area SSL-Interception die Option SNI validieren: Nein deaktivieren.
Ohne SNI Validierung können Clients die SNI beliebig manipulieren, um den Webfilter zu passieren. Diese Einstellung sollte nur als eine letzte Möglichkeit betrachtet werden, wenn es unmöglich scheint, die DNS-Einstellungen zwischen Clients des HTTP-Proxy und der UTM zu vereinheitlichen.