Heartbleed und Open Source

Jetzt, wo so langsam das ganze Ausmaß der OpenSSL-Sicherheitslücke bekannt wird, stellt sich unter anderem auch die Frage, in welchem Licht das die Grundidee der Quelloffenheit von Programmcode erscheinen lässt. Da wir in der Vergangenheit größtenteils mit OpenSource-Software – allen voran Magento, OXID eShop und Shopware in den jeweiligen Versionen – gearbeitet haben und Unternehmen immer zu einer Open-Source-Strategie raten würden, müssen wir uns jetzt fragen: Ist die Party damit vorbei?

Absolut nicht. Natürlich ist die Sicherheitslücke ein Problem von besonderer Tragweite und man muss sich die Frage stellen, warum ein eigentlich trivialer Programmierfehler über solch einen langen Zeitraum nicht bemerkt wurde. Ist nicht das durch die Quelloffenheit erst mögliche Mehr-Augen-Prinzip und die damit verbundene Transparenz das entscheidende Argument für Freie Software?

Nach Bekanntwerden der Lücke wurde schnell ein Patch veröffentlicht und Unternehmen haben schnell reagiert. Die Hosting-Provider beispielsweise, mit denen wir im E-Commerce-Umfeld zusammenarbeiten, konnten innerhalb von Stunden das Problem lösen und ihre Kunden entsprechend informieren. Zwar ist noch nicht absehbar, welche wirtschaftlichen Folgen der Heartbleed-Bug haben wird, doch der Umgang mit der Thematik trennt unserer Einschätzung nach Dienstleister-Spreu vom -Weizen und lässt erkennen, wie ernsthaft das Thema Sicherheit im Einzelfall vorangetrieben wird.

An dieser Stelle lohnt sich ein Gedankenexperiment: Was wäre, wenn es sich bei OpenSSL um eine proprietäre Lösung handelte? Fühlten wir uns dann als private und geschäftliche Nutzer des Internet sicherer bei dem Gedanken, dass die Qualität einer weltweit eingesetzten Verschlüsselungstechnologie in den Händen eines (möglicherweise) einzigen Unternehmens läge? Einem Unternehmen, dass die Entscheidung zur Bekanntmachung einer derartigen Sicherheitslücke seinem wirtschaftlichen Kalkül unterwirft bzw. unterwerfen muss?

Die Diskussion sei hiermit eröffnet. Vielleicht möchte auch Zoman Renner einen Kommentar dazu abgeben?

(Bild von philmikejones)

2 Gedanken zu „Heartbleed und Open Source

  1. Pingback: This Week in Shop Tech -

  2. Danny Althoff

    Ansich ist das Ausmaß, welches diese Fragestellung offenlegt, nicht auf den ersten Blick so klar (und leider auch erschreckend), doch seien wir mal ehrlich:
    Wie handhaben wir es selber als Entwickler und diejenigen, die nach kostengünstigen/kostenlosen Alternativen schauen und oftmals dafür auf OpenSource-Software zurückgreifen?

    Genau, garnicht! Wir sind froh, wenn wir etwas kostenloses bekommen, was gut dokumentiert ist, oder was uns die Arbeit möglichst erleichtert, ABER wer schaut sich schon den Quellcode an? Mir fällt nur eine Hand von Szenarien ein, wo wir WIRKLICH man den Quellcode anschauen:
    1. Wir müssen für die jeweilige etwas entwickeln, weil die Anforderungen der Kunden darauf angewendet werden sollen
    2. Etwas funktioniert nicht, wie es soll, also suchen wir nach dem Fehler (natürlich zuerst in unserer Applikation und erst danach in die Hersteller-Software, und hoffen wir mal, dass der Hersteller einen BugTracker anbietet, damit man solche Funde posten kann)
    3. Security-Audits
    4. (und das ist seltener der Fall) um etwas zu lernen

    Ansich hört man oftmals „OpenSource sei sicherer, da es von allen eingesehen wird und somit auf Sicherheit geprüft wird“, doch leider ist bei weitem nicht jeder in Punkto Sicherheit geschweige denn in Kristallkugel-Sehen geschult.
    Doch ich muss auch sagen, dass ich mich nicht sicherer fühle mit ClosedSource-Software! Ich kann weder etwas einsehen, noch wirklich nachvollziehen.

    Nehmen wir doch mal einen der aktuellen Fälle außerhalb von openSSL: TrueCrypt! Hier ist OpenSource, welches nun auch einen offiziellen (ersten) Audit hinter sich hat, viele verwenden es und können jetzt erst recht sich sicherer fühlen, schon alleine weil hier gezielt auf Sicherheit geprüft worden ist. So, und jetzt zeig mir mal jemand wirklich gute Beispiele für ClosedSource-Software, bei der dies unabhängig möglich ist.

    Was aber auch sehr oft vergessen wird: OpenSource heißt nicht automatisch Lizenzfrei, genau das ist leider oftmals auch ein Garant dafür, dass ein Projekt garnicht erst entsteht, da es sich beißt.

    Naja, irgendwie ist jeder Vorteil auch ein Nachteil.

    P.S.: „Security by Obfruscation“ ist kein gültiges Argument 😉 auch wenn der ein oder andere Quellcode einen daran erinnern mag

    Gefällt mir

    Antwort

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s