#!/bin/blog

April 26, 2014

Microsoft und Oracle könnten wir für sowas wie Heartbleed in Regress nehmen

Filed under: Open Source — Tags: , , , , , — martin @ 3:36 pm

heartbleedEin Satz, gesprochen von einem Kunden, der es besser wissen müsste, als das Heartbleed-Debakel bereits seinen Höhepunkt überschritten hatte:

“Microsoft und Oracle könnten wir für sowas wie Heartbleed in Regress nehmen.”

Obwohl der Ausspruch sich für jeden mit mehr als 4 Wochen Erfahrung in der EDV schon von selbst ins richtige Licht setzt, habe ich heute Zeit, etwas darüber zu schreiben.

Warum kann man ein Open-Source-Projekt wie OpenSSL nicht haftbar machen für schwerwiegende Fehler, die für erheblichen personellen Aufwand und Vertrauensverlust bei den Kunden sorgen?

Na, das weiß doch jeder. Das ist ganz einfach nachzulesen in der Lizenz, wie bei jedem Open-Source-Projekt. OpenSSL steht unter der OpenSSL-Lizenz. Dort heißt es:

openssl

Das wäre also erwartungsgemäß geklärt. Jede Gewährleistung wird ausgeschlossen. Ihr kennt das. So ist das eben bei Frickelsoftware von unbezahlten Bastlern aus dem Hobbykeller.

Mit vernünftiger kommerzieller Software müsste man sich sowas nicht antun. Oder vielleicht doch?

RedHat

Bevor wir zu Microsoft und Oracle gehen, schauen wir mal nach dem Linux-Distributor, über den mein Kunde sein OpenSSL-Paket installiert hatte. RedHat hat ein “Enterprise Agreement” oder zu deutsch “Geschäftskundenvertrag”:

redhat

In Punkt 8.1 wird dort die Haftungsobergrenze zunächst auf 45000 Euro festgelegt. In den folgenden Punkten wird dann festgelegt, dass RedHat außer bei Vorsatz für keinerlei Schäden haften wird. Gefolgt wird das ganze vom gezeigten Punkt 10.2, in dem jegliche Gewährleistung ausdrücklich ausgeschlossen wird.

Microsoft

Weiter zu Microsoft. Hier habe ich mir die Lizenbestimmungen für Windows 2012 Server in der “Datacenter Edition” angeschaut:

microsoft

Ähnlich wie Redhat setzt Microsoft in Punkt 23 eine Haftungsobergrenze. Diese erstreckt sich maximal auf den Betrag, der für die Software bezahlt wurde. Eine weitere Haftung für Schäden jeder Art wird ausgeschlossen. In den folgenden Garantiebestimmungen wird zugesichert, dass die Software im wesentlichen wie beschrieben funktionieren und bei Bedarf kostenlos nachgebessert werden wird. Für den Fall, dass sie nicht nachgebessert werden kann, wird die Rückgabe des Kaufpreises zugesagt, selbstverständlich nicht ohne die Bedingung, dass die Software in diesem Fall deinstalliert werden muss. “Dies sind Ihre einzigen Ansprüche.” Es gibt also de-facto überhaupt keine Ansprüche.

Oracle

Für Java gilt das “Oracle Binary Code License Agreement for the Java SE Platform Products and JavaFX”:

oraclejava

Oracle gibt in Punkt 4, ähnlich wie das die meisten Open-Source-Lizenzen tun, überhaupt keine Garantie für Java und setzt in Punkt 5 pro forma eine Haftungsobergrenze von 1000 US-Dollar und schließt vor allem jegliche Haftung aus.

Egal, wieviel gutes man über Oracle sagen will oder nicht, zumindest sind sie hier so nah an den Open-Source-Lizenzen dran, dass ihre Formulierungen klar auf den Punkt kommen.

Fazit

Wir sehen, dass nicht nur lächerlich geringe Haftungshöchstgrenzen zum Geschäft gehören, sondern dass selbstverständlich jede Gewährleistung grundsätzlich ausgeschlossen wird. Das hier ist kein Märchen von Fanatikern aus der Open-Source-Szene, sondern die simple Wahrheit, die jeder einfach selbst nachlesen kann.

Advertisements

April 14, 2014

Die Täuschung

Filed under: Open Source, Paranoia, Sicherheit — Tags: , — martin @ 7:15 am

heartbleedDer Begriff “Perfect Forward Secrecy” ist in dieser Zeit enorm populär. Ohne geht es einfach nicht mehr. Perfect. Perfektion. In Teilbereichen der Informationsverarbeitung ist Perfektion möglich. “Höchste Vollendung in der technischen Beherrschung und Ausführung von etwas. Vollkommene Meisterschaft.” (Duden)

Es scheint, als hätte es einen ähnlich absoluten Begriff wie “Wired Equivalent Privacy” nie gegeben. Es ist 2014 und Perfektion in Algorithmen und Software ist möglich.

Mitten in dieses Idyll platzt ein profaner und in wenigen dürren Worten beschreibbarer Bug in OpenSSL, bei dem ein paar Kilobyte aus dem Speicher des Webservers abgegriffen werden können. Das bedeutet: Updates installieren, SSL-Zertifikate tauschen, Kunden auffordern, ihre Passwörter zu ändern. Unangenehmes Zeugs.

Aber mit welcher Wahrnehmung. Der Super-GAU (noch dazu der “erste des Internets”) ist da. Der Horror-Bug. Die 11 auf einer Skala von 10. Und dabei ist es doch nur ein Bug, ein Implementierungsfehler, den ein normaler Mensch an einem normalen Tag in den Sand gesetzt hat.

Wer wirklich geglaubt hat, dass es Perfektion geben kann, dass in Sicherheit und Software so etwas wie Vollkommenheit existieren kann und dass man existenzielle Dinge von Perfektion in äußerst komplexer Software wie OpenSSL abhängig machen darf, sollte sich glücklich schätzen, wenn er rechtzeitig durch Heartbleed schonend auf den Boden der Tatsachen zurückgeholt wurde, ohne dass jemand an Leib und Leben Schaden genommen hat.

Macht weiter. Bleibt so sicher, wie ihr es im Hier und Jetzt könnt. Fallt nicht auf falsche Versprechungen rein. Lasst die Finger von der verdammten Hybris.

Alles ist nicht nur genauso in Ordnung, wie vor dem 7. April 2014, sondern sogar besser.

July 10, 2008

Verisign und OCSP

Filed under: Security — Tags: , , , , — martin @ 9:36 pm

Was mir heute nicht so gut in den Kram gepaßt hat:

$KUNDE warf mir nochmal 50 SSL-Zertifikate vor die Füße, zwecks Überprüfung, von denen 38 für das Debian-SSL-Problem empfänglich waren. Aber ich hab ja mittlerweile Routine.

Also wurden neue CSRs generiert, welche er bei Verisign (RSA/”Secure Server Certification Authority”) zum Re-Issue eingereicht hat. Minuten später kam der erste mit einer Firefox-Fehlermeldung um die Ecke:

Die verantwortliche Konfigurationsoption war dann auch schnell identifiziert:

Willkommen im Dilemma. So schwer es mir fällt, zu bestreiten, daß diese Voreinstellung in Firefox 3.0 auf den Tag genau zur rechten Zeit kommt, so unangebracht finde ich es, daß Verisign ein Zertifikat, dessen Austausch es gerade mal so mit Ach und Krach in die Mailbox der Administratoren geschafft hat, sofort per OCSP als gesperrt propagiert.

Gerade weil es jetzt so weit ist, daß OCSP, das Online Certificate Status Protokoll, tatsächlich genutzt wird, wäre eine gewisse Galgenfrist von mindestens 1 Tag bis vielleicht 1 Woche mehr als angemessen. Insbesondere bei einer Massenaktion mit einem Umfang von mehreren Dutzend Zertifikaten ist mir persönlich nämlich schleierhaft, wie man die Zertifikate im Rahmen von Change-Prozessen derart schnell auf die Produktivserver katapultieren soll.

Wenn man nochmal 30 Sekunden drüber nachdenkt, kommt man übrigens zur Erkenntnis, daß es auch mit einem einzigen Zertifikat kaum sauber hinzubekommen ist. Auf einer hochgradig produktiven SSL-Site muß man, wenn die CA einen OCSP Distribution Point bereitstellt, in Zukunft auf den Re-Issue verzichten und additiv ein neues Zertifikat dazukaufen, um es überhaupt ohne Ausfall tauschen zu können. Ob das wirklich im Sinne des Erfinders ist?

June 21, 2008

Surfin’ the post 5/13 world.

Filed under: Security — Tags: , , , — martin @ 11:27 pm

Das audit-ssl-Script (.tar.gz) ist funktional in der Lage, Seiten mit angreifbaren SSL-Zertifikaten zu erkennen. Komfortabler und plattformübergreifend tut es aber die SSL Blacklist Extension für den Firefox:

Auch zu empfehlen als kleiner Warnschuß an Anwender, die sich weigern, Zertifikate auszutauschen: “Firefox zeigt bereits eine Warnmeldung an. Was wirst Du Deinen Kunden erzählen, wenn der Internet Explorer das nach dem nächsten Microsoft-Patchday ebenfalls macht?”

June 4, 2008

OpenSSL: Key, CSR und Zertifikat auf Übereinstimmung prüfen

Filed under: Security — Tags: , — martin @ 6:17 pm

Der 13. Mai hat mein ohnehin schon verpfuschtes Leben in eine verdammte Hölle aus Zertifikaten, Keys und Certificate Signing Requests verwandelt. Und dann heute mal was neues: Beim Kunden wollte ein Webserver mit einem der von der CA neu ausgestellten Zertifikate nicht mehr starten. Key und Zertifikat paßten nicht zusammen.

Wie man ermitteln kann, ob ein Zertifikat zum CSR paßt, klingt z.B. hier oder in der Apache-FAQ an:

# openssl x509 -in example.com-cert.pem -noout -modulus | openssl sha1
5ba93c9db0cff93f52b521d7420e43f6eda2784f
# openssl req -in example.com-req.pem -noout -modulus | openssl sha1
5ba93c9db0cff93f52b521d7420e43f6eda2784f

So ließ sich dann recht einfach ermitteln, daß die CA tatsächlich nicht den neuen, sondern einen dort gespeicherten alten Certificate Signing Request für die Neuausstellung des Zertifikats benutzt hatte. Worauf dann unmittelbar die Frage folgte, ob davon vielleicht auch noch andere der 50 neu ausgestellten Zertifikate betroffen sein könnten.

Also mußte ein Script her, das weniger sperrig war als die o.g. OpenSSL-Aufrufe, und dem man vorzugsweise nicht sagen muß, um was es sich bei der jeweils präsentierten Datei handelt:

#!/bin/sh
# Script: ssl_matchchk
for i in "$@"
do
  openssl x509 -in $i -noout >/dev/null 2>&1 && 
    echo `openssl x509 -in $i -modulus -noout 2>/dev/null | openssl sha1` $i
  openssl req  -in $i -noout >/dev/null 2>&1 && 
    echo `openssl req  -in $i -modulus -noout 2>/dev/null | openssl sha1` $i
  openssl rsa  -in $i -noout >/dev/null 2>&1 && 
    echo `openssl rsa  -in $i -modulus -noout 2>/dev/null | openssl sha1` $i
done

Mit diesem Script, dem es zugegebenermaßen an einer sauberen Fehlerbehandlung fehlt, und mit einem kleinen weiteren Shell-Einzeiler ließ sich dann relativ flott sicherstellen, daß nur ein einziges Zertifikat von einer solchen Verwechslung betroffen war. Schwein gehabt. 😉

Blog at WordPress.com.