Simon Koelsch coding software, using gadgets

5Apr/11Off

SSL und was es damit eigentlich auf sich hat

Wir nutzen das Internet immer mehr unterwegs. Nicht nur von mobilen Endgeräten wie Handys sondern auch der Laptop / das Netbook sind immer dabei. Sei es über das UMTS Netz, einen WLAN Zugang im Cafe, an der Uni oder bei Freunden. Dabei ist es wichtig verschlüsselte Verbindungen zu nutzen, um Zugangsdaten und private Informationen nicht im Klartext zu senden. Es geht hierbei nicht nur um die Privatsphäre sondern auch um den Schutz vor Missbrauch und Identitätsdiebstahl. Der eigene Internetzugang ist dabei keine Ausnahme. Zugegeben die Wahrscheinlichkeit, dass zum Beispiel jemand meine Kommunikation mit dem Mailserver mitliest ist deutlich geringer, aber immernoch vorhanden.
Ettercap demonstriert schon seit einer kleinen Ewigkeit, wie einfach ein entsprechender Man-In-The-Middle Angriff zu bewerkstelligen ist. Der Angreifer liest dabei den Datenverkehr als Dritter zwischen Server und Client. Mit dem vor mehreren Monaten veröffentlichten Browser Plugin Firesheep wird das Sniffen von Logon-Cookies zum Kinderspiel. Mit diesem abgefangenen Cookie kann sich der Angreifer dann gegenüber einer Homepage unter dem Account des Opfers einloggen.
Beim Besuch von Webseiten gibt es meist die Möglichkeit den Server ueber HTTPS anzusprechen, wodurch die Verbindung durch SSL gesichert wird. Twitter und Facebook bieten seit einiger Zeit die Einstellung an, grundsätzlich in eine HTTPS gesicherte Verbindung zu wechseln. Um aber wirklich von der Verschlüsslung zu profitieren ist es wichtig zu verstehen, wie SSL eigentlich funktioniert.

SSL/TLS

SSL steht fuer Secure Socket Layer und beschreibt eine Technik um sichere Verbindungen herzustellen. Der aktuelle Name ist daher auch Transport Layer Security (TLS). Der Einfachheit halber will ich hier trotzdem die Bezeichnung SSL benutzen.
SSL benötigt zum Aufbau einer verschlüsselten Verbindung zu einem Server dessen öffentlichen Schlüssel. Die Daten können dann nur vom Server mit seinem privaten Schlüssel wieder in Klartext verwandelt werden. Dieses Prinzip bezeichnet man als Public-Key-Verfahren.
Bei HTTPS wird dem Browser, welcher die Verbindung zu einem Webserver aufbauen will, dieser Schlüssel in Form eines X.509 Zertifikats zur Verfügung gestellt. Dieses Zertifikat enthält im Regelfall neben dem Schlüssel noch die Domain, eine Gültigkeit sowie mehr oder weniger Informationen über den Aussteller und Inhaber.

Zertifizierungsstellen

Dieser Schlüssel löst zwar das Problem der Verschlüsslung, verhindert aber nicht zwangsläufig einen Man-In-The-Middle Angriff. Ist ein Angreifer in der Lage den Datenverkehr mitzulesen und zu verändern, kann er bei der Übertragung des öffentlichen Schlüssels diesen durch einen eigenen ersetzen. Danach ist die Verbindung zwar gesichert, der Kommunikationspartner ist allerdings nicht der eigentliche Zielserver, sondern der Angreifer. Es muss also sichergestellt sein, dass man wirklich das Zertifikat des Servers erhalten hat. Ein Zertifikat kann allerdings für beliebige Domains mit beliebigem Inhalt selbst erstellt werden, man sieht ihm nicht direkt an, ob es echt oder falsch ist.

Zu diesem Zweck gibt es das Prinzip von Zertifizierungsstellen, sogenannten CAs (Certificate Authorities). Die Idee dahinter ist, dass man einer bestimmten CA vertraut und damit auch den von ihr ausgestellten Zertifikaten. Um zu prüfen ob ein bestimmtes Zertifikat auch wirklich von dieser CA ausgestellt wurde benötigt man zum Vergleich deren Root-Zertifikat. Ein Browser enthält daher eine lange List an Root-Zertifikaten von verschiedenen Unternehmen. Diese Zertifizierungsstellen haben sich verpflichtet die in ihren Zertifikaten enthaltenen Daten zu prüfen. Dabei sollte zum Beispiel nur der Inhaber einer Domain sich ein Zertifikat für diese ausstellen lassen können.

Wer bist du wirklich?

In der Praxis fangen aber genau hier die eigentlichen Probleme an. Die Liste der Zertifizierungsstellen ist in allen gängigen Browsern sehr lang. Eine CA kann ausserdem die Möglichkeit des Signierens von Zertifikaten weiter delegieren. So kann eine lange Kette an CAs entstehen, die berechtigt sind gültige Zertifikate auszustellen.
Ein anschauliches Beispiel (entliehen von Certificate Patrol) ist die Bayrische Staatsbibliothek. Deren Zertifikat wurde von der eigenen Zertifizierungsstelle ausgestellt. Der Browser vertraut dieser Stelle nur weil ihr vom Deutschen Forschungsnetz vertraut wird, dem wiederum die Deutsche Telekom vertraut. Erst deren Root-Zertifikat ist in den Browsern hinterlegt. Eine "kleine" Liste von CAs nur für Deutschland findet sich bei Netcraft. Dort findet man dann auch Nestle oder Adidas in der Liste.
Absolut sichere Systeme gibt es nicht, und so kommt es immer wieder vor, dass durch die Vortäuschung falscher Informationen oder einem Einbruch in einen Server gefälschte Zertifikate ausgestellt werden.
Für einen Browser gibt es nicht zwangsläufig einen Unterschied zwischen dem echten Zertifikat meiner Bank und einem Zertifikat, welches von einer CA in einem Land ausgestellt wurde, indem ich mich nichtmal trauen würde Urlaub zu machen. Er wird in beiden Fällen eine "gesicherte Verbindung" anzeigen.
Ein aktuelles Beispiel ist Comodo, bei dem es ein Hacker geschafft hat, sich Zertifikate für Seiten wie Google Mail und Skype zu beschaffen.
Es gibt bei SSL zwar einen Mechanismus um Zertifikate über eine Liste zu widerrufen, allerdings müssen diese Fälle auch bekannt sein.
Abhilfe schaffen zumindest teilweise verschiedene Tools.

Unterstützende Tools

Perspectives

Perspectives ist ein Firefox und Chrome Plugin, um sich auch vor solchen Angriffen zu schützen. Die Idee dahinter ist es, beim Aufbau einer gesicherten Verbindung einen dritten Server nach der Checksumme des Zertifikats zu fragen und diese zu vergleichen. Der dritte Server ermittelt dann über seine eigene Verbindung die Checksumme. Ist diese unterschiedlich, ist von einem Man-In-The-Middle Angriff auszugehen, das heisst ein Angreifer hat sein eigenes gefälschtes Zertifikat in die Verbindung eingeschleust. Ausserdem werden die Checksummen auf dem dritten Server gespeichert. Dadurch wird es möglich zu prüfen ob sich das Zertifikat des Servers erst vor kurzem geändert hat.
Die Perspectives Entwickler betreiben ein kleines Netzwerk von sogenannten Notary Servern die vom Browserplugin abgefragt werden. Bekommt man von Google Mail dann plötzlich ein neues Zertifikat, obwohl die Notary Server eine andere Version kennen, gibt das Anlass zur Sorge. Zusätzlich gibt es fuer den Datenbestand der gecachten Checksummen auch ein Webinterface.
Durch diese Art der Anfragen ist natürlich nachvollziehbar, welche gesicherten Seiten ich besucht habe. Die Policy der Notary Server legt dabei viel Wert auf Datenschutz und verspricht die IP Adressen der Nutzer nicht zu speichern. Wer trotzdem lieber einen eigenen Notary Server betreiben moechte kann das mit der quelloffenen Python Server Software tun.

Certificate Patrol

Ein anderes Firefox Plugin welches den Umgang mit SSL sicherer macht ist Certificate Patrol. Es speichert einfach die Zertifikate der besuchten Seiten. Ändert sich danach etwas am Zertifikat zeigt Certificate Patrol diese Änderung zum ursprünglichen Zertifikat an.
Benutzt die eigene Bank dann plötzlich ein Zertifikat aus dem Iran, sollte man sich überlegen ob man sein Onlinebanking nicht verschiebt.
Auch auf weitere Unstimmigkeiten weist Certificate Patrol hin.

Fazit

Es gibt leider keine pauschale Sicherheit. Der gern propagierte Hinweis, "Achten sie auf das grüne Schloss in der Adresszeile des Browsers", bedeutet leider nicht automatisch eine sichere Verbindung. SSL ist eine Lösung für diese Sicherheitsprobleme, in der Praxis funktioniert diese Lösung allerdings nicht so ohne weiteres, zumindest nicht ohne sich mit der Thematik auseinandergesetzt zu haben. Man darf gespannt sein, was fuer Alternativen in den nächsten Jahren auf uns zukommen.
Im Moment hilft nur "Kopf einschalten".

Kommentare (0) Trackbacks (0)

Die Kommentarfunktion ist hier derzeit deaktiviert.

Trackbacks are disabled.