Verständnisfrage: Funktionsweise neuer HTTPS/SSL-Filter in FRITZ!OS 6.80

[DeusoftheWired]

Moin,

seit zwei Wochen gibt es ja die 6.80 von FRITZ!OS. Ein Punkt, der mir beim Lesen des Changelogs ins Auge gefallen ist, ist dieser:

Verbesserung – Filter für Internetseiten berücksichtigt gesperrte Domains jetzt auch bei https-Aufrufen

Nach meinem Wissen ist es so, daß Paketfilter auf URL-Basis nur für HTTP funktionieren, weil man für HTTPS in den Header schauen müßte und das dort durch die Verschlüsselung nicht funktioniert.

Wie also wird das ganze ohne DPI/MitM in FRITZ!OS umgesetzt? In diesem Thread bei administrator.de schätzt man, daß es über die DNS-Abfrage erledigt wird, was wohl aber nur funktioniert, wenn man die FRITZ!Box bzw. die angeschlossenen Geräte den DNS des Providers nutzen läßt und keinen alternativen DNS festlegt. Das hieße dann, daß die FRITZ!Box wirklich nur tief in die Pakete auf Port 53 schaut, die ja standardmäßig nicht verschlüsselt sind.

 

[wirelessy]

Die Domain sieht du - brauchst du ja um zum Ziel hinzukommen. Nur den Inhalt nicht, bzw den subrequest nach /home/seite.htm nicht.

Entsprechend verstehe ich eher nicht, wieso sie es früher nicht konnte .

 

[Asghan]

Ich würde ja sagen: Probiers einfach aus

 

[DeusoftheWired]

Die Domain sieht du - brauchst du ja um zum Ziel hinzukommen.

Na ja, teilweise. Soweit ich es verstehe, findet die Abfrage, zu welcher IP die Domain x gehört, vorher statt. Ich weiß zwar den schematischen Ablauf – also daß erst ein Hallo vom Client kommt, dann ein Hallo vom Server, sich beide auf eine Ciphersuite einigen und danach die eigentlichen Nutzdaten austauschen –, aber den genauen Aufbau des Pakets nicht. Deswegen die Frage.

Ich würde ja sagen: Probiers einfach aus

Wird heute abend getestet, aber das ist nur nettes Nebenbei. Ich würde gern verstehen, wieso und wie es funktioniert, wenn es das dem Prinzip nach doch gar nicht kann (außer über die DNS-Abfrage zu mogeln).

 

[IronEagle]

Die Domain sieht man NICHT im Klartext. Man sieht die Ziel-IP und Port, aber das wars dann auch. Deswegen brauchte man ja auch früher zwingend eine IP pro HTTPS-Server, und konnte nicht wie bei Plain-Text HTTP mehrere vHosts auf einer IP laufen lassen.

Mittlerweile gibts dafür den Mechanismus SNI: https://de.wikipedia.org/wiki/Server_Name_Indication

Dort wird der Domain-Name dann unverschlüsselt übertragen, vielleicht greift AVM das ab. Das würde dann allerdings bedeuten, dass die Filterung nur für eine Teilmenge der HTTPS Server funktioniert.

 

[wirelessy]

IronEagle, SNI ist Sache des Clients, nicht des Servers.
Es wird im Client Hello mit angegeben - entweder der Server interessiert sich dafür, oder halt nicht.
Zumindest in der heutigen Praxis.

Siehe Anhang.

//e: Das macht übrigens fast jeder TLS 1.1 fähige Client so. Du hast aber natürlich recht, es ist kein Muss. Man kann den Filter garantiert dazu bringen, nicht zu greifen. Allerdings funktioniert ohne SNI ebenfalls nur eine Teilmenge der Server.

//e2: Die letzte Möglichkeit ist noch RDNS. Aber was macht man dann mit denen, die es nicht haben? Blocken, erlauben? Ich glaub der Filter nutzt SNI, und wenns keins gibt filtert er halt nicht.

 

[IronEagle]

Ob das Sache des Clients ist oder des Servers ist in dem Falle egal, da der unverschluesselte Name so oder so an der FritzBox vorbei kommt.

 

[DeusoftheWired]

//e: Das macht übrigens fast jeder TLS 1.1 fähige Client so. Du hast aber natürlich recht, es ist kein Muss. Man kann den Filter garantiert dazu bringen, nicht zu greifen. Allerdings funktioniert ohne SNI ebenfalls nur eine Teilmenge der Server.

Um zu prüfen, ob das ganze so abläuft, muß man also die HTTPS-Version einer Seite in den Filter setzen und einmal mit einem SNI-fähigen Browser aufrufen und einmal mit einem SNI-unfähigen. Richtig?

 

[wirelessy]

Jau.