UTM/APP/HTTP Proxy-Host-header-forgery: Unterschied zwischen den Versionen

Aktuelle Version vom 5. Juni 2024, 12:46 Uhr

{{var | Lösung--SNI

| Einfach, aber unsicher:
Unter Bereich 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.

Fehlgeschlagene DNS-Auflösung bei transparentem Proxy mit HTTPS und webfilterbasierter SSL-Interception

Neuer Artikel zur Version: 12.1.9 (12.2021)

notempty

Dieser Artikel bezieht sich auf eine Resellerpreview

-

Situation

UTM mit aktivem transparenten HTTP-Proxy für HTTP und HTTPS.
Die SSL-Interception läuft im Modus "Webfilterbasierend".

Fehlermeldung im Browser

ERROR_SSL_PROTOCOL_ERROR
ssl_error_rx_record_too_long

Logmeldung in der UTM

Logmdeldung des Squid (Menü Log ) in der 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

Bedeutung

Der Client startet eine TCP-Verbindung zu einem HTTPS-Server
Die Verbindung wird durch die UTM → Transparenter Proxy abgefangen
Der HTTP-Proxy (Squid) prüft die Verbindung und analysiert den TLS-Handshake.
Die gewonnen Informationen wie der SNI werden dabei aufgelöst und mit der ursprünglichen IP-Adresse verglichen
In diesem Fall stimmen ursprüngliche IP und die aufgelöste IP für den SNI (Hostnamen) nicht überein und werden daher durch den HTTP-Proxy blockiert und es kommt zu oben stehender Fehlermeldung

Ursache

Dieses Verhalten ist bei Hostnamen mit einer intensiven Lastenverteilung zu beobachten.
Wenn der Anbieter in kurzer Zeit unterschiedliche Antworten auf DNS-Anfragen gibt, können sich die Ergebnisse in der DNS-Auflösung zwischen Client und UTM unterscheiden.

Dieses Verhalten kann hervorgerufen werden durch:

Unterschiedliche DNS-Server auf Client und UTM
Hostnamen, die mit einer sehr kleinen TTL durch intensive Lastenverteilung, von UTM und Client unterschiedlich aufgelöst werden.
Nutzung von DNS-Servern an unterschiedlichen geografischen Standorten.
Dabei kann über den entfernten Standort für die aufgerufenen Hostnamen eine andere IP-Adresse zurückgegeben werden als am lokalen Standort der UTM. (Geographic DNS Routing)

Lösung

Best Practice:
Auf dem Client wird die UTM als globaler Proxy-Server und ggf. für jede Anwendung als Proxy-Server eingetragen.
Workaround:
Auf Client und UTM werden die gleichen DNS-Server eingetragen.

Dieses Vorgehen minimiert die Fehlerrate, kann das Problem aber vor allem bei Servern, die Loadbalancing mit sehr kurzen TTLs-betreiben nicht sicher verhindern.
Zusätzlich muss darauf geachtet werden, daß auch keine DNS-Server verwendet werden, die selber bereits über Geographic DNS Routing angesprochen werden.
Die Google-Server z.B. unterscheiden sich trotz identischer IP-Adresse je nach Region, von der aus sie aufgerufen werden!

@@ Zeile 2: / Zeile 2: @@
 {{#vardefine:headerIcon|spicon-utm}}
-{{:UTM/APP/HTTP Proxy-Transparenter Modus.lang}}
+{{var	| display
+		| Fehlermeldung bei transparentem Proxy
+		| Error message for transparent proxy }}
+{{var	| head
+		| Fehlgeschlagene DNS-Auflösung bei transparentem Proxy mit HTTPS und webfilterbasierter SSL-Interception
+		| Failed DNS resolution for transparent proxy with HTTPS }}
+{{var	| Situation--desc
+		|
+* UTM mit aktivem transparenten HTTP-Proxy für HTTP und HTTPS.
+* Die SSL-Interception läuft im Modus "Webfilterbasierend".
+		|
+* UTM with active transparent HTTP proxy for HTTP and HTTPS.
+* SSL interception running in "Web Filter Based" mode. }}
+{{var	| Fehlermeldung im Browser
+		| Fehlermeldung im Browser
+		| Error message in the browser }}
+{{var	| Logmeldung im Squid
+		| Logmeldung in der UTM
+		| Log message in the UTM }}
+{{var	| Logmeldung im Squid--desc
+		| Logmdeldung des Squid (Menü {{Menu-UTM||Log}}) in der UTM:
+		| Log message of Squid (menu {{Menu-UTM||Log}}) in the UTM: }}
+{{var	| Bedeutung
+		| Bedeutung
+		| Meaning }}
+{{var	| Bedeutung--desc
+		|
+* Der Client startet eine TCP-Verbindung zu einem HTTPS-Server
+* Die Verbindung wird durch die UTM → Transparenter Proxy abgefangen
+* Der HTTP-Proxy (Squid) prüft die Verbindung und analysiert den TLS-Handshake.
+* Die gewonnen Informationen wie der SNI werden dabei aufgelöst und mit der ursprünglichen IP-Adresse verglichen
+* In diesem Fall stimmen ursprüngliche IP und die aufgelöste IP für den SNI (Hostnamen) nicht überein und werden daher durch den HTTP-Proxy blockiert und es kommt zu oben stehender Fehlermeldung
+		|
+* 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 }}
+{{var	| Ursache
+		| Ursache
+		| Cause }}
+{{var	| Ursache--desc
+		| Dieses Verhalten ist bei Hostnamen mit einer intensiven Lastenverteilung zu beobachten. <br>Wenn der Anbieter in kurzer Zeit unterschiedliche Antworten auf DNS-Anfragen gibt, können sich die Ergebnisse in der DNS-Auflösung zwischen Client und UTM unterscheiden.<br><br> Dieses Verhalten kann hervorgerufen werden durch:
+* Unterschiedliche DNS-Server auf Client und UTM
+* Hostnamen, die mit einer sehr kleinen TTL durch intensive Lastenverteilung, von UTM und Client unterschiedlich aufgelöst werden.
+* Nutzung von DNS-Servern an unterschiedlichen geografischen Standorten.<br> Dabei kann über den entfernten Standort für die aufgerufenen Hostnamen eine andere IP-Adresse zurückgegeben werden als am lokalen Standort der UTM. (Geographic DNS Routing)
+		| This behavior can be observed for hostnames with intensive load balancing. <br>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.<br><br> 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.<br> 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) }}
+{{var	| Lösung
+		| Lösung
+		| Solution }}
+{{var	| Lösung--desc
+		|
+* '''Best Practice:'''<br> Auf dem Client wird die UTM als globaler Proxy-Server und ggf. für jede Anwendung als Proxy-Server eingetragen.
+* '''Workaround:'''<br> Auf Client und UTM werden die gleichen DNS-Server eingetragen.
+		|  }}
+{{var	| Lösung--Hinweis
+		| Dieses Vorgehen minimiert die Fehlerrate, kann das Problem aber vor allem bei Servern, die Loadbalancing mit sehr kurzen TTLs-betreiben nicht sicher verhindern.<br> Zusätzlich muss darauf geachtet werden, daß auch keine DNS-Server verwendet werden, die selber bereits über ''Geographic DNS Routing'' angesprochen werden.<br> Die Google-Server z.B. unterscheiden sich trotz identischer IP-Adresse je nach Region, von der aus sie aufgerufen werden!
+		| This procedure minimizes the error rate, but cannot reliably prevent the problem, especially with servers that use load balancing with very short TTLs.<br> In addition, it must be ensured that no DNS servers are used that are themselves already addressed via ''Geographic DNS Routing''.<br> The Google servers, for example, differ despite identical IP address depending on the region from which they are called! }}
+{{var	| Lösung--SNI
+		| '''Einfach, aber unsicher:'''<br>Unter  {{Menu-UTM|Anwendungen|HTTP-Proxy|SSL-Interception}} die Option {{b|SNI validieren:}} {{ButtonAus|Nein}} deaktivieren. {{info|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.}}
 </div><noinclude>{{TOC2}}{{Select_lang}}
-{{Header|12.1.9 <small>(12.2021)</small>|display={{#var:display--Host-header-forgery}}|head={{#var:head--Host-header-forgery}} | new=true
+{{Header|12.1.9 <small>(12.2021)</small>|new=true|
 }}</noinclude>
-==== {{#var:Situation}} ====
-<div class="Einrücken">{{#var:Situation--desc}}</div>
+==== Situation ====
+<div class="Einrücken">
+{{#var:Situation--desc}}
+</div>
 ==== {{#var:Fehlermeldung im Browser}} ====
-<div class="Einrücken">{{code|{{#var:Fehlermeldung im Browser--desc}} }}
+<div class="Einrücken">
+{{code|ERROR_SSL_PROTOCOL_ERROR}}
 {{#var:oder}}<br>
-{{code|{{#var:Fehlermeldung im Browser--Firefox--desc}} }}</div>
+{{code|ssl_error_rx_record_too_long}}
+</div>
 ==== {{#var:Logmeldung im Squid}} ====
-<div class="Einrücken">{{#var:Logmeldung im Squid--desc}}<br>
+<div class="Einrücken">
+{{#var:Logmeldung im Squid--desc}}<br>
 <div class="code" style="overflow: scroll; width: 100%; white-space: nowrap;">
 -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/- -<br>
@@ Zeile 25: / Zeile 95: @@
 -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)<br>
 -09-15T16:50:22.654+02:00|squid|8933|SECURITY ALERT: on URL: loadbalancing.ttt-point.de:443
-</div>
+</div></div>
-</div>
 ----
 ==== {{#var:Bedeutung}} ====
-<div class="Einrücken">{{#var:Bedeutung--desc}}</div>
+<div class="Einrücken">
+{{#var:Bedeutung--desc}}
+</div>
 ==== {{#var:Ursache}} ====
-<div class="Einrücken">{{#var:Ursache--desc}}</div>
+<div class="Einrücken">
+{{#var:Ursache--desc}}
+</div>
@@ Zeile 43: / Zeile 115: @@
 {{#var:Lösung--desc}}
 <li class="list--element__alert list--element__warning einrücken">{{#var:Lösung--Hinweis}}</li>
-{{#var:Lösung--SNI}}
+* {{#var:Lösung--SNI}}
 </div>