OpenSSL soll das Internet durch Verschlüsseln sicherer machen. Durch einen jetzt bekannt gewordenen Fehler ist aber genau das Gegenteil eingetreten.

“Eine schlechte Verschlüsselung ist immer noch besser als gar keine”, lautet eine kryptologische Binsenweisheit.

Mit Recht, denn eine Karten-Geheimnummer wie “AHYY NPUG RVAF SHRAS” lässt sich zwar leicht entschlüsseln. Doch nicht jeder Kartendieb hat eine kryptologische Ader, und so wird sich ein Krimineller möglicherweise erst gar nicht mit den seltsamen Buchstaben beschäftigen.

In die gleiche Richtung geht eine derzeit von vielen Sicherheitsexperten (z. B. Bruce Schneier) geäußerte Empfehlung: Je mehr wir verschlüsseln, desto schwieriger wird es für die diversen Schnüffelorganisationen, uns zu überwachen – auch wenn nicht jede Verschlüsselung zu 100 Prozent sicher ist.

Unpassend: der Heartbleed-Bug

So gesehen ist es höchst unpassend, dass momentan eine Verschlüsselungssoftware Schlagzeilen macht, für die gilt: Auf sie zu verzichten ist sicherer, als sie zu nutzen. Das ist etwa so, als würde im Fußball ein Stürmer mehr Eigentore als richtige Tore schießen.

Die Rede ist von OpenSSL. Dabei handelt es sich um eine Open-Source-Implentierung des TLS-Protokolls (wie TLS funktioniert, steht in meinem Buch Kryptografie – Verfahren, Protokolle, Infrastrukturen). In OpenSSL wurde ein Fehler entdeckt, der als “Heartbleed-Bug” bezeichnet wird. Durch diesen Fehler gibt eine OpenSSL-Instanz Daten preis, die normalerweise weder verschlüsselt noch unverschlüsselt sichtbar sind.

Und so funktioniert’s: TLS sieht eine Funktion namens “Heartbeat” vor. Mit dieser können sich Rechner gegenseitig Leernachrichten zuschicken, um damit anzuzeigen, dass alles in Ordnung ist. Mit einer entsprechend zusammengesetzten Nachricht kann ein Angreifer eine OpenSSL-Instanz dazu veranlassen, in einer vermeintlichen Leernachricht 64 KByte aus dem Hauptspeicher zu liefern. Darin kann eine E-Mail, ein Text oder sonst etwas enthalten sein – im schlechtesten Fall auch ein geheimer Schlüssel oder ein Passwort.
Banner-Kryptografie

Schlussfolgerungen

Folgendes ist zum Heartbleed-Angriff zu sagen:

  • Das TLS-Protokoll selbst ist nicht fehlerhaft. Es wurde im Falle von OpenSSL nur falsch implementiert.
  • Die Verschlüsselung, die das TLS-Protokoll durchführt, ist vom Heartbleed-Bug nicht betroffen (abgesehen davon, dass man damit an den Schlüssel herankommen könnte).
  • Fehler wie den Heartbeat-Bug hat es schon viele gegeben. Meist waren Programme betroffen, die nichts mit Kryptografie zu tun haben. Wenn ein Speicherzugriff nicht sauber programmiert ist, dann kann dies ein Einfallstor für Hacker sein.
  • Der Heartbleed-Bug war für die OpenSSL-Entwickler leicht zu korrigieren – ein paar zusätzliche Codezeilen genügten. Die korrigierte Version ist längst verfügbar.

Fazit: Der Heartbleed-Bug hat kaum etwas mit Kryptografie zu tun und gehört daher eigentlich nicht in diesen Blog. Die Aussage “eine schlechte Verschlüsselung ist besser als gar keine” gilt nach wie vor.

Kommentare (22)

  1. #1 rolak
    10. April 2014

    korrigierte Version ist längst verfügbar

    a)
    b) betrifft SSL nur den Transportweg

    schlechte Verschlüsselung ist besser als gar keine

    Nu ja, da ‘Verschlüsselung’ typischerweise gebraucht wird im Sinne von ‘Nutzung von Programm XYZ im Vertrauen darauf, daß es ordentlich verschlüsselt” wäre in diesem Falle sogar das andere Extrem angemessen: Eine Verschlüsselung, die mehr Daten offenlegt als sie schützen soll.

  2. #2 DasKleineTeilchen
    10. April 2014

    “korrigierte Version ist längst verfügbar”.

    ja, haha. blöd nur, daß die “lücke” wohl ordentliche 2 jahre bestand, oder?

  3. #3 MartinB
    10. April 2014

    Der Artikel verwirrt mich etwas. Welche der beiden Aussagen
    “So gesehen ist es höchst unpassend, dass momentan eine Verschlüsselungssoftware Schlagzeilen macht, für die gilt: Auf sie zu verzichten ist sicherer, als sie zu nutzen.”
    und
    “Die Aussage “eine schlechte Verschlüsselung ist besser als gar keine” gilt nach wie vor.”
    ist denn nun – bezogen auf OpenSSL – richtig?

    • #4 Klaus Schmeh
      10. April 2014

      Die Aussage “eine schlechte Verschlüsselung ist besser als gar keine” ist richtig. OpenSSL mit dem Heartbleed-Bug ist eine seltene Ausnahme.

  4. #5 DasKleineTeilchen
    10. April 2014

    @Martin: bezogen auf openSSL (sofern vom hoster noch nicht auf die gefixte version umgestellt) die erste aussage, nämlich “alles scheisse, nicht benutzen”. unsere passwords müssen wir eh alle ändern. die nummer ist qua der absolute supergau (aktuell heise, älterer artikel ist ja oben im text verlinkt):

    http://www.heise.de/newsticker/meldung/Passwort-Zugriff-Heartbleed-Luecke-mit-katastrophalen-Folgen-2166861.html

  5. #6 MartinB
    10. April 2014

    @DKT
    Trotzdem halte ich die Aussage für problematisch; sie mag im Moment bei den Servern, die noch kein update haben, richtig sein – aber mehr auch nicht, oder?

  6. #7 MartinB
    10. April 2014

    PS: Und warum eine verschlüsselte, aber knackbare, Übertragung schlimmer sein soll als eine unverschlüsselte, leuchtet mir auch nicht ein – schlimmer als Daten im Klartext senden, geht doch eigentlich nicht, oder?

    • #8 Klaus Schmeh
      10. April 2014

      Doch das geht. Wenn die Software, wie in diesem Fall, vertrauliche Daten ausspuckt, die normalerweise nicht versendet werden, dann ist das noch schlechter als eine Klartextübertragung.

  7. #9 DasKleineTeilchen
    10. April 2014

    @martin: heise, zitat:

    “Grundsätzlich muss man alle vertraulichen Daten, die über die Server gelaufen sind, als kompromittiert betrachten. Ein Angreifer bekommt die sensiblen Daten dabei auf dem Silbertablett serviert, da er ausgerechnet Einblick in den Speicherbereich von OpenSSL erhält. In dem durch die Lücke abrufbaren Bereich des Speichers können sich nicht nur Klartext-Zugangsdaten befinden, sondern auch Sitzungs-IDs und sogar die privaten Schlüssel, die die Server zur Verschlüsselung des SSL-Traffic benutzen. Ein Angreifer, der in der Vergangenheit bereits verschlüsselten Datenverkehr aufgezeichnet hat, kann ihn damit nachträglich entschlüsseln (sofern der Server-Betreiber nicht Perfect Forward Secrecy aktiviert hat). “

  8. #10 Struppi
    10. April 2014

    Die Aussage beruht darauf, dass dieser Bug mehr preisgibt als eine unverschlüsselte Übertragung. Durch diesen Bug ist es möglich alle Schlüssel zu ermitteln und damit alle Nachrichten zu entschlüsseln.

    Oder wie es ein anderer Kryptexperte formuliert hat, auf einer Skala von 1 bis 10, ist dieser Bug eine 11

  9. #11 MartinB
    10. April 2014

    @Struppi
    Danke, aber warum ist es schlimmer, wenn jemand alle Schlüssel kennt und alles mitlesen kann als wenn er alles mitlesen kann, weil es unverschlüsselt ist?
    Dass der bug schlimm ist, ist ja keine Frage (auch wenn sich der Schaden – falls ihn vorher niemand anderes ausgenutzt hat – vermutlich in Grenzen halten wird, denke ich).

  10. #12 DasKleineTeilchen
    10. April 2014

    @martin: der witz ist, das ein angreifer den “geschützten” SERVER auslesen kann (oder den client, wenn sich ein exploit als SSL-server ausgibt), was mit ner unverschlüsselten verbindung so garnicht möglich ist. und der oberwitz ist, daß mit der ausnutzung dieses SSL-bugs keinerlei spuren des angriffs auf dem server/client nachweisbar sind. gar.keine.

  11. #13 MartinB
    10. April 2014

    @DKT
    Der Angreifer kann also auch die Teile vom Server auslesen, die gar nicht übertragen werden, weil er auf den Speicher zugreifen kann?
    Ja, das ist böse…

  12. #14 rolak
    10. April 2014

    Teile vom Server auslesen, die gar nicht übertragen werden

    Genau deswegen die ‘schlimmer als nix’-Formulierung, MartinB, allerdings ist DKTs Schnappatmung imho nicht angemessen. Nicht nur, daß die ergatterten Daten zufällig ausgewählt und eher schlecht zuzuordnen wären, im eher nichtkommerziellen Bereich läuft auf wesentlichen Systemen partiell gehärtete (nachgebesserte) Software augetestetster Art – aktuelles Beispiel aus der Grauzone: Debian 6 mit OpenSSL 0.9.8, nie auch nur ansatzweise involviert.

    Daß solch eine krasse Fehlprogrammierung (boundary-check ist derart neu, daß diese Technik kaum jemand kennt, geschweige denn nutzt^^) allerdings so lange unaufgespießt und quicklebendig bleibt, ist schon blamabel, ein systemischer Fehler in der Qualitätskontrolle. Open hin oder her.

  13. #15 Chemiker
    10. April 2014

    (boundary-check ist derart neu, daß diese Technik kaum jemand kennt, geschweige denn nutzt^^)

    Diese Formulierung ist ja echt pulitzer-würdig.

  14. #16 DasKleineTeilchen
    10. April 2014

    “schnappatmung”, soso. sieh mal hier rolak:

    http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-been-exploited-months-before-patch/

    der artikel wurde gerade geupdatet. “schnappatmung”, aha. die lücke gibts seit 2(!) jahren. offener quellcode. konnte jeder reinschauen. sorry, aber die bezeichnung supergau ist m.e. durchaus angemessen.

  15. #17 DasKleineTeilchen
    10. April 2014
  16. #18 Klaus Schmeh
    10. April 2014
  17. #19 DasKleineTeilchen
    11. April 2014
  18. #20 DasKleineTeilchen
    11. April 2014

    sorry meine ständige posterei, aber der hier ist wirklich perfekt:

    http://xkcd.com/1354/

    • #21 Klaus Schmeh
      11. April 2014

      Genial, besser kann man den Heartbleed-Bug nicht erklären.

  19. #22 Peter
    11. April 2014

    WOW
    Heute bin ich echt beeindruckt !
    Es ist schön zu wissen, dass wenn man ein interessantes Thema hat doch schnell eine gute Diskussion stattfinden kann, was mich persönlich immer wieder von neuem inspiriert.
    Vor allem ist hier gut zusehen, wie schnell eine Idee die andere jagt. So macht Rätseln echt spass !