Single post

SSL oder warum du der IT der Bayrischen Staatsbibliothek vertrauen solltest

Will man sich vor Internetkriminalität und Überwachung schützen und eine sichere, verschlüsselte Verbindung zu einer Website aufbauen, so braucht man nur darauf zu achten, dass der Browser links oben vor der Internetadresse eine kleines Sicherheitsschloss oder ähnlich suggestives Symbol einblendet. Das hat sich sogar bis zum österreichischen Innenministerium herumgesprochen.

Richtig? Leider nicht ganz. Um zu verstehen, was SSL eigentlich leisten kann (und wovor es eben nicht schützt: nämlich staatlicher Überwachung), muss man genauer verstehen, wie SSL funktioniert: Verbindet sich ein Webbrowser zu einem https-Server, wird die Verbindung als vertrauenswürdig eingestuft, wenn der Server ein gültiges Zertifikat samt Unterschrift von einer sogenannten trusted certificate authority (CA) präsentieren kann. Solch vertrauenswürdigen CAs sind unter anderem all diejenigen, deren Zertifikat im Browser vorinstalliert ist. Diese sogenannten root CAs können ihrerseits jedoch beliebig viele subordinate CAs bzw. intermediate CAs (SCAs bzw. ICAs) vertrauen.
Eine Liste all der vorinstallierten Zertifikate kann man bei mir unter Preferences->Advanced->Security->Certificates ansehen. Und es ist eine kleine Überraschung, wer da alles unser Vertrauen genießt:“TÜRKTRUST“ oder eine kontrovers diskutierte der chinesischen Regierung unterstellte Institution namens „CNNIC“ sind nur die lustigsten Beispiele, die sich nach kurzem Überfliegen der Liste entdecken lassen. Der deutsche Bundestag, die HU Berlin und die bayrische Staatsbibliothek gehören genausosehr zu den vertrauenswürdigen SCAs, wie man auf den Seiten petitionen.bundestag.de, agnes.hu-berlin.de und bsb-muenchen.de überprüfen kann. Außerdem dabei sind natürlich auch lauter private Firmen wie z.B. T-Systems, Verisign und godaddy.

Was bedeutet das konkret? Jede der vorgenannten Institutionen und Firmen (sowie viele tausend weitere) können sich als eine beliebige SSL-gesicherte Website ausgeben, ohne dass der Browser eine Fehlermeldung ausgeben würde. Konkreter: Hat nun ein Angreifer (staatlich oder nicht-staatlich) Zugriff auf den Traffic (z.B. über offene WiFi-Hotspots wie sie etwa in den Bussen von MeinFernbus verwendet werden) und ist im Besitz solch eines Zertifikates, dann ist es trivial, dem angegriffenen Browser die Authentizität beliebiger Websites vorzuspielen: Konkret heißt das: Jedes Passwort, dass man über eine verschlüsselte Verbindung eingibt, kann mitgeloggt werden (z.B. webmail, Online-Banking, ebay), beliebige website-Inhalte können verändert werden. Tätigt man eine Online-Überweisung über ein Online-Banking-Interface, so ist trotz iTan-Verfahren einem Anfreifer eine Überweisung auf ein beliebiges Konto möglich. Installiert man Software (etwa ein Firefox-Plugin), so ist danach die Sicherheit des gesamten Systems kompromittiert.

Diese Bedrohung ist nicht etwa abstrakt, sondern ganz konkret. Dazu muss eine dieser Institutionen nicht einmal bösen Willens sein, es reichen schon kleine Unachtsamkeiten, Inkompetenz oder Sicherheitslücken (oder böser Wille, der sich als solche tarnt). Aktuelle Beispiele gefälschter Zertifikate für google.com  findet man auf dem google security blog. Dabei ließen sich die ausgestellten Zertifikate über mehrere intermediate CAs auf das französische Innenministerium (http://googleonlinesecurity.blogspot.de/2013/12/further-improving-digital-certificate.html) oder die chinesische Internet-Behörde CNNIC zurückführen (http://googleonlinesecurity.blogspot.de/2015/03/maintaining-digital-certificate-security.html).

 

Kann irgendetwas gegen solche Angriffe getan werden? Es ist wichtig zu verstehen, dass in keinem dieser Fälle der Browser eine Fehlermeldung ausgegeben hätte, als Benutzer_in hätte man also ersteinmal keine Chance, diesen Angriff direkt zu bemerken. Dennoch würde sich der Fingerprint des SSL-Zertifikats der Website ändern (das Zertifikat samt fingerprint kann man überprüfen, indem man auf das kleine Schloss in der Adresszeile klickt). Eine Gegenmaßnahme gegen solche Angriffe wäre nun das Auswendiglernen der Fingerprints aller wichtigen Seiten . immerhin lässt sich diese Aufgabe mit einem Plugin für Firefox automatisieren: Einen gewissen Schutz gegen gefälschte Zertifikate schafft das Firefox plugin „certificate patrol“, welches immer dann Warnungen ausgibt, wenn eine bereits besuchte website ein neues Zertifikat hat (das tritt legitimerweise ca. einmal im Jahr auf). Die website des plugins ist sehr lesenswert: http://patrol.psyced.org/
ps: In all den Snowden-Veröffentlichungen wurde meines Wissens noch nie eine Folie gesichtet, die sich mit dem Knacken von SSL-Verschlüsselung beschäftigt. Vermutlich ist der Grund die hier beschriebene Problematik: Für die NSA ist es einfach trivial, sich beliebige vertrauenswürdige Zertifikate zu besorgen.
pps: Diese Problematik ist natürlich nicht auf Webbrowser beschränkt, sondern tritt auch auf, wenn man sich per SSL-gesicherter Verbindung zu einem selbst gehosteten-Mailserver verbindet. Oh je…

Eine unkommentierte, jedoch lesenswerte Sammlung von weiterführende Links zum Thema SSL-Zertifikate und was man für Unsinn damit treiben kann:
„Der Bundestag kann SSL abhören“ https://janschejbal.wordpress.com/2010/10/04/bundestag-kann-ssl-abhoren/
http://blog.fefe.de/?ts=abee1fe8
http://www.heise.de/security/meldung/Gefaelschtes-Microsoft-Zertifikat-zum-Spass-registriert-2577714.html
https://blog.hboeck.de/archives/865-Software-Privdog-worse-than-Superfish.html
http://www.zeit.de/digital/datenschutz/2015-02/superfish-lenovo-adware-hebelt-https-aus
https://netzpolitik.org/2015/it-sicherheitsrichtlinie-des-bundesinnenministeriums-keine-kettenmails-und-zentrale-verschluesselung/

Tloen Uqbar
April 12th, 2015 at 11:48 am

Und hier noch der originale Report eines Iraners, der mittels certificate pinning eine (vermutlich staatliche) Attacke auf sein gmail-Konto entdecken konnte:

https://productforums.google.com/forum/#!topic/gmail/3J3r2JqFNTw/discussion

Die Analyse bzw. Antwort von google:
http://googleonlinesecurity.blogspot.de/2011/08/update-on-attempted-man-in-middle.html

Das falsche Zertifikat stammte von diginotar, welche mittelbar vom holländischen Staat als trusted eingestuft wurde.

Tloen Uqbar
Mai 22nd, 2015 at 1:48 pm

Seit version 32 betreibt firefox sehr simples eingebautes certificate pinning (genauer gesagt CA pinning):
https://blog.mozilla.org/security/2014/09/02/public-key-pinning/

Comments are closed.

theme by teslathemes