Wechseln zu:Navigation, Suche
Wiki

























Fehlgeschlagene DNS-Auflösung bei transparentem Proxy mit HTTPS

Nur mit UTM v12.2 (09.2021)


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


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

  • 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!