Die meisten großen sozialen Netzwerke bieten inzwischen die Möglichkeit, Inhalte im Internet auch im eigenen internen geschützen Bereich des Netzwerks verfügbar zu machen, zu teilen. Gefällt mir eine Seite, so gebe ich die URL dazu an, die Plattform ruft die URL auf und versucht anhand von Data-Mining eine möglichst knappe Übersicht davon in meiner Hauptseite darzustellen.

Inzwischen aber sind die Plattformen dazu übergegangen, mit technischen Hilfsmitteln direkt auf den fremden Seiten Links (“Like-Button”) anzubieten, mit denen ein Benutzer auf der dritten Seite eine Verknüpfung zwischen sich (seinem Plattformprofil) und der dritten Seite (z.B. IMDB) herstellen kann.

Im Prinzip eine gute Sache, denn wer es nicht braucht, der benutzt es einfach nicht. Schaden oder Mißbrauch entsteht ja keiner, oder?

Eine Ode an die Technik

Leider ist das nicht ganz richtig. Es verhält nämlich sich so:

Sobald Du Dich bei Deiner Plattform, nehmen wir Facebook als Beispiel, einloggst, werden ein Haufen Identifizierer -sogenannte Cookies- in Deinem Webbrowser gespeichert. Es erkennt daran, dass Du der Benutzer XYZ bist, aus welchem Land Du kommst, welchen Webbrowser Du benutzt, und viele andere Dinge. Im Wesentlichen lässt sich damit verhindern, dass jemand durch Abhören Deiner Verbindung auf seinem eigenen System sich als Dich ausgeben kann.

Mit anderen Worten: Bei jedem Seitenaufruf durch Dich werden sehr viele Informationen zwischen Deinem Browser und Facebook ausgetauscht.

Der nette Nebeneffekt ist, dass Du Dich nicht jedesmal bei einem Klick in Facebook einloggen musst. Die Plattform weiß ja, wer Du bist, und gewährt Dir daher die Rechte dazu.

Jetzt wird es ein bisschen schwieriger:

• Fakt eins: Auch wenn Du Dich ausloggst oder den Browser schließt, bleiben die meisten der oben genannten Cookies bestehen. Das heißt, Facebook weiß auch morgen noch, wer Du bist, obwohl Du dich noch gar nicht eingeloggt hattest.
• Fakt zwei: Bei jeder Anfrage an Facebook, also bei jedem Bild, jeder Seite, jedem Text und auch jedem Stück Programmcode (“JavaScript”), welche Dein Browser von Facebook anfragt, werden alle diese Cookies mitgesendet.
  Facebook weiß also immer, wer welches Bild, Text, usw. herunterladen und anschauen möchte, und das selbst dann, wenn Du nicht eingeloggt bist.
• Fakt drei: Es spielt keine Rolle, auf welcher Seite Du gerade surfst. Bist Du beispielsweise bei www.imdb.de unterwegs, und würde IMDB ein Bild von Facebook (und sei es nur das Facebook-Logo!) auf seiner Seite darstellen, dann würde Dein Browser:
  1. Von IMDB Inhalte laden
  2. An Facebook Deine Identifizierung (“Cookies”) senden
  3. Von Facebook das Titellogo laden

  Auch kann unter Umständen durch die Dauer der Anzeige, sprich wie lange es braucht, bis Du Dir ein neues Bild von Facebook lädst, darauf geschlossen werden, wie lange Du die Seite angesehen hast, und daraus, wie interessant der Inhalt für Dich war.

Facebook weiß damit ziemlich sicher über Dich, wann Du Dir wo Informationen über welchen Film angesehen hast. Nun kann man das bei Filmen sicher noch nachsehen, was aber bei politischen Inhalten? Was hat es Facebook oder irgendeine andere soziale Plattform zu interessieren, was Du Dir wann anschaust?

Meiner Meinung absolut nichts! Zeit, sich ein Stück Freiheit wiederzuholen.

Fleißige Helferlein

Aus der Not geboren wurde für den Firefox das nette Plugin Adblock Plus, das der Werbeflut im Internet Einhalt gebieten soll. Sein Einsatz ist nicht unumstritten, leben doch viele Seiten von der Darstellung der Werbung.

Nun gut, jeder muss das mit sich selbst ausmachen, wir werden es benutzen, um Facebooks Inhalte auch nur von dort zu laden, wenn wir uns gerade auf der Seite befinden.

Unser Filter soll also:

1. Alle Inhalte von Facebook blockieren (Iframes, Scripts, Images, Links, usw.)
2. Das auf allen Seiten des Internet
3. Es sei denn, wir surfen gerade auf facebook.com

Eine Winzigkeit gibt es noch zu beachten: Facebook lädt statische Inhalte von einer anderen Domäne. Der Filter muss das berücksichtigen.

Hier also die beiden Zeilen:

Diese Zeilen einfach in den Adblock Plus Einstellungen hinzufügen und schon ist man wieder sicher.

Es empfiehlt sich eine Gegenprobe mit Firebug, bei mir hat bislang alles geklappt.

Eine hitzige Diskussion entspann sich im Heise-Forum (Link möchte ich absichtlich nicht setzen, benutzt Google) über das Für und Wider des ePA. Befürworter führen gerne die fantastischen neuen Möglichkeiten an, die der elektronische Ausweis bieten soll und heben hervor, dass das System “sicher” sei und so wenig wie möglich zusätzliche und damit mißbräuchlich nutzbare Daten generiere.

Dem muss nun einmal widersprochen werden, ich habe deswegen Argumente zusammengetragen, die gegen das System argumentieren. Ihr werdet hier keine Pro-Argumente finden.

Einführende Links und Vorträge

Vorab sollte sich der geneigte Leser in der Wikipedia den für Nicht-Techniker relativ gut geschriebenen Artikel bzw. Abschnitt für den ePA zu Gemüte führen. Auch der gestreamte Vortrag über das verwendete Protokoll vom 26c3 erscheint sehenswert. Sehr interessante Vortragsfolien (PDF) habe ich von Dataport gefunden, sie zeigen für die Behörden praktische Auswirkungen auf.

Hier das Video eines Vortrags vom CCC, man möge dem Referenten seinen teils verwirrenden Stil vergeben.

Contra ePA

Vorab möchte ich anmerken, dass zu manchen Punkten Unklarheiten bestehen und ich diese updaten werde, sobald mehr Informationen verfügbar sind. Die entsprechenden Passagen sind selbstverständlich gekennzeichnet.

Anwendungen

Die wichtigste Frage stellt sich nach der Anwendung des ePA, genauer: dem elektronischen Identitätsnachweis. Es sind verschiedene Felder auslesbar und andere auf einen gegebenen Wert prüfbar. Im wesentlichen werden vier Betätigungsfelder angeführt:

• Hoheitsfunktion: Die Grenzbeamten im In- und Ausland können feststellen, ob der Ausweis gültig ist, die Namen mit dem Aufdruck übereinstimmen und ob die im Formular ausgefüllte Adresse mit der im Ausweis übereinstimmt, so sie sich die Mühe machem, die Adresse selbst in ihren Rechner zu klopfen. Wo da der Vorteil zum bisherigen Verfahren liegt, ist zumindest mir nicht ersichtlich. Unklar: Funktioniert die Prüfung online und wird das obligatorisch?
• Altersverifikation: Ist wohl vornehmlich für Zigaretten und Pornoprodukte gedacht. Verzeihung, aber Kippenkaufen geht auch mit Führerschein oder EC-Karte, Orion und Amazon liefern 18+-Produkte eben “zu Händen” bzw. “Persönlich” aus. Und der reguläre Durchschnittskonsument findet im Internet eine Reihe von kostenfreien Alternativprodukten, yourporn,  tube8 und deviantclips, um nur einige zu nennen.
• “Sichere Rechtsgrundlage” im Internet: Hä? Was ist denn jetzt die unsichere Rechtsgrundlage? Das Verfahren mit Vorkasse funktioniert doch sehr gut. Der Kunde zahlt und sagt, wo es hinsoll. Protokolle (z.B. “eMail”) halten die beteiligten Vorgänge einwandfrei fest auf beiden Vertragsseiten. Und nachdem die gespeicherte Adresse noch nicht einmal auslesbar, sondern nur “verifizierbar” ist, kann ich den Ausweis noch nicht einmal als “Ausfüllhilfe” bezeichnen. Und mal ehrlich, was interessiert’s den Versender, wo er hinversendet oder wie sein Kunde heißt? Er hat doch sein Geld schon bekommen, und die korrekte Adressangabe ist im Interesse des Kunden.
• Optional – Behördengänge mittels QES, eGovernment: Man soll sich offenbar authentifizieren (können), wenn man Offizielles bei der Verwaltung tätigt. Bei allem nötigen Respekt, aber wann muss ich das schon? Gewerbebetrieb und Steuererklärung funktionieren derzeit sogar ohne Zertifikate über ELSTER einwandfrei und unkompliziert, alles andere kann ich per Fax erledigen, und die Ummeldung, bei der es tatsächlich Einsparungen bringen könnte, mache ich einmal in fünf Jahren.

Unklar ist weiterhin, wie ich das eGovernment benutze: Während das BSI schreibt, dass eGovernment schon mit eID möglich ist, scheint die rechtsverbindliche Unterschrift, die bei Behörden vonnöten wäre, nur mit QES möglich zu sein. WTF!?

Weitere Anwendungen, weswegen man den Ausweis bräuchte, wollen mir gerade nicht einfallen.

Hardware

Für jeden teilnehmenden Rechner oder auch “Clienten” braucht man offenbar ein kompatibles = zertifiziertes Lesegerät. Ob das Lesegerät oder der teilnehmende Rechner (nicht Benutzer!) an sich im System eindeutig identifizierbar ist oder sein wird, ist mir derzeit unklar. Im digitalen Behördenfunk wird das so sein, jedes Gerät soll ja eindeutig adressier- und vor allem sperrbar sein, falls es verloren geht oder gestohlen wird.

Nun stellt sich die Frage, ob wir denn nichts gelernt haben aus HBCI und FinTS, dem “sicheren” Online-Banking. Die Parallelen sind frapide: Man brauchte ein Lesegerät (ca. 30,- €, soweit ich noch weiß), von der Bank eine HBCI-Chipkarte (ca. 10,- €) und HBCI-PIN sowie eine kompatible zertifizierte (?) Software (z.B. Starmoney oder das T-Online Produkt). HBCI hat es nie weit gebracht, vermutlich, weil der finanzielle und organisatorische Aufwand für den Anwender im Gegensatz zum Nutzen zu groß war.

Zwar ist das System bestehend aus Webinterface und *TAN nicht besonders sicher, aber dafür einfach und von relativ vielen Menschen bedienbar. Und hier noch eine inoffizielle sinngemäße Aussage eines Vorstands einer österreichischen Bank:

Sicher kosten die Schäden, welche uns durch Online-Banking-Betrug und PIN-Phishing entstehen, Geld. Es würde uns aber sehr viel mehr kosten, wenn wir durch neue Verfahren und neue Sicherheitssysteme unsere Kunden verunsichern. Daher zahlen wir lieber und machen um diese Vorfälle keinen großen Wind.

Software

Damit ein Rechner am System teilnehmen kann, muss zusätzlich darauf eine Software, der sogenannte Bürger-Client, installiert werden. Laut Wikipedia ist der Auftraggeber das Bundesministerium des Inneren (BMI), und da habe ich schon aufgehört zu lesen. Außer dem Wikipedia-Artikel habe habe keine detailreicheren Beschreibungen zur Software gefunden. Folgende Punkte sind unklar:

• Wird die Software OpenSource (No Security through Obscurity!)?
• Für welche Betriebssysteme wird es sie geben?
• Wer garantiert mir, dass ein potentiell vorhandenes Auto-Update-Feature keinen Bundestrojaner auf meinen Rechner lädt bzw. dass die Software nur genau das tut, was sie soll?
• Muss sie unter einem Administrator-Account laufen?

Verbindung

Offenbar benötigt der Client eine Online-Verbindung. Das kann ich zwar bei den Personen, die die obigen Anwendungen nutzen, als gegeben voraussetzen, auf der anderen Seite aber hatten 2007 “nur” knapp 20 Millionen Haushalte von 39 Millionen, sprich zirka die Hälfte, einen Breitbandanschluss. Über Schmalbandverbindungen habe ich keine verläßlichen Aussagen gefunden.

Potentiell müssen also die Mitglieder der anderen 20 Millionen Haushalte vorerst auf die Benutzung des Systems verzichten, bezahlen es aber trotzdem.

Usability

Weiterhin gibt es verschiedene Daten und Nummern, mit denen der Benutzer zurecht kommen muss:

• Personal Identification Number (PIN) zum Benutzen der eID Funktionen
• Aufgedruckte CAN für dritten Eingabeversuch der PIN
• PIN Unblocking Key (PUK) zum Zurücksetzen von drei Fehlversuchen (PIN-Änderung damit aber nicht möglich)
• Sperrkennwort für den Ausweis
• Optional: PIN2 für QES
• Unklar: PUK2 zum Entsperren der PIN2?

Der Nutzen der CAN stellt sich mir sehr infrage, nachdem offenbar ein simpler Kopierer diese Nummer bereits kopieren kann und sie statisch zu sein scheint. Es scheint so zu sein, dass die Nutzung der CAN sicherstellen soll, dass der Ausweis tatsächlich vor Ort am Lesegerät liegt, nachdem sie offenbar nur für hoheitliche Stellen benutzbar ist.

Jetzt aber kommt der Hammer: Man mache die Unterschiede zwischen diesen Teilen einem Nicht-Techniker klar. Yummi! By the way: Wenn die PIN dreimal falsch eingegeben wurde, was bei älteren Teilnehmern schon mal vorkommt, kann nur noch eine Behörde mit entsprechendem Zertifikat (oder der PUK) dat Dingen wieder entsperren. Juchuu, wenn so ein Entsperrzertifikat, von denen es potentiell Hunderte geben kann, abhanden kommt, nicht wahr (der Vollständigkeit halber möchte ich diesen Punkt allerdings als unklar anbringen).

Biometrie

Das Paßfoto wird elektronisch auf dem Ausweis gespeichert, und ist offenbar durch hoheitliche Stellen auslesbar. Zitat aus diesem PDF, Seite 71:

Aufdruck der Karten-Zugangsnummer, mit der hoheitliche Stellen auf alle Daten [confirmed: auch die eID-Daten] im Chip zugreifen können.

Nachdem nicht klar ist, was “zugreifen” genau bedeutet, gehe ich einmal davon aus, dass es mit “auslesen” gleichzusetzen ist. Dafür ist offenbar ein wiederum potentiell hundertfach vorhandenes Hoheitszertifikat ausreichend. Außerdem steht der Beweis, dass eine automatisierte Gesichtserkennung besser ist als die eines Menschen, noch aus. Stichwort “Seam-Carving”.

Gläserner Bürger, Überwachung, Mißbrauch

Neben der schon angesprochenen potentiellen (unklaren) Schwachstelle der vielen verteilten Zertifikate, die etwas dürfen in den Ausweisen (PIN zurücksetzen und entsperren, Adressen ändern, Ausweis für ungültig erklären, Daten auslesen, und anderes) existiert möglicherweise eine eklatante Schwachstelle im Datenschutz.

Fakt ist, dass eine Firma, die eID für ihre Kunden anbieten möchte, sich beim Ausweishersteller (Bund oder BMI) zertifizieren lassen muss und ein entsprechendes elektronisches Zertifikat bekommt, mit welchem sie Datenfelder aus Kundenausweisen auslesen kann (Zustimmung des Kunden natürlich vorausgesetzt).

Offensichtlich gibt es weiterhin sogenannte Sperrlistenbetreiber, die die von einer PKI bekannten Revocation-Lists (CRL) bereithalten, also das Wissen darüber, welche Ausweise (genauer: deren IDs) ungültig sind. Eventuell ist der Inhaber gestorben, oder hat seinen Ausweis selbst gesperrt, die Gründe sind verschieden.

Es macht daher für jeden eID-Teilnehmer (Geschäft oder hoheitliche Stelle) Sinn, einen Ausweis vorab auf Gültigkeit zu prüfen. Legt der Kunde einen ungültigen Ausweis vor, würde die restliche Transaktion (Bestellung, Einreise, usw.) abgebrochen oder zumindest anders abgewickelt werden.

Das Geschäft oder die hoheitliche Stelle wird also bei dem oder einem Anbieter der offiziellen CRL die Gültigkeit des Dokumentes nachfragen. Damit ergibt sich auf der Anbieterseite der CRL ein Record ähnlich des folgenden:

• ID des Ausweises
• ID der anfragenden Einheit
• Zeitstempel

Kann nun eine Verknüpfung hergestellt werden zwischen Ausweis-ID und Inhaberdaten, was theoretisch bei jedem Online-Einkauf mit eID-Funktion geschieht, hat der CRL-Betreiber bereits wertvolle Daten erhalten.

Kann eine weitere Verknüpfung zwischen Lesegerät-ID und Standort bzw. Inhaber hergestellt werden (potentiell beim Herausgeber der Zertifikate vollständig vorhanden), so ist nun auch bekannt, welchem Zweck die Abfrage diente. Hat beispielsweise der “Orion-Versand” für “Max Müller” die Gültigkeit geprüft, dürfte recht eindeutig sein, was Max Müller wohl bestellt hat.

Die Gefahr besteht deswegen aus meiner Sicht, dass sich vollständige Reise- und Kaufprofile von Benutzern erstellen lassen. Allein dass die Möglichkeit besteht, rechtfertigt schon eine ernsthafte Sorge, denn wo Mißbrauchsmöglichkeiten bestehen, werden sie früher oder später auch genutzt. Siehe Deutsches LKW-Mautsystem und Gefahrenabwehr. Lach.

Kosten

Mein herkömmlicher Ausweis hat knapp 8,- € gekostet. Der Bio-Reisepass hat 56,- € EUR, knapp das doppelte, gekostet. Nun stellt sich mir die berechtigte Frage: Wer soll das bezahlen, wer hat soviel Geld?

Das BMI meint lapidar:

Was wird der elektronische Personalausweis kosten?
Noch befindet sich der elektronische Ausweis in der Planungsphase. Ein Preismodell wird derzeit erarbeitet. Ziel der Konzeptionierung ist es, Kosten und Nutzen für die Bürgerinnen und Bürger ausgewogen zu gestalten.

Bedeutet also, ich als Anwender soll den Käse auch noch zahlen. Und es hört ja nicht beim Ausweis auf. Wer bezahlt den Leser? Wer ersetzt den Teilnehmern im Internet (Versandshops) ihre Kosten für die Zertifizierung? Zumindest die Vergangenheit zeigt, dass das die Verbraucher sein werden. Vielen Dank dafür.

Fazit

Null Nutzen, mehrfache Kosten. Was soll der Quatsch! Ich werde mir rechtzeitig im Oktober noch einen alten Ausweis holen, dann hab ich wenigstens für 10 Jahre Ruhe.

Wir alle kennen die Problematik. Im Prinzip würde sichere eMail bereits seit einigen Jahren funktionieren; sofern beide Benutzer jeweils ihre öffentlichen Schlüssel zur Verfügung stellen, könnte eine mit asymmetrischer Kryptographie geschützte Kommunikation ohne weiteres stattfinden. Leider ergeben sich in der Praxis handfeste Schwierigkeiten, die eine breite Anwendung von Kryphtographie verhindern.

Im Folgenden möchte ich einige dieser Probleme aufzeigen und Ihnen dann für den Teilbereich Webanwendungen, der meines Wissens nach noch nicht untersucht wurde, ein Konzept vorstellen, wie Sie Ihre Kunden in Ihrer Webanwendung sicher per eMail kontaktieren können.

Asymmetrische Verschlüsselung

Verschlüsselung von eMail ist mit einigen Problemen aus Benutzerperspektive und in technischer Hinsicht verbunden. Grundsätzlich hat man in der vertraulichen Kommunikation mit zwei Basisproblemen zu kämpfen:

• Inhalt der Kommunikation absichern (“Verschlüsselung”)
• Identität des Absenders garantieren (“Signatur”)

Um die obigen Probleme zu lösen, benutzt man asymmetrische Verschlüsselung.

Ein asymmetrisches Kryptosystem ist ein Kryptosystem, bei dem jede der kommunizierenden Parteien ein Schlüsselpaar besitzt, das aus einem geheimen Teil (privater Schlüssel) und einem nicht geheimen Teil (öffentlicher Schlüssel) besteht. Der öffentliche Schlüssel ermöglicht es jedermann, Daten für den Inhaber des privaten Schlüssels zu verschlüsseln, dessen digitale Signaturen zu prüfen oder ihn zu authentifizieren. Der private Schlüssel ermöglicht es seinem Inhaber, mit dem öffentlichen Schlüssel verschlüsselte Daten zu entschlüsseln, digitale Signaturen zu erzeugen oder sich zu authentisieren. [Quelle]

Zusammengefaßt:

Verschlüsselung

Signatur

symmetr. Key

1. Um eine Nachricht zu verschlüsseln, verwendet man den oder die öffentlichen Schlüssel des oder der Adressaten.
2. Um eine Nachricht zu signieren, verschlüsselt man den Hash der Nachricht mit dem eigenen privaten Schlüssel.

Leider arbeiten asymmetrische Verfahren sehr langsam. Es wird daher ein hybrides Verfahren eingesetzt, in dem über Asymmetrie nur ein Schlüssel für ein symmetrisches Verfahren (z.B. RC4) ausgehandelt wird. Die beschriebenen Vorgänge hier noch einmal als Grafiken.

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.

Technik eines Seitenaufrufes

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?

Domain-Name-System

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:

• Windows 98
• Windows 2000
• Windows XP
• Mac OS 8.x und 9.x
• Mac OS X
• Debian GNU/Linux

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.

Verbindungsaufbau

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:

1. 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.
2. 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.

Adressierung des Inhaltes – Theorie

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:

Adressen

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.

Auslieferung des Inhaltes (ohne Verschlüsselung)

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:

1. Welche Ressource (Datei oder Ordner) ist gewünscht?
2. 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):

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:

1. DNS dient dazu, den Server physikalisch ausfindig zu machen
2. 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.

Und mit Verschlüsselung (https)?

Bei HTTPS greifen einige Sicherheitsmechanismen und stellen folgendes sicher:

1. 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.
2. 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.

Fazit

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.

Error creating directory
C:\\Users\\Mein S\x366chsiche Benutzername\\AppData\\Roaming\\tor

Eine Volltextsuche nach dem Pfad förderte die Datei “C:\Users\Mein Söchsiche Benutzername\AppData\Roaming\Vidalia\vidalia.conf” zu Tage, in der ich dann just ziemlich weit oben den Text

DataDirectory=
\"C:\\\\Users\\\\Mein S\\366chsiche Benutzername\\\\AppData\\\\Roaming\\\\tor\"

gefunden habe. Das sollte natürlich geändert werden zu

DataDirectory=
\"C:\\\\Users\\\\Mein S\xf6chsiche Benutzername\\\\AppData\\\\Roaming\\\\tor\"

und nach einem Neustart des Programms Vidalia lief alles wie gewohnt. Wenn ihr andere Sonderzeichen habt, seht in den Pfadangaben darüber nach, dort sind diese ebenfalls angegeben und ihr könnt die Codierung einfach 1:1 übernehmen.