Sperren von Webseiten technisch untersucht
Inhaltsverzeichnis
1. Vorwort Inhalt
Diese Tage kursieren in Foren und Artikelkommentaren viele Meinungen und Pseudoweisheiten, die es aus der Welt zu schaffen gilt. Es scheint die Allgemeinheit der „Experten“ darin übereinzustimmen, dass DNS- oder IP-Sperren leicht zu umgehen sind.
Rein technisch gesehen ist das leider nicht der Fall. Eine DNS- oder IP-Sperre ist sogar exorbitant wirksam, wenn es um’s Zensieren von Inhalten geht. Im Folgenden möchte ich einige relevante Schwachstellen herausarbeiten.
Voraussetzung der meisten Schwachstellen ist allerdings, dass alle rechtlichen Hürden zum Überwachen des Inhaltes ausgeräumt sind, der Provider also Zugriff auf die Inhalte der Kommunikation erlangt und diese ändern darf. Das ist natürlich gottlob im Moment zumindest noch in weiter Ferne.
2. Technik eines Seitenaufrufes Inhalt
Was passiert eigentlich, wenn Sie eine Webseite (z.B. „http://www.haumichblau.de/„) aufrufen? Wie findet Ihr Browser die Information, die er zum Darstellen benötigt, und wie gelangt sie zu Ihnen? Wo liegen mögliche Schwachstellen im System?
2.1 Domain-Name-System Inhalt
Zunächst sucht sich Ihr Browser über den DNS-Client des Betriebssystems („Resolver“) die IP-Adresse oder „Telefonnummer“ des Servers oder -bei größeren Seiten- der Server, auf welchem der gewünschte Inhalt liegt. Funktioniert wie beim Telefonbuch: Name rein, Nummer raus.
Genau wie beim Telefonbuch, von dem es ja auch nicht nur eines auf dem Planeten gibt, hat auch jeder Provider mehrere DNS-Server, also eigene Telefonbücher. Über selbige besitzt er außerdem vollen Zugriff und kann die Name-zu-Telefonnummer-Zuordnung beliebig verändern.
Und dreisterweise schickt Ihnen Ihr Provider im Allgemeinen, sobald Sie oder Ihr Router sich bei ihm eingewählt haben, eines oder zweie seiner Telefonbücher zu. Sie bekommen also automatisch die „Adressen-Sicht“ Ihres Providers ins Haus geliefert.
Schwachpunkt 1: Ihr Provider kann die „Telefonnummern“, die zu einem Namen gehören, beliebig ändern, und Sie bekommen davon nichts mit.
Lösung 1: Verwenden Sie nicht die „Telefonbücher“ oder „DNS-Server“ Ihres Providers. Wie Sie in Ihrem Betriebssystem andere DNS-Server bekannt machen, verraten Ihnen diverse Artikel auf den Seiten des ccc:
Schwachpunkt 2: Jetzt wird es trickreich. Ihr Provider kann nämlich -sofern die rechtlichen Hürden ausgeräumt sind- Ihre „Telefonbuchanfragen“ auch an völlig andere DNS-Server 1) erkennen, 2) blockieren und 3) an seine eigenen Server umleiten. Die Antwort, die Ihr Betriebssystem erhält, ist von der Antwort des „richtigen“, also fremden DNS-Servers nicht zu unterscheiden. Es spielt dabei keine Rolle, ob Sie die Lösung 1 implementiert haben oder nicht. Die Anfragen können technisch verändert werden, DNS wird nicht verschlüsselt.
Lösung 2: Hier hilft es nur noch, entweder die IP-Adresse des zu befragenden Servers direkt einzugeben (statt http://www.haumichblau.de/ geben Sie selbst http://217.145.103.12/ in Ihren Webbrowser ein) oder aber einen Anonymity-Dienst wie tor zu benutzen.
2.2 Verbindungsaufbau Inhalt
Wenn nun die Telefonnummer (IP-Adresse) des anbietenden Servers bekannt ist, baut Ihr Webbrowser eine sogenannte TCP/IP-Verbindung auf. Um beim Telefonvergleich zu bleiben: die Nummer wird gewählt, es klingelt (sehr) kurz, und sofern der Angerufene („Zielserver“) keine technischen Probleme hat, wird er den „Hörer“ abnehmen und darauf warten, was Ihr Webbrowser zu sagen hat.
Schwachpunkt 3: Kommt es wirklich hart auf hart, und möchte der Provider wirklich einen bestimmten Inhalt blockieren, so kann er hier an dieser Verbindung ansetzen. Es tun sich zwei Löcher auf:
- Hier ist’s wie beim menschlichen Gedächtnis: Der Provider kann den Verbindungsaufbau komplett blockieren; Sie sehen den Fehler „Der Server antwortete nicht“, auch wenn der Server selbst gar kein Problem hätte. Ob der Server oder der Provider schuld hat, bekommen Sie nicht mit.
- Der Provider kann den Verbindungsaufbau auf einen beliebigen anderen oder eigenen Server umleiten. Wenn Ihr ursprünglicher Zielserver kein Zertifikat vorweisen kann, die Verbindung also nicht verschlüsselt wird, bekommen Sie auch das nicht mit.
Lösung 3: Hier hilft nur noch ein Anonymisierungsdienst oder -Netzwerk. Ist eine IP-Adresse providerseitig gesperrt, ist mir sonst kein Weg bekannt, die Sperre zu umgehen. Ich habe Tunnellösungen mit Absicht nicht einbezogen; das zählt für mich als Anonymisierungsdienst.
2.3 Adressierung des Inhaltes – Theorie Inhalt
Hierfür müssen wir etwas Theorie verstehen. Es ist seit Jahren so, dass die Telefonnummern („IP-Adressen“) im Internet immer knapper werden. Das hat schlicht mit der Anzahl der Teilnehmer und der maximal möglichen Adressen zu tun und läßt sich anschaulich demonstrieren. Eine Internet-Telefonnummer hat genau 4 Stellen zu je 255 unterschiedlichen Werten. Also reichen sie von 0.0.0.0 bis 255.255.255.255, wobei es darin Sonderbereiche gibt, die nicht für das Internet zur Verfügung stehen. Maximal gibt es somit:
Zwar eine sehr große Zahl, aber für alle WWW-Adressen des Planeten reicht die lange nicht aus. Noch dazu, wo sehr viele der IP-Adressen nicht für WWW-Server, sondern für beliebige andere Rechner verwendet werden müssen.
Kurz: IP-Adressen müssen gespart werden bei Internetservern. Man hat dazu das Konzept der „virtuellen Hosts“, auch VHOSTS genannt, erfunden. Ein physikalischer Rechner (eine einzige IP-Adresse) bedient eine prinzipiell beliebig große Zahl von WWW-Adressen.
2.4 Auslieferung des Inhaltes (ohne Verschlüsselung) Inhalt
Wie funktioniert das genau? Nun, Ihr Webbrowser, der ja die Verbindung aufgebaut hatte, teilt nun dem Server über das sogenannte Hypertext-Transfer-Protocol (HTTP) im Wesentlichen zwei Informationen mit:
- Welche Ressource (Datei oder Ordner) ist gewünscht?
- Auf welchem Server liegt sie?
Sehen wir uns das näher an. Zunächst einmal zeigt Ihr Browser dem Server die benötigte Ressource an und verlangt mittels „GET“ eine Auslieferung (hier einmal der Datei „/index.html“, meist die Standardseite):
Einfacher HTTP-Request Header
GET /index.html HTTP/1.1
Host: www.haumichblau.de
Wichtig ist nun der zweite Eintrag, „Host:“. Hiermit teilt der Browser dem Server mit, von welcher WWW-Seite er die Informationen abrufen möchte. Fassen wir zusammen:
- DNS dient dazu, den Server physikalisch ausfindig zu machen
- Nach dem Kommunikationsaufbau dient HTTP dazu,
a) den virtuellen Host (wenn Sie so wollen, den „Ordner“) auf dem physikalischen Server mittels des „Host:“ Eintrags festzulegen und
b) die gewünschte Datei („/index.html“) zu spezifizieren.
Schwachpunkt 4: Ohne Schwierigkeiten können Sie erkennen, dass ein Provider sämtliche Felder dieses HTTP-Requests beliebig ändern kann. Er sitzt ja zwischen Ihrem Browser und dem Zielserver und könnte z.B. die erste Zeile in „GET /index2.html HTTP/1.1“ abändern. Ohne es zu wissen, würden Sie den Zielserver nach einer falschen Seite fragen.
Schwachpunkt 5: Weiterhin sendet der Zielserver im Allgemeinen auch Daten (Webseiten, Bilder, usw.) zurück. Die Kommunikation findet offen statt. Ihr Provider kann nun auch den Inhalt der Antwort bearbeiten, und Ihnen statt dem Text über Demokratie von Wikipedia Wolfgang Schäubles Lebenslauf unterschieben. Das würden Sie zwar -hoffentlich- bemerken, was aber, wenn die Veränderung viel subtiler ausgeprägt ist? Vielleicht ein „nicht“ eingefügt, das die Aussagen ins Gegenteil verkehrt?
Anders ausgedrückt: Sie haben keine Möglichkeit festzustellen, ob der Inhalt auch unverändert zu Ihnen kam.
Lösung 4 & 5: Hier hilft nur noch ein Anonymisierungsdienst oder -Netzwerk. Läuft der Verkehr über den Provider unverschlüsselt, ist es wie bei Toyota: Nichts ist unmöglich!
Schwachpunkt 6: Wenn der Provider doch jetzt diese eine IP-Adresse sperrt, sind denn dann nicht unter Umständen eine Reihe von unschuldigen WWW-Seiten betroffen? Gerade wurde doch gesagt, pro IP-Adresse gäbe es eventuell viele WWW-Seiten.
Lösung 6: Leider ist auch das kein Problem. Der Provider hat ja über die zweite Zeile erfahren, dass Sie mit www.haumichblau.de Kontakt aufnehmen wollen. Steht die nun auf dem Index, muss Ihr Provider nur Ihren gesamten Internetverkehr filtern und „trennt“ praktisch in der Mitte die Verbindung, wenn er das Wort „www.haumichblau.de“ irgendwo in einer zweiten Zeile Ihrer Kommunikation „hört“. Davon wären alle übrigen Dienste und WWW-Seiten auf diesem Server nicht betroffen.
2.5 Und mit Verschlüsselung (https)? Inhalt
Bei HTTPS greifen einige Sicherheitsmechanismen und stellen folgendes sicher:
- Eine „planetare“ Instanz (Verisign, Thawte, oder ähnlich) bestätigt durch ein Zertifikat, welches nicht kopiert werden kann, dass der Server auch der ist, für den er sich ausgibt.
- Die Kommunikation (also auch der oben erwähnte Request sowie alle Inhalte) ist in beide Richtungen verschlüsselt und auch für Großrechner nicht unter Äonenfrist zu entschlüsseln.
Zwar gibt es eine Reihe von sehr guten Angriffs-Szenarien gegen https, diese sind aber eber für Experten interessant. Wichtig ist zu wissen, dass dem Provider bei HTTPS im Allgemeinen nur die vollständige Sperrung der IP-Adresse des Zielservers bleibt.
So bekommen Sie zumindest mit, dass der Inhalt „nicht erreichbar“ ist und müssen nicht befürchten, dass er beschnitten oder verändert wurde.
Schwachpunkt 7: Wenn doch jetzt der Provider nur noch diese eine IP-Adresse sperren kann, sind jetzt nicht ganz sicher eine Reihe von unschuldigen WWW-Seiten betroffen? Gerade wurde doch gesagt, pro IP-Adresse gäbe es eventuell viele WWW-Seiten und durch die Verschlüsselung sieht der Provider doch den GET und den HOST: Eintrag nicht mehr.
Lösung 7: Hm, guter Punkt. Leider kein Gewinn. Die Zertifikate von Webseiten werden nur für die Webseiten oder auch Domänen an sich ausgestellt, nicht für den physikalischen Server.
Das müssen Sie sich so vorstellen: Ein Server bediene 20 VHOSTS. Jetzt erhält er eine verschlüsselte Anfrage (funktioniert in Wirklichkeit anders, ist so aber leichter vorzustellen). Welches Zertifikat soll er nehmen? Er kann ja nicht einfach alle durchprobieren.
Deswegen ist es bei verschlüsselten WWW-Seiten so, dass sie ihre eigene separate IP-Adresse bekommen. So wird genau einer IP-Adresse (und einer WWW-Adresse) genau ein Zertifikat zugeordnet und die Verschlüsselung funktioniert einwandfrei.
Leider bedeutet das auch eine sehr wirksame Sperrung auf IP-Ebene. Die betrifft nämlich nur die gewünschte WWW-Seite.
3. Fazit Inhalt
Wer wirklich sicher sein will, alle Inhalte unzensiert und originalgetreu erhalten zu können, der muss zwingend einen Anonymisierungsdienst oder -Netzwerk wie TOR in Anspruch nehmen. Das momentane Verzeichnis- und Kommunikationssystem hat gegen Zensur einfach zu viele Anfälligkeiten, die nur durch rechtliche Hürden (noch) nicht ausgenutzt werden. Doch wir alle wissen, was mit solchen Möglichkeiten passiert: Früher oder später werden sie ausgenutzt.
Leider ist das für den Laien nicht so einfach zu überschauen oder einzurichten.
Bislang keine Kommentare vorhanden.
Einen Kommentar hinterlassen