Zwei Dinge kann man natürlich aus dieser heißen Luft trotzdem mitnehmen: wer aus Prinzip verschlüsselt, macht es den Geheimdiensten schwerer - die Masse macht's. Und man fällt auf und ist damit automatisch verdächtig. Das kann sich jetzt jeder selbst überlegen.
Wie man Emailverschlüsselung einrichtet, wird übrigens hier ganz gut erklärt (am Beispiel von Thunderbird in Windows, das Grundprinzip ist aber bei Mac und Linux fast identisch), und ich hatte das vor einiger Zeit auch schon mal beschrieben.
Was genau passiert nun bei Verschlüsselung, und wie funktioniert Abhören?
Normalerweise nimmt man einen Browser oder ein Emailprogramm und der Computer zuhause - der Client - baut eine Verbindung zu einem anderen Computer auf, dem sogenannten Server, der eine Dienstleistung anbietet, sei das nun WWW oder Email oder Chat oder etwas ganz anderes; für unsere Betrachtungen ist das vollkommen unerheblich.
Ich will jetzt auch gar nicht so ganz im Detail darauf eingehen, wie diese Verbindung funktioniert, aber das OSI-Schichtenmodell spielt dabei eine Rolle, und die üblichen Verbindungen laufen über das TCP-Protokoll im TCP/IP. Wer tiefer Bescheid wissen will, möge den Links folgen.
Bei unverschlüsselten Verbindungen fragt der Client den Server im Klartext, und die Antwort des Servers darauf erfolgt ebenfalls im Klartext. Hier ist es natürlich vollkommen problemlos, den kompletten Inhalt in beiden Richtungen abzuhören, wenn man sich an einer der Knotenstellen dazwischen einklinken kann - Geheimdienste machen das gern am DE-CIX in Frankfurt, da trifft sich so gut wie alles, was Rang und Namen hat ... Die Bundesregierung verweigert übrigens die Antwort auf die Frage, ob deutsche Geheimdienste ebenfalls am DE-CIX abhören. Allein diese Weigerung finde ich schon sehr bezeichnend.
Man erzeugt ein Duplikat des Datenstroms, und schon mit billigen Sniffer-Werkzeugen wie Wireshark kann man gezielt herausfiltern, dass man an einer bestimmten Verbindung des Typs "T" von "A" nach "B" interessiert ist (T=email, A=Thomas, B=pop.gmx.net).
Gut, das wollen wir natürlich nicht (ich zumindest), und deswegen wollen wir es dem Lauscher an der Wand etwas schwieriger machen, und schalten TLS ein. Was bedeutet das technisch? Zunächst einmal bedeutet es, dass wir den modernen neuen Namen verwenden. Früher hieß das nämlich noch SSL, und von diesem Namen stammt auch das "s" für "secure" in den URLs, wie z.B. https://www.ccc.de.
TLS ist eine Sammlung von Methoden und Protokollen, mit denen man ver- und entschlüsseln kann, sowie Prüfsummen nach allen möglichen Standards berechnen kann. Es gibt mehrere Softwarepakete, die TLS bzw. SSL anbieten, darunter das am häufigsten verwendete OpenSSL oder auch GnuTLS.
Das Tolle an TLS ist, dass man die Ver- und Entschlüsselung mit unterschiedlichen Codes durchführen kann (asymmetrische Verschlüsselung). Der Code zum Verschlüsseln kann ruhig bekannt werden; deshalb wird er auch "öffentlicher Schlüssel" genannt. Selbst wenn man ihn besitzt, kann man einen verschlüsselten Text damit nicht wieder lesbar machen. Nur wenn man den dazugehörigen "privaten Schlüssel" besitzt, kann man den Text dechiffrieren. Ein bekanntes Verfahren heißt RSA und wurde nach den Entwicklern Rivest, Shamir, Adleman benannt.
Das asymmetrische Prinzip mit der Aufteilung in einen öffentlichen und einen geheimen Schlüssel hat zwei besondere Eigenschaften, die beide sehr nützlich sind und verwendet werden. Zum Einen kann man mit dem öffentlichen Schlüssel etwas unlesbar machen und nur der Empfänger kann es mit seinem geheimen Schlüssel wieder lesbar machen. Nicht einmal der Absender kann die Verschlüsselung rückgängig machen! Zum Anderen kann der Besitzer des geheimen Schlüssels eine elektronische Unterschrift (Signatur) erzeugen, und jeder kann mit dem öffentlichen Schlüssel prüfen, ob die Unterschrift korrekt ist.
Beim ersten Verbindungsaufbau sendet der Client eine Anfrage, ob der Server Verschlüsselung unterstützt. Falls ja, bietet er eine Liste von Verschlüsselungsverfahren an und sendet auch gleich seinen öffentlichen Schlüssel mit (in Wahrheit ist es etwas komplizierter, aber das ist das Prinzip). Mit diesem öffentlichen Schlüssel kann also der Client schon mal chiffrierten Text an den Server schicken, und nur der Server kann ihn wieder lesbar machen.
Soweit, so cool ... aber wie geht der Rückweg?
Im Prinzip funktioniert der Weg der Serverantworten genauso, nur andersrum ;).
Der Client und der Server einigen sich auf ein bestimmtes Verschlüsselungsverfahren (z.B. AES) und tauschen beim Verbindungsaufbau einen geheimen Schlüssel aus, der nur für diese eine Verbindung verwendet wird. Diesen etwas komplizierten, umständlichen Weg geht man, weil das asymmetrische Verfahren sehr rechenaufwändig ist. Man setzt es deshalb nur einmal ein, um einen zufällig gewählten Code für ein schnelleres, typischerweise symmetrisches Verfahren auszutauschen.
Soweit, so cool ... aber woher weiß ich, dass der Server wirklich die Maschine ist, die ich ansprechen will und nicht eine andere Kiste, vielleicht wurde ich sogar umgeleitet mittels Angriffsmechanismen wie DNS-Fälschung, ARP-Fälschung usw.?
Jetzt wird's komplizierter ;). Erst mal weiß ich das nicht. Der Server bietet mir beim Verbindungsaufbau seinen öffentlichen Schlüssel an. Aber ich weiß noch nicht, ob das alles zusammenpasst. Ich kann natürlich über einen anderen Weg prüfen, ob der "Fingerabdruck" (fingerprint) des öffentlichen Schlüssels korrekt ist, aber dann müsste ich mir selbst eine Liste von Fingerprints aufbauen für alle Webserver, Emailserver usw., mit denen ich sprechen will.
Üblicherweise geht man einen anderen Weg: man lässt sich den öffentlichen Schlüssel "signieren" von einem vertrauenswürdigen Dritten, einer sogenannten Zertifizierungsstelle. Und man vertraut dann nicht jedem einzelnen öffentlichen Schlüssel jedes Servers, sondern einmalig der Zertifizierungsstelle. Das sind die "Vertrauenswürdigen Institutionen" in den Interneteinstellungen bei Windows bzw. die "Authorities" im Firefox-Browser.
Das ganze scheitert dann, wenn diese Zertifizierungsstellen unterwandert oder kompromittiert werden, und dafür gibt es leider mehr als genug Beispiele, eben weil diese Abhörmöglichkeit extrem attraktiv ist.
- Vor einigen Jahren wurde die niederländische DigiNotar gehackt und gefälschte Zertifikate für bekannte Hostnamen von Google und anderen signiert (insgesamt gab es über 500 gefälschte Signaturen)
- neulich gab es eine schlimme Panne in der Türkei
- aus dem Iran ist bekannt, dass 2011 zum Abhören gefälschte Zertifikate für google.com erkannt wurden, vermutlich vom Einbruch bei DigiNotar
- das israelische Unternehmen StartSSL wurde angegriffen
- ein Angriff auf die französische ANSSI ist noch ungeklärt
- und jetzt aktuell wurde bekannt, dass die staatliche NIC von Indien ebenfalls versucht hat, mit Zertifikaten für Hostnamen bei Google und Yahoo ihre Bürger abzuhören.
Das Problem ist nämlich: wenn das Zertifikat gefälscht ist, d.h. "falsch" signiert ist, funktioniert es technisch immer noch problemlos und sieht immer noch genauso vertrauenswürdig aus, obwohl es jemand mit böser Absicht erzeugt hat und verwendet. Nur die "Unterschrift" ist von einer anderen Stelle, der mein Browser aber ebenfalls vertraut. Nur wenn man weiß, dass das Zertifikat normalerweise von Verisign signiert wird und eben nicht von "NIC India", dann springt einem die Fälschung sofort in's Auge.
Das wäre genauso, als ob man bei einem Brief nur darauf schaut, dass er handschriftlich unterschrieben ist, aber man prüft nicht, ob die Handschrift wirklich "echt" ist.
Googles Chrome-Browser prüft übrigens bei einigen Hostnamen, ob das Zertifikat von der richtigen Instanz unterschrieben wurde, und schlägt Alarm, wenn man auf diese Weise auf eine Fälschung trifft. Diese Prüfung heißt "certificate pinning" - man legt in der eigenen Software fest, welche Signatur erwartet wird.
Als Fazit lässt sich sagen: die Mathematik lässt sich (derzeit) nicht austricksen, aber das System der vertrauenswürdigen Signaturstellen ist gehörig angeknackst, um nicht zu sagen: es ist kaputt.
Das Problem ist natürlich offensichtlich und wird auch bereits unter Sicherheitsforschern diskutiert. Eine Möglichkeit ist, dass jede Certificate Authority, die Signaturdienstleistungen anbietet, öffentlich macht, für wen sie Zertifikate ausgestellt hat. Damit könnte jeder Browser prüfen, ob ein Zertifikat wirklich hochoffiziell von dieser CA signiert werden durfte.
Bislang gab es eine gewisse Vertrauenswürdigkeit in die Signaturstellen, aber das ist in's Wanken geraten mit Bekanntwerden der Tatsache, dass insbesondere amerikanische Geheimdienste gern man mit geheimgehaltenen Gerichtsurteilen die Herausgabe aller Schlüssel erzwingen, wie etwa im Fall des Emaildienstleisters Lavabit.
Ein weiterer Ansatz ist eine Sperrliste. Da greift aber erst, wenn einem Besitzer aufgefallen ist, dass ein gefälschtes Zertifikat im Umlauf ist oder ein echtes gestohlen wurde. Die Browser können bei einer Auskunftsinstanz nachfragen, ob ein gegebenes Zertifikat (noch) gültig ist oder widerrufen wurde. Einerseits hat dies mächtige Performance-Probleme, weil für jedes Zertifikat eine Anfrage abgeschickt werden muss. Andererseits ist das ein riesiges Problem für die Privatsphäre, wenn ich einer weiteren Instanz mitteile, wo ich gerade surfe. In Firefox und Chrome gibt es diese Technik, da aber Google diese Probleme als zu schwerwiegend ansieht, ist das Feature abgeschaltet. Es gibt aber technische Weiterentwicklungen, wie z.B. eine einzelne zentrale Sperrliste.
Keine Kommentare:
Kommentar veröffentlichen