Heartbleed: Passwörter ändern ist nur die halbe Wahrheit
Nachdem der OpenSSL-Bug Heartbleed die Welt erschüttert hat, haben alle ernstzunehmenden Anbieter umgehend die SSL-Zertifikate ausgetauscht. Wenige Tage später hat sich auch die Erkenntnis durchgesetzt, dass in den vergangenen zwei Jahren auf diesem Wege auch Passwörter hätten abgehört werden können -- und man liest zunehmend häufiger die Aufrufe, die Passwörter zu ändern.
Doch das ist leider nur die halbe Wahrheit -- und in Wirklichkeit schlimmstenfalls sogar nutzlos. Das Problem geht noch viel weiter -- doch merkwürdigerweise wird darüber bislang nicht geredet.
Das Problem am Heartbleed-Bug: Angreifer hätten die Private Keys des Servers auslesen können. Damit wären sie im Rahmen einer Man-in-the-middle-Attacke in der Lage gewesen, die verschlüsselte Kommunikation zu decodieren und mitzulesen -- die Inhalte der Kommunikation, aber auch Passwörter. Soweit, sogut.
Auch nach dem Key-Tausch müssen Server derzeit noch als unsicher gelten
Nur: Auch wenn jetzt überall neue Keys eingespielt worden sind, können Angreifer nach wie vor im Besitz der ursprünglichen Private Keys mitsamt der entsprechenden SSL-Zertifikate sein, die eine CA als valide unterschrieben hat. Und damit könnten sie auch jetzt noch eine Man-in-the-middle-Attacke fahren, in dem sie dem Client vortäuschen, er würde mittels SSL gesichert mit dem echten Server reden. Der Client wird sich in Sicherheit wägen, ist die Validierung durch eine CA doch erfolgt.
Um abhanden gekommene Zertifikate zurückziehen zu können, unterhalten CAs eine sogenannte "Certification Revoke List" (CRL). Browser und andere SSL-Clients sollten (sic!) empfangene Zertifikate gegen diese CRL prüfen und dort gesperrte Zertfikate nicht mehr akzeptieren.
Ein man-in-the-middle kann auch die neuen geänderten Passwörter abhören
Auch wenn Anbieter neue Keys und Zertifikate eingespielt haben, sind man-in-the-middle-Attacken weiterhin möglich, solange die CA die alten Zertifikate nicht revoked hat.
Manche CAs gehen damit sehr nachlässig um -- man kann froh sein, wenn überhaupt revoked wird.
Auf jeden Fall aber vergehen bis zum revoken der Zertifikate üblicherweise einige Tage, weil der Betreiber des Servers zunächst Zeit haben muss, die neuen Zertifikate einzuspielen.
Daraus folgt:
- Auch jetzt sind die meisten potentiell geklauten Keys und Zertifikate also noch voll gültig und werden weiterhin von den Clients akzeptiert. Es wäre nötig und spannend zu beobachten, wann welche Zertifikate revoked werden -- und ob die Clients überhaupt gegen eine CRL prüfen, oder die revokten Zertifikate nicht stillschweigend die nächsten Jahre weiterhin akzeptieren.
- Auch wer jetzt sein Passwort ändert, muss weiterhin davon ausgehen, dass seine Verbindung derzeit noch genauso unsicher und durch einen man-in-the-middle abhörbar ist, wie vor dem weltweiten Zertifikatstausch. Auch jetzt können Verbindungen (mitsamt dem neuen geänderten Passwort) noch abgehört werden.
Betreiber müssen sicherstellen, dass die CA die alten Zertifikate zeitnah revoked!
Auf der wirklich sicheren Seite ist also nur, wer nach erfolgter Sperrung des alten Anbieter-Zertifikats auf der CRL (erneut) sein Passwort ändert. Dann -- und nur dann -- ist die SSL-Verbindung zum Server wieder grundsätzlich abhörsicher.
Vorausgesetzt jedoch, der eigene Client prüft überhaupt gegen die CRLs der Anbieter... Mir fehlt derzeit die Zeit zur Recherche, aber es wäre mehr als nur spannend zu wissen, welche Anwendungen CRLs prüfen, und welche nicht. Vor allem aber ist auch zu unterscheiden, welche CRLs die jeweiligen Programme bereits kennen -- und wo CRLs manuell aktiviert oder konfiguriert werden müssen. So veröffentlicht die Uni Trier eine Anleitung, um die CRL des DFN für Firefox/Thunderbird zu aktivieren. Im Umkehrschluß heißt das: Wer das nicht macht, wird noch auf Jahre hinweg geklauten DFN-Zertifikaten blind vertrauen.
Die Sicherheit nach dem Heartbleed-Bug ist nicht wiederhergestellt. Wer sich derzeit in Sicherheit wiegt, hat die wahre Dimension des Problems noch nicht verstanden. Die Auswirkungen werden noch auf Jahre hinweg zu spüren sein -- bis das letzte potentiell betroffene Zertifikat durch Zeitablauf erledigt ist.
Kommentare
9 Antworten zu Heartbleed: Passwörter ändern ist nur die halbe Wahrheit
Und nicht vergessen das die Anwender seit Jahren darauf trainiert sind <b>“Trotzdem akzeptieren”</b> zu klicken.
Ein echter Super-GAU (d.H. noch größer als der größte anzunehmende Unfall)
Das nächste mal wenn mit C Programmierer mit “Echte Programmierer wissen was sie tun” kommt antworte ich nur #gotofail und #heartbleed
Beim Firefox kann unter
"Bearbeiten > Einstellungen > Erweitert > Zertifikate > Validierung"
die Option
"OCSP verwenden um die Gültigkeit von Zertifikaten zu bestätigen"
aktiviert werden.
Google Chrome bietet unter
"Einstellungen > Erweiterte Einstellungen anzeigen > HTTPS/SSL"
die Option "Serverzertifikate auf Sperrung prüfen".
Weitere Info:
https://de.wikipedia.org/wiki/Zertifikatsperrliste
https://de.wikipedia.org/wiki/Online_Certificate_Status_Protocol
https://en.wikipedia.org/wiki/OCSP_stapling
http://www.guntiahoster.de/blog/2013/allgemein/ocsp-stapling-browser-un…
http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation…
http://www.heise.de/security/news/foren/S-Hilft-das-Sperren-der-alten-Z…
http://security.stackexchange.com/questions/55457/how-to-configure-brow…
Das mit Firefox stimmt so nicht ganz:
CRLs kann man im aktuellen Firefox nicht mehr importieren. Statt dessen ist standardmäßig OCSP aktiv. Dies funktioniert für vom DFN ausgestellte Zertifikate (Universitäten, Hochschulen).
...und z.B. auch für Zertifikate des im "Umfeld der operativen Hektik beim Tausch der Schlüssel" vielgescholtenen Anbieters StartSSL.
Wer hat eigentlich die Mär von den Server-Keys in den Raum geworfen?
Ausser der Aussage "we were able steal from ourselves the secret keys used for our X.509 certificates" auf Heartbleed.com habe ich keine Hinweise
BTW: Wer Zugriff auf eine CA hat konnte auch vorher schon ohne Heartbleed MITM, und wird dies auch weiterhin noch tun können (read: Agencies).
M.E. sollte nicht noch mehr Öl ins Feuer der Halbwahrheiten & Hysteria gegossen werden, das macht Heise (das neue ComputerBild) schon zu Genüge
Tja, im *aktuellen* Firefox. Es ist ja immer schön, daß die aktuellsten der aktuellsten Programme irgendwas toll und richtig machen. Die Praxis zeigt aber, dass viele mit veralteten Versionen unterwegs sind. Und damit bleibt das Problem bestehen.
Dieser Artikel lässt mich ein wenig die Stirn runzeln. Ausgerechnet CRLs sollen ein wichtiger Schritt auf dem Weg zurück zur sicheren Kommunikation sein?
Oben steht: "Ein man-in-the-middle kann auch die neuen geänderten Passwörter abhören". Richtig, und was ein Man-in-the-middle vor allem ebenfalls kann ist die Verbindung zum CRL- und OCSP-Server unterbinden. Das ist der mit Abstand leichteste Teil der Übung, und damit sind CRL und OCSP zu 100% aus dem Rennen.
(Außer natürlich der Client würde auf einer Verifizierung per CRL oder OCSP <b>bestehen</b>. Aber jeder Browserhersteller hat in der Vergangenheit die Erfahrung machen müssen, dass dies zwar ein löbliches, aber hoffnungsloses Unterfangen ist, da es in der Praxis zu unbegrenzt vielen Fehlalarmen führt und man seinen Nutzern keinen sinnvollen Ratschlag geben kann, wie sie sich denn in all diesen Fällen verhalten sollten.)
Mal abgesehen davon ist OCSP aus Datenschutzsicht ein Alptraum und CRLs versagen alleine schon aufgrund ihrer mangelnden Skalierbarkeit.
Daher meine Empfehlung: Heartbleed-Lücke schließen: Letzte Woche!
Zertifikat austauschen bzw Passwörter ändern: So schnell wie möglich!
Altes Zertifikat zurückziehen: Irgendwann wenn man Zeit hat. Hat in der Theorie seine Berechtigung, bringt in der Praxis aber keine erhöhte Sicherheit bei Angriffen.
Hi!
Ich bin auch gespannt was es noch für Nachrichten in den nächsten Tagen zu diesem Thema gibt. Aber es wird wie immer sein: nach 2-3 Wochen spricht niemand mehr darüber... und der Normal-User ist mal wieder bestätigt: "Es hilft alles nichts, also wieso verschlüsseln? Wieso Datenschutz? Wieso..."
MfG
Max
@Markus
das ist keine Behauptung, dass man die Keys auslesen kann/konnte, das ist Fakt. Das wurde demonstriert ( http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge ) und die dafür nötigen Tools kursieren öffentlich.