Amazons s2n wichtiger Beitrag zur Online-Sicherheit

Defizite in einigen Details sollten aber überdacht werden.

»Amazons Ankündigung zu s2n (»Signal to Noise«) ist eine ziemlich aufregende Neuigkeit. Es ist fast immer eine gute Sache, wenn ein großes Internetunternehmen wie Amazon bei der Verbesserung zentraler Internettechnologie wie Transport Layer Security (TLS) nach dem Open-Source-Prinzip vorgeht. Nach Heartbleed sahen wir ähnliches von Google mit dem Release von BoringSSL, sowie OpenBSDs LibreSSL. Alle diese Projekte versprechen eine abgespeckte Version von SSL/TLS, mit einem Auge darauf, überflüssigen Programmcode zu entfernen, der zu Schwachstellen und seltsamen Code-Pfaden in OpenSSL führt.

Das bemerkenswerteste Feature von s2n ist, dass es über nur 6.000 Zeilen Code verfügt, was manuelle Code-Audits sehr viel einfacher macht. Es ist nicht zu erwarten, dass diese extrem kleine Basis bleibt, da – in ihrer jetzigen Form – keine integrierte Unterstützung für wichtige Funktionen wie Zertifikats-Parsing enthalten ist. Es handelt sich also um eine kleine Code-Basis, die bis zum breit gestreuten Produktionseinsatz noch von weiteren Projekten abhängig sein wird. Es scheint jedoch eine gute Idee zu sein, die TLS-Funktionalität von der allgemeineren Kryptographie-Funktionalität zu trennen, so dass Bugs und Features dort bearbeitet und isoliert getestet werden können.

s2n ist auf GitHub gehostet, derzeit der Ort schlechthin für die Zusammenarbeit an Open-Source-Projekten. Dank GitHub profitieren neben Amazon auch die Community und andere Unternehmen, die einen Mehrwert in s2n sehen. Schließlich kann Amazon ein anerkannt gutes, ausgereiftes Programm zum Handling von Sicherheitslücken vorweisen. Amazon nimmt zwar noch nicht an Bug Bountys teil, ist aber auf jeden Fall erfahren, wenn es um die Zusammenarbeit mit Forschern auf eine kooperative, konfrontationsfreie Weise geht, wenn Sicherheitsprobleme in AWS oder anderen Amazon-Bereichen auftauchen.

Fraglich ist, warum s2n noch einige ältere Protokolle wie SSLv3 unterstützen soll, auch wenn dies standardmäßig deaktiviert ist. Dies ist eine seltsame Entscheidung, wenn man bedenkt, das SSLv3 jetzt völlig veraltet ist und nicht als sicher gilt. Im Vergleich dazu deaktiviert BoringSSL SSLv3 auch standardmäßig und LibreSSL wird die Unterstützung bald völlig streichen.

Auch das angepriesene Konzept »zweier getrennter Zufallszahlengeneratoren«, um Werte für »öffentliche« und »private« Operationen zu setzen, ist nicht zu Ende gedacht. Wenn ein Zufallszahlengenerator sicher genug ist, werden nicht zwei davon benötigt. Ein Grundprinzip der Kryptographie ist, dass eine Reihe von sicher generierten Zahlen keine Hinweise darauf liefern sollte, welche Zahlen danach folgen. Die Implementierung von zwei Zufallszahlengeneratoren könnte also zukünftig für Probleme sorgen.

Alles in allem ist es erfreulich zu sehen, dass wir aus Heartbleed und ähnlichen Fiaskos unsere Lehren ziehen. OpenSSL ist ein erstaunliches Stück Technologie, das von Freiwilligen geschrieben und von Philanthropie finanziert wird. Es ist zudem ein wesentlicher Grund, warum wir Arbeitsplätze im Internet haben und online einkaufen können. Es ist jedoch an der Zeit, eine ernsthafte Investition in Sachen Kryptografie zu tätigen. Damit ist es als positiv zu werten, dass sich Amazon hier einer Führungsrolle annimmt.«

Tod Beardsley, Security Engineering Manager, (https://www.rapid7.com/)

infografik rapid7 data breach investigations report