Die Dynamik der Internetzensur, insbesondere in Regionen wie dem Iran, bietet oft unerwartete Einblicke in die Funktionsweise von Netzwerksperren. Dieser Bericht beleuchtet eine spezifische Beobachtung bezüglich des Zugangs zu einer WordPress-Website, die mittels NGINX und VLESS + TLS konfiguriert wurde. Das Phänomen war, dass der direkte Website-Zugriff blockiert war, während der Zugang über einen Proxy (mit V2RAYN-Client) einwandfrei funktionierte. Eine tiefere Analyse enthüllte spezifische Probleme im Zusammenhang mit der Chrome-Version 107.0.5304.88 und dem TLS-Handshake-Protokoll.
Diese Situation wirft wichtige Fragen auf: Sollte der Proxy-Verkehr nicht identisch mit dem direkten Website-Zugriff sein? Wenn nicht, welche Unterschiede könnten von Zensurmechanismen zukünftig ausgenutzt werden?
Detaillierte Problembeschreibung und Beobachtungen
Die ursprüngliche Konfiguration umfasste eine WordPress-Website auf NGINX mit VLESS + TLS im Backend, basierend auf einem modifizierten Wulabing-Skript. Ein CDN wurde im “DNS only”-Modus (graue Wolke) verwendet. Die Website war zunächst zugänglich, bis Berichte über Probleme auftauchten.
- ISP-abhängige Blockierung: Zunächst war die Website nur über den ISP “Mokhaberat” nicht erreichbar, während “Irancell” funktionierte. Spätere Tests zeigten jedoch eine Ausweitung der Blockierung auch auf “Irancell”. Dies deutet auf eine dynamische oder regionale Anpassung der Zensurmaßnahmen hin.
- Geräte-Konsistenz: Die Blockierung betraf mehrere Geräte (zwei PCs mit Windows 10/11 und ein Android 8-Gerät), wobei der Proxy-Zugriff auf allen Geräten weiterhin funktionierte. Dies schloss gerätespezifische Software-Probleme weitgehend aus.
- uTLS und TLS-Fingerprints: Versuche, die uTLS-Einstellungen in V2rayN und V2rayNG anzupassen, um mögliche Probleme mit TLS-Fingerprints zu umgehen, zeigten keine Besserung. Dies deutete darauf hin, dass das Problem tiefer lag als eine einfache Fingerprint-Erkennung.
- Browser-Diskrepanz: Eine besonders interessante Beobachtung war, dass Firefox die Website öffnen konnte, während Chrome dies nicht tat. Dies führte zu einer genauen Untersuchung der Netzwerkpakete.
Technische Analyse mit WireShark: Der Fall von Chrome 107.0.5304.88
Um die Diskrepanz zwischen Firefox und Chrome zu verstehen, wurde WireShark auf dem System des Clients installiert. Die Analyse der TLS-Handshakes lieferte aufschlussreiche Ergebnisse.
TLS-Handshake-Fehler in Chrome 107.0.5304.88 bei Internetzensur in Iran
Das obige Bild zeigt den TLS-Handshake von Chrome 107.0.5304.88 (Offizieller Build) (64-Bit). Nach der TCP-Bestätigung wurde ein Client Hello gesendet, jedoch wurde kein Server Hello-Paket empfangen. Dies bedeutet, dass der TLS-Handshake fehlschlug. Im Gegensatz dazu zeigten die V2rayN-Pakete, die ähnliche TLS-Fingerprints aufwiesen, aber TLSv3 nutzten, einen erfolgreichen Handshake.
Ein Blick auf die Firefox 106.0.5 (64bit) Pakete bestätigte ebenfalls einen erfolgreichen Handshake:
Erfolgreicher TLS-Handshake in Firefox 106.0.5 im Vergleich zu Chrome 107.0.5304.88
Auch hier funktionierte der Zugriff einwandfrei, und die TLS-Version war ebenfalls entscheidend. Interessanterweise wurde Chrome Version 108.0.5359.29 (Offizieller Build) Beta (64-Bit) installiert und funktionierte ebenfalls. In dessen Client Hello-Paket war deutlich zu sehen, dass TLSv3 verwendet wurde, mit dem gleichen erfolgreichen Ergebnis wie bei Firefox.
Mögliche Schlussfolgerungen und Hypothesen
Basierend auf diesen Beobachtungen lassen sich mehrere Hypothesen ableiten, die jedoch mit Vorsicht zu genießen sind:
- Inkompetenz der ISPs: Es ist denkbar, dass die iranischen Internetanbieter (ISPs) über unzureichendes Wissen im Bereich des TLS-Protokolls verfügen. Indem sie bestimmte TLS-Versionen oder -Implementierungen blockieren, könnten sie unbeabsichtigt legitime Websites für viele Nutzer sperren. Dies deutet auf einen Mangel an Präzision in ihren Zensurwerkzeugen hin.
- Anti-Google-Politik: Angesichts der Tatsache, dass andere Google-Dienste wie Google Translate und Google Play im Iran bereits blockiert sind, könnte dies Teil einer breiteren Strategie sein, die Nutzung von Google Chrome zu unterbinden. Der Client berichtete zudem, dass Chrome ohne VPN weder herunterladbar noch aktualisierbar ist, was diese Annahme stützt. Es stellt sich jedoch die Frage, warum gezielt eine bestimmte TLS-Version und nicht der TLS-Fingerprint (wie JA3) anvisiert wird, was technisch nicht langsamer wäre. Die Tatsache, dass die Beta-Version von Chrome, die TLSv3 verwendet, funktioniert, verstärkt diese Hypothese.
- Erzwingung spezifischer Chiffren: Eine weitere, wenn auch spekulativere Möglichkeit ist, dass diese Blockaden dazu dienen könnten, Anwendungen zur Verwendung spezifischer Chiffrierverfahren zu zwingen. Solche Chiffren könnten leichter zu erkennen sein, wenn sie für Proxy-Zwecke missbraucht werden. Obwohl dies ein komplexes Szenario darstellt, ist es theoretisch eine Option in der Weiterentwicklung von Zensurtechnologien.
Fazit
Die selektive Blockierung von Internetzugriffen, insbesondere die beobachteten Probleme mit Chrome 107.0.5304.88 und bestimmten TLS-Versionen, unterstreicht die Komplexität und die dynamische Natur der Internetzensur. Es zeigt, wie kleine technische Details in Browser-Implementierungen oder Protokollversionen weitreichende Auswirkungen auf die Zugänglichkeit von Online-Inhalten haben können. Diese Erkenntnisse bieten wertvolle Anhaltspunkte für Entwickler und Nutzer, die mit ähnlichen Herausforderungen konfrontiert sind, und erfordern eine kontinuierliche Anpassung an die sich entwickelnden Zensurmechanismen. Es bleibt abzuwarten, welche Rolle TLS-Versionen und Browser-Fingerprints in zukünftigen Zensurstrategien spielen werden.