News Schwere Sicherheitslücke im TLS-Protokoll von OpenSSL

[Nilson]

Jo, du hast kein Weg dich zu schützen, außer das PW zu ändern, aber das bringt auch nur was, wenn die ihre Server upgedatet haben. Das bringt aber nur was für die Zukunft. Was bisher mitgeschnitten wurde kann man dann immer noch entschlüsseln, da leider viele keine Maßnahmen für den Fall, dass der Key bekannt wird, treffen. Heißt, es wurde nicht so verschlüsselt das der Key mit der Zeit ungültig wird.

 

[luky37]

Als User kann man nicht das geringste machen und es gibt keine Möglichkeit, sich zu schützen. Entweder ihr ignoriert das, oder ihr stellt eure Onlineaktivität ein, bis alle Zertifikate abgelaufen sind.

 

[Daaron]

Pft... ich hab heut wie ne gute halbe Stunde vorm Code gesessen wie ne Kuh wenns blitzt und mich gewundert, warum mein

if($(selector).lenght ==0) {}

nicht zündet... Wie oft muss man "length" eigentlich geschrieben haben bis einem auffällt, dass man gefälligst "t" vor "h" zu schreiben hat?
Ne, niemand ist gefeit vor total blödsinnigen Fehlern. Das fängt mit einfachen Tipfehlern an und endet noch lange nicht mit "na zu dem Zeitpunkt schien es ne gute Idee zu sein".

Was heisst das für mich als Nutzer von Onlinekaufhäusern, sowie bank und foren? Sensible Daten sind ja nur bei den ersten beiden genannten abzugreifen. Aber dh man kann sich momentan nicht schützen?

Schützen ist relativ.
Du kannst (und solltest) bei Stellen, wo es wirklich um sensible Daten geht, 2 Schritte durchführen, bevor du dem Server vertraust.
1.) Nimm einen Verwundbarkeitstester. Schlägt er an... nix guter Server
2.) Schau dir das Zertifikat genau an.
Ist der Server nicht verwundbar und das Zertifikat brand neu (also diese Woche), dann ist alles gut. Ist das Zertifikat schon älter, könnte es kompromittiert sein.

Außerdem kannst du versuchen herauszufinden, welches Betriebssystem hinter dem Server steckt. Debian 6 wäre z.B. nicht verwundbar. Ich bezweifle, dass Windows auf OpenSSL setzt, also wäre eine Webseite, die auf MS IIS läuft, ebenfalls nicht betroffen.
Schwierig wird es, an diese Informationen zu kommen, zumindest als Laie. Das Plugin Chrome Sniffer verrät aber bereits eine Menge.

 

[DerToast]

Mal ne Laienfrage: seh ich das richtig, dass wenn z.B. der Trafic eines Mailanbieters mitgeschrieben wurde und über den Bug dessen Key ausgelesen wurde, dann kann ein Angreifer jetzt gemütlich mein aktuelles Mail-Passwort entschlüsseln (da er den Trafic hat und den damals genutzten Key)
Der Grund für meien Frage ist, dass man oft liest, dass alle Passwörter im Netz geändert werden sollten, meine Bank hat mir aber mitgeteilt, dass sie dass ganze offenbar so handhaben, dass ein Passwortwechsel bei ihnen nicht nötig ist.

Grüsse

 

[Helmpflicht]

Ich weiß nicht. Ein großflächiger Passwortwechsel ist wohl auch erst sinnvoll, wenn wirklich alle Server gepatcht und alle Zertifikate neu sind. Sonst geht das Spiel ja wieder von Vorn los.

Ich warte einfach mal darauf, was die seriösen Anbieter machen. Denn diese setzten ja häufig die Passwörter selbst zurück, wenn die Gefahr besteht, dass sie kompromittiert wurden.

 

[Daaron]

... jetzt gemütlich mein aktuelles Mail-Passwort entschlüsseln (da er den Trafic hat und den damals genutzten Key)

Nicht zwingend. Wenn PFS (Perfect Forward Secrecy) implementiert wurde ist es nicht möglich, rückwirkend Verbindungen zu entschlüsseln. Die Betonung liegt auf rückwirkend.

...meine Bank hat mir aber mitgeteilt, dass sie dass ganze offenbar so handhaben, dass ein Passwortwechsel bei ihnen nicht nötig ist.

Deine Bank wird schlichtweg nicht auf OpenSSL zurückgreifen. Kein OpenSSL (oder altes) -> kein Heartbleed-Bug -> kein Problem

Ich warte einfach mal darauf, was die seriösen Anbieter machen. Denn diese setzten ja häufig die Passwörter selbst zurück, wenn die Gefahr besteht, dass sie kompromittiert wurden.

Wer ist schon "seriös"?
Bei wem ich mir vorstellen könnte, dass es zu keinen PRoblemen kam: Google & Microsoft.
- Microsoft setzt im Zweifel auf Closed Source Software als SSL-Dienst.
- Google setzt zumidnest in Chrome (noch) auf NSS statt OpenSSL, wenn die insgesamt einheitlich arbeiten, dann laufen auch die GMail-Server wohl auch nicht mit OpenSSL

Das Problem waren noch nie die großen Anbieter, sondern kleine Webseiten, wo du Mail+Passwort als Login verwendest.

 

[PhilS1984]

Danke. Dh erstmal abwarten.

 

[Daaron]

Ist wie mit dem Yellowstone-Ausbruch, nem Meteoriteneinschlag, nem Gamma Ray Burst,... Du kannst nix machen, also amch dich nicht verrückt deswegen. Im Zweifel rammt dich morgen eh ein besoffener LKW-Fahrer....

 

[PhilS1984]

Danke. Dh erstmal abwarten. Müsste man nicht dennoch im Zweifel von den Websites eine mail bekommen wenn es den Grund zur Annahme gäbe Daten seien gestohlen worden? Zb Amazon oder so?

 

[Jesterfox]

Btw welcher Browser nutzt denn überhaupt OpenSSL? IE und Chrome ja auch nicht, und mir dünkt, dass Apple bei Safari auch eigene Wege geht...

Soweit ich mitbekommen hab hat wohl nur Opera OpenSSL verwendet. Und damit: RIP Opera 12 :-(

 

[abulafia]

Wäre das nicht Open Source, könnte man jetzt wenigstens der NSA die Schuld geben.

Ist das jetzt der Todesstoß für das Argument, Open Source hätte einen Sicherheitsvorteil?

 

[Creeed]

Nein, eher das Gegenteil. Denn wäre es Closed Source gewesen hätte man den Fehler nicht so einfach finden können. Dann hätte man die Binaries per Reverse Engeneering auseinander dröseln müssen.

 

[zuo]

grad so nebenbei gesehen.

Dieser OpenSSL Fehler ist bei freenode seit 8 Monaten bekannt.

https://dev.freenode.net/redmine/issues/34

https://github.com/atheme/charybdis/commit/97b0e99e2a46012d7f8cafe6591c137af4dc3fca


ob es auch der hier genannt Fehler kann ich nicht sagen

 

[Yuuri]

Denn wäre es Closed Source gewesen hätte man den Fehler nicht so einfach finden können.

Wer ist "man"? Jeder spricht von "man". Bei diesem Bug hat es nun knapp zwei Jahre (wenn der Bug mit 1.0.1 kam) niemanden gegeben, der es entdeckt hat, obwohl "man" es hätte können. Das heißt doch nur, dass OSS vom Prinzip her toll ist, aber keiner Lust hat, über den Code zu sehen, wie es manche hier immer darstellen. Bei Closed Source wäre es vielleicht nie aufgefallen. Bei Closed Source, wäre die Lücke vielleicht einfach gefixt worden. Bei Closed Source hätte es schon einen Nachfolgecode geben können. Hätte, hätte, Herrentoilette, ...

Diese Situation zeigt nur: Es gab einen extrem tiefgreifenden Bug, der knappe zwei Jahre existiert hat, obwohl "man" ihn doch hätte finden können. Keiner tat es bislang. Hier muss man keine OSS <-> CSS Debatte führen, hier geht es alleinig um "OSS ist so viel sicherer, da man ja drüber schauen kann". "Man" ist aber wahrscheinlich niemand oder "man" ist immer nur "jemand" alle paar Jahre.

 

[Daaron]

Müsste man nicht dennoch im Zweifel von den Websites eine mail bekommen wenn es den Grund zur Annahme gäbe Daten seien gestohlen worden? Zb Amazon oder so?

Nein, warum? Was wäre gewonnen? Das löst wahlweise ein Schulterzucken beim User oder aber ne Panik-Stampede aus. Beides ändert genau gar nichts.

Ist das jetzt der Todesstoß für das Argument, Open Source hätte einen Sicherheitsvorteil?

Kein Todesurteil, aber eben etwas problematisch.
FOSS gibt Entwicklern halt das Werkzeug in die Hand, über den Code mal selbst nachzudenken. Bei Closed Source ist es friss-oder-stirb. Wenn diese Eigenverantwortung sowohl der Entwickler als auch der User nicht genutzt wird, wer ist dann schuld?

Wenn Microsoft ne kritische Lücke in ner Windows-Komponente verbocken, dann kannst du eindeutig mit dem Finger zeigen. Ob das nun besser ist oder schlechter.. Dafür hast du da keinen Einfluss auf das Schließen der Lücke.

 

[Creeed]

@Yuuri
Es gilt immer es ist Team Arbeit einen Code zu reviewen, was für ein Deutsch. Also "Toll Ein Anderer Machts". Es ist ja nicht so als ob der Bug erst letzte Woche gefunden wurde, wie zuo ja passend schreibt sind schon ein paar Fähnchen wedelnd durch die Gegend gehüpft um darauf aufmerksam zu machen. Hat nur keinen Interessiert. Erst jetzt wo man den Kram automatisch aktiviert hat ging wohl einigen der Sack gehörig auf Grundeis oder irgendwer hat nochmal ins Physikbuch gesehen und hat festgestellt das Kernkraftwerke doch explodieren können.

Wenn sich keiner für den Code interessiert ist es egal ob OSS oder CSS. C als Programmiersprache ist sowieso eine Zumutung um sichere Software zu schreiben. Wenn man sieht was so mancher da zusammen knaupt kann man eigentlich nur noch schreiend aus dem Fenster springen. OSS hat in diesem Moment nur den Vorteil dass man den Fehler erkennt und es öffentlich ist. Wäre der gleiche Fehler im SChannel aufgetreten hätte man sich von Herstellerseite wahrscheinlich bedeckt gehalten und den Fehler eventuell in 5-10 Jahren gefixt.

 

[PhilS1984]

Nein, warum? Was wäre gewonnen? Das löst wahlweise ein Schulterzucken beim User oder aber ne Panik-Stampede aus. Beides ändert genau gar nichts.

Na ja, ich dachte es wäre so wie wenn zb Steam oder Uplay gehackt werden, da habe ich auch schonmal ne Mail bekommen, dass ich mein Passwort ändern muss.
Dachte an so eine Email

habe mal das tool aus dem ersten post genutzt:

Folgendes kam dabei rum:

Looking for TLS extensions on [url]https://www.forumla.de[/url]

ext 65281 (renegotiation info, length=1)
ext 00011 (EC point formats, length=4)
ext 00035 (session ticket, length=0)
ext 00015 (heartbeat, length=1) <-- Your server supports heartbeat. Bug is possible when linking against OpenSSL 1.0.1f or older. Let me check.
Actively checking if CVE-2014-0160 works: Your server appears to be patched against this bug.

Checking your certificate
Certificate is valid before 0day. <-- Your stuff may be compromised. Consider changing the certificate and passwords.

was genau bedeute das? also übersetzen kann ich das auch aber bedeutet es wirklich, das jemand meine login daten dort abgefangen haben könnte?

Danke Jungs


PS: Das Gleiche kommt übrigens auch bei www.google.dem bei www.instagram.com, bei www.foursquare.com

 

[Daaron]

Wenn das Zertifikat älter ist als der Patch (0day heißt hier: bekannt werden der Zero-Day-Lücke), dann kann ein Angreifer eben bereits den PRivate Key haben und somit alle Kommunikation entschlüsseln.
Erst wenn das alte Cert zurückgerufen und ein neues ausgestellt wurde (und vorher die Lücke geschlossen wurde), erst dann ist die Kommunikation wieder sicher.

 

[MountWalker]

... C als Programmiersprache ist sowieso eine Zumutung um sichere Software zu schreiben. ...

Ja, aber die TLS-Implementationen sind doch im Moment alle in C geschrieben, mit Ausnahme von JSSE, und alles andere als C ist doch "uncool", weil man mit Kenntnissen in Java und Python nicht so gut angeben kann...

 

[PhilS1984]

Wenn das Zertifikat älter ist als der Patch (0day heißt hier: bekannt werden der Zero-Day-Lücke), dann kann ein Angreifer eben bereits den PRivate Key haben und somit alle Kommunikation entschlüsseln.
Erst wenn das alte Cert zurückgerufen und ein neues ausgestellt wurde (und vorher die Lücke geschlossen wurde), erst dann ist die Kommunikation wieder sicher.

DH es macht kein Sinn das Passwort zu ändern?

bei www.pinterest.com kommt folgendes

Looking for TLS extensions on https://www.pinterest.com

ext 65281 (renegotiation info, length=1)
ext 00035 (session ticket, length=0)
ext 00015 (heartbeat, length=1) <-- Your server supports heartbeat. Bug is possible when linking against OpenSSL 1.0.1f or older. Let me check.
Actively checking if CVE-2014-0160 works: Your server appears to be patched against this bug.

Checking your certificate
Certificate has been reissued since the 0day. Good. <-- Have you changed the passwords?