Netzzensur per SSL-Tunnel aushebeln

Seite 5: Unverzichtbarer Funktionstest

Inhaltsverzeichnis

Wer einen solchen Proxy einrichtet, sollte die Konfiguration einem vollständigen Funktionstest unterziehen. Die Tabelle führt alle notwendigen Tests sowie die zu erwartenden Ergebnisse auf. Außerdem empfiehlt sich vor dem Starten des Proxy-Dienstes ein Blick in die ausgehenden Netzwerkpakete auf dem SSL-Proxy, um zu prüfen, ob Apache den "geheimen“ Header richtig entfernt. Auf Linux-Systemen kann man leicht mit tcpdump sehen, welche Header bei Seitenaufrufen vom ausgehenden Netzwerk-Device auf Port 80 des Webservers gesendet werden.

Testfälle für den Tunnel
Nutzungsart Header gesetzt nicht gesetzt
Proxy auf Port 443 Webseite (200) Fehler (403)
http://www… - Webseite (200)
Proxy auf Port 80 Fehler (403) Fehler (403)
https://www… - Webseite (200)

Wer Solaris einsetzt, greift alternativ zu snoop. Der in Listing 4 gezeigte geheime X- Proxy-Header darf in der Praxis auf keinen Fall nach außen gelangen. Besonders elegant ist die Verwendung von FoxyProxy, eines Plug-in für Firefox. Es erlaubt, für unterschiedliche Zieladressen eigene Proxies zu verwenden. So ist es denkbar, für inländische Webseiten eine direkte Verbindung zu definieren und für .com- oder .fr-Adressen jeweils unterschiedliche geheime Proxies zu nutzen.

Ohne weitere Maßnahmen wäre es möglich, den Proxy auch über den Port 80 anzusteuern. Dabei ginge jedoch der geheime Header im Klartext über das Netz. Die Verwendung des Proxy über einen unverschlüsselten Port lässt sich mit Konfigurationen im Apache allein nicht abschalten. Möglicherweise ist dieser Umstand akzeptabel, wenn die Anwender darüber Bescheid wissen, den Proxy-Server auf keinen Fall unter Umgehung des SSL-Tunnels zu verwenden. Besser ist es jedoch, den Proxy-Server als eigene Instanz zu installieren und damit ausschließlich SSL-verschlüsselte Verbindungen über den Port 443 anzunehmen. Eine zweite Apache-Instanz kann dann ohne aktiviertes Proxy-Modul seine Seiten über Port 80 ausliefern. Die Konfigurationsdateien des unverschlüsselten Webservers könnten weiterhin unter /etc/apache2/ liegen, während die Konfiguration des (verschlüsselnden) Proxy-Servers unter /etc/ apache2-ssl/ liegt. Soll der Listener des Proxy tatsächlich nur für den HTTPS- Port starten, ist die Datei ports.conf anzupassen:

<IfModule mod_ssl.c>
# SSL name based virtual hosts are not
# yet supported, therefore no
# NameVirtualHost statement here
Listen 443
</IfModule>

Wer Man-in-the-Middle-Angriffe befürchtet, sollte das SSL-Zertifikat prüfen lassen. Zum Automatisieren lässt sich stunnel so konfigurieren, dass es beim Verbindungsaufbau ein lokal hinterlegtes Zertifikat geprüft. Die Datei mit dem Zertifikat legt man serverseitig in /etc/apache2/sites-available/ default-ssl (oder /etc/apache2-ssl/sites- available/default-ssl) in der Variablen SSLCertificateFile fest. Alternativ lässt sich das Zertifikat mit dem Browser herunterladen. Beim Firefox unter Tools/Page Info/Security/View Certificate/Details/Export, beim Internet Explorer unter Datei/Eigenschaften/Zertifikate herunterladen. Anschließend passt man die Konfiguration von stunnel wie folgt an. Alternativ lässt sich der Fingerprint des Zertifikats vor jeder Nutzung mit einem vorher notierten Wert überprüfen:

; Authentication stuff
verify = 2
CAfile = /etc/stunnel/ssl-cert-proxy_example_org.pem

Die Verschlüsselung der Proxy-Zugriffe mittels stunnel funktioniert nur für HTTP, nicht jedoch für HTTPS. Spätestens am „Sesam öffne Dich“-Mechanismus des gesetzten Header muss jeder Versuch scheitern, HTTPS-Seiten aufzurufen. Dieser Umstand ist von Nachteil, wenn nicht nur auf Zeitungsseiten und Webradios zugegriffen werden soll. Denn ein Login geschieht meist via HTTPS. Aus Sicht des Betreibers eines solchen SSL-Proxy ist es jedoch beruhigend zu wissen, dass er sich nicht für Bestellungen bei Onlinehändlern missbrauchen lässt.

Bei allem Reiz, sich unbemerkt im Internet zu bewegen, sind die Gefahren des Umgehens von Sperrmaßnahmen nicht zu ignorieren. Ein am Unternehmensfilter vorbei eingeschleppter Virus könnte ernsthafte Konsequenzen für das Arbeitsverhältnis haben. Schon das bloße Verwenden eines Tunnels oder eines eigenen Proxy kann gegen eine Betriebsvereinbarung verstoßen.
Da zur Nutzung des geheimen Proxy auch immer zusätzliche Software notwendig ist, verlagert sich die Entdeckungsgefahr weg von Netzwerk hin auf den lokalen Rechner. Ein Blick in die Prozessliste, die Browserkonfiguration oder die installierten Programme dürfte einen Anfangsverdacht bestätigen. Letztlich muss jeder Risiken und Gefahren der Nutzung selbst abwägen. (rek)