Tim Hudson, Präsident der OpenSSL Corporation – Interviewreihe

Tim Hudson ist Mitautor von SSLeay und einer der Organisatoren der OpenSSL Conference, Prag, 13.–15. Oktober 2026. Er verfügt über mehr als 30 Jahre Erfahrung in System‑ und Netzwerksicherheit und ist Präsident der OpenSSL Corporation sowie Chief Technology Officer bei Cryptsoft Pty Ltd. Seit 1995 umfasst seine Arbeit die Mitbegründung von SSLeay mit Eric Young, der kryptografischen Bibliothek, die zur OpenSSL Library, die Mitbegründung des RSA Security Australia Development Center, Beiträge zu Änderungen der US‑Exportvorschriften für Verschlüsselung, die Leitung von mehr als 30 FIPS‑140‑Validierungen, das Co‑Chairing der OASIS‑Technical Committees KMIP und SAM sowie Vorträge auf führenden Sicherheitskonferenzen, darunter die RSA Conference, AusCERT, ICMC, LinuxConf und die OpenSSL Conference.

OpenSSL ist ein globales, kollaboratives Open‑Source‑Projekt, das die OpenSSL Library entwickelt und pflegt, eine der weltweit am häufigsten genutzten kryptografischen Bibliotheken. Die OpenSSL Library wird in Betriebssystemen, Cloud‑Plattformen, Unternehmenssoftware und vernetzten Geräten eingesetzt und schützt täglich Milliarden sicherer Online‑Interaktionen. Durch die OpenSSL Foundation und die OpenSSL Corporation verpflichtet sich das Projekt, vertrauenswürdige Kryptografie voranzutreiben, nachhaltige Open‑Source‑Entwicklung zu unterstützen und die Sicherheit des Internets zu stärken.

Sie haben 1995 zusammen mit Eric Young SSLeay gegründet, nachdem Sie den Bedarf an einer nicht‑US‑Implementierung von SSL erkannt hatten, und diese Arbeit wurde schließlich zur Grundlage von OpenSSL. Welches Problem wollten Sie ursprünglich lösen, und hatten Sie damals bereits das Gefühl, dass die Technologie zu einem so grundlegenden Bestandteil der Internetsicherheit werden könnte?

Das Problem war völlig konkret und zunächst ein kommerzielles, bevor es etwas anderes war. Ich arbeitete bei Mincom in Brisbane, und wir hatten Kunden, die ihre Kommunikation sichern mussten. Es gab keine Möglichkeit, diese Fähigkeit zu kaufen. Die US‑Exportkontrollen für Kryptografie bedeuteten, dass amerikanische Produkte entweder überhaupt nicht an uns geliefert werden konnten oder nur mit so stark eingeschränkten Schlüssellängen kamen, dass ihr Einsatz unehrlich gewesen wäre. Das war keine philosophische Einwendung gegen die Exportpolitik, sondern ein technisches Problem, bei dem die benötigte Komponente in keiner käuflichen Form existierte, während Kunden bereits warteten.

Was ich jedoch hatte, war Wissen über etwas, das die meisten Menschen vergessen hatten. Eric Young hatte einige Jahre zuvor eine DES‑Implementierung geschrieben: guten, sauberen, frei verfügbaren Code, der um seiner selbst willen entstand und völlig unrelated zu all dem war. Eric arbeitete nicht an SSL und kannte SSL nicht. Als Netscape die Spezifikation veröffentlichte, las ich sie, wandte mich mit dem Problem an Eric und stellte es als einen relativ kleinen Schritt von dem dar, was er bereits hatte.

Das war jedoch nicht das ganze Bild. Jeder Teil war einfach, aber es gab eine beträchtliche Anzahl von Teilen. Eine DES‑Implementierung liefert einen symmetrischen Algorithmus. SSL benötigt Public‑Key‑Kryptografie, arithmetische Operationen mit beliebiger Präzision, ASN.1, X.509‑Zertifikatsverarbeitung und eine Protokoll‑Zustandsmaschine – und das alles korrekt, denn in der Kryptografie sind fast korrekte und defekte Implementierungen dasselbe. Ich hatte das Ausmaß optimistisch dargestellt. Eric erkannte schnell, wie umfangreich es war, und genoss es, weil die Größe eher als Anreiz denn als Hindernis wirkte. Ich bin mir nicht sicher, ob es auf andere Weise begonnen hätte.

Er entwickelte den kryptografischen Kern, weshalb die Bibliothek seine Initialen trägt. Ich übernahm die Teile, die eine Bibliothek zu etwas machen, das andere tatsächlich einsetzen können: die Anwendungsintegration, das Testen, die Dokumentation und den Community‑Bereich. Außerdem suchte ich aktiv nach Stellen, an denen eine konkurrierende Verschlüsselungsbibliothek eingesetzt wurde, und ersetzte sie. SSLtelnet, SSLftp, NCSA httpd und zahlreiche weitere Pakete waren meine Arbeit – Anwendungen, die auf den von Eric implementierten kryptografischen Algorithmen und Protokollen aufbauten. Diese Aufteilung ermöglichte es jedem von uns, sich auf das zu konzentrieren, was uns wirklich interessierte, was meiner Meinung nach der Hauptgrund dafür war, dass das Projekt weiterlief.

Der Standort in Australien machte die Lösung überhaupt erst möglich, und dann stellte sich heraus, dass viele andere genau dasselbe Problem aus demselben Grund hatten. Etwas, das für eine spezifische Kundenanforderung in Brisbane entwickelt wurde, wurde für alle außerhalb der Vereinigten Staaten nützlich und schließlich auch für zahlreiche Menschen innerhalb der USA.

Wussten wir, was daraus werden würde? Nein. Niemand hat das Ziel, kritische Infrastruktur zu bauen. Kritische Infrastruktur erkennt man erst Jahre später, wenn man erfährt, wer darauf angewiesen ist. Wir dachten, wir lösen ein aktuelles Problem und beantworten anschließend Fragen von anderen, die vor demselben Problem standen. Das Beantworten von Fragen erwies sich als genauso wichtig wie der Code.

Sie arbeiten seit mehr als drei Jahrzehnten in der Kryptografie und Internetsicherheit. Was hat sich in diesem Zeitraum am dramatischsten an der Bedrohungslandschaft verändert, und welche Sicherheitsprobleme sind trotz enormer technologischer Fortschritte überraschend ähnlich geblieben?

Die bedeutendste Veränderung ist, dass das Angreifen von Systemen zu einem Beruf mit einem wirtschaftlichen Modell geworden ist. Mitte der 90‑Jahre hackten Menschen hauptsächlich aus Interesse. Heute gibt es eine Branche mit Spezialisierung, Werkzeugen, Lieferketten, Kundensupport und teilweise staatlicher Finanzierung. Das verändert alles, wie man denken muss, denn man verteidigt sich nicht mehr gegen Neugier, sondern gegen jemanden mit Budget, Frist und Business‑Case.

Die zweite Veränderung ist die Skalierung und Abhängigkeit. Die durchschnittliche Anwendung 1995 war etwas, das Sie selbst geschrieben haben. Heute ist die durchschnittliche Anwendung etwas, das Sie zusammenstellen, und der Großteil des Codes stammt von Personen, die Sie nie getroffen haben und nicht benennen können. Die Angriffsfläche verlagerte sich von Ihrem eigenen Code zu Ihren Abhängigkeiten, und die meisten Organisationen haben ihr Denken nicht entsprechend angepasst.

Was bemerkenswert konstant blieb, sind die Fehlermodi. Wir schreiben immer noch Bugs in Code, der untrusted Eingaben parst. Wir liefern weiterhin Systeme mit Standardeinstellungen, die niemand mehr überprüft hat. Zertifikate laufen immer noch an einem Samstag ab. Zugangsdaten landen immer noch an Orten, wo sie nicht hingehören. Und Kryptografie wird fast nie auf mathematischer Ebene gebrochen; sie wird umgangen, falsch konfiguriert oder schlicht nicht aktiviert. Wenn Sie mir eine Liste der zehn Hauptursachen für Verstöße aus dem Jahr 1996 und eine aktuelle Liste geben würden, wäre es schwer, sie zu unterscheiden. Die Technologie hat sich vollständig gewandelt, die Fehler jedoch nicht.

OpenSSL 4.0 wurde im April 2026 veröffentlicht und stellt die erste größere Veröffentlichung des Projekts seit mehreren Jahren dar. Was sagt uns diese Version über die zukünftige Richtung der kryptografischen Infrastruktur, und welche Änderungen werden Ihrer Meinung nach letztlich für Organisationen, die auf OpenSSL angewiesen sind, am wichtigsten sein?

Das Wichtigste, das man über 4.0 verstehen muss, ist, dass es hauptsächlich ein Subtraktions‑Release ist – und genau das war sein Zweck.

Wir haben die ENGINE‑Schnittstelle vollständig entfernt. Wir haben SSLv3 und das SSLv2‑ClientHello entfernt. Wir haben veraltete elliptische Kurven und explizite EC‑Kurven zur Compile‑Zeit deaktiviert. Wir haben ASN1_STRING undurchsichtig gemacht und zahlreiche API‑Signaturen verschärft. Das sind die Änderungen, die Arbeit für die Nutzer erzeugen und die wirklich wichtig sind, denn eine kryptografische Bibliothek, die nur weiter wächst, kann nicht sicher bleiben. Jeder veraltete Codepfad, den man weiter aktiv hält, ist eine Angriffsfläche, die von jemandem in Ihrem Namen gepflegt wird, ohne dass jemand sie testet.

Es gibt Ergänzungen: Encrypted Client Hello, Unterstützung für RFC 8998 inklusive der hybriden SM2/ML‑KEM‑Gruppe, cSHAKE, SNMP‑ und SRTP‑KDFs, verhandelte FFDHE für TLS 1.2. Besonders ECH schließt eine echte Datenschutzlücke, da Server Name Indication seit dem Versand von TLS 1.3 die Identität jeder besuchten Seite preisgab. Aber die Entfernungen sind das eigentliche Thema.

Die wichtigste Botschaft, die ich Organisationen mitgeben möchte, lautet: 4.0 ist nicht die LTS‑Version. Sie wird bis Mai 2027 unterstützt. Die aktuelle langfristig stabile Version ist 3.5, unterstützt bis April 2030, und 3.5 enthält bereits die post‑quantum‑Algorithmen. Wenn Sie den neuesten Code wollen, setzen Sie 4.0 ein. Wenn Sie ein stabiles Ziel für einen Fünf‑Jahres‑Migrationsplan benötigen, setzen Sie 3.5 ein. Die höhere Versionsnummer nur wegen ihrer Größe zu wählen, ist ein Fehler, den wir jedes Mal beobachten.

Post‑quantum‑Kryptografie hat sich von einem Forschungsproblem zu einer Migrationsherausforderung entwickelt, wobei OpenSSL bereits ML‑KEM, ML‑DSA und SLH‑DSA sowie hybriden post‑quantum Schlüsselaustausch unterstützt. Welche Risiken übersehen Führungskräfte, die annehmen, dass Quantencomputing noch zu weit entfernt ist?

Der häufigste Fehler besteht darin, dies als Frage nach dem Zeitpunkt zu betrachten, an dem ein kryptografisch relevanter Quantencomputer eintrifft. Das ist die falsche Variable. Die richtige Frage lautet, wie lange Ihre Daten vertraulich bleiben müssen und wie lange Ihre Migration dauert. Subtrahieren Sie das Zweite vom Ersten und Sie erhalten Ihre tatsächliche Frist – und für viele Organisationen liegt diese Frist bereits in der Vergangenheit.

Verschlüsselter Datenverkehr kann heute abgefangen und unbegrenzt gespeichert werden. Wenn die darin enthaltenen Informationen eine Sensitivitätsdauer von zwanzig Jahren haben (Patientenakten, Personalunterlagen, geistiges Eigentum, diplomatisches Material, finanzielle Positionen), benötigt ein Angreifer keinen Quantencomputer jetzt, sondern irgendwann und in der Zwischenzeit günstigen Speicher. Das ist kein spekulativer Angriff, sondern eine Archivierungsentscheidung.

Der zweite übersehene Punkt ist, dass die Migration nicht ein einzelnes Projekt ist. Der Schlüsselaustausch ist der einfache Teil, und ein Großteil davon geschieht bereits: OpenSSL 3.5 hat den hybriden post‑quantum Schlüsselaustausch zum TLS‑Standard gemacht, sodass viele Organisationen bereits post‑quantum Schlüsselvereinbarungen nutzen, ohne eine Entscheidung dazu getroffen zu haben. Signaturen und die Zertifikathierarchie sind der schwierige Teil, weil sie Zertifizierungsstellen, Hardware‑Root‑of‑Trusts, Firmware‑Signaturschlüssel, Hardware‑Security‑Modules und Geräte mit einer Lebensdauer von fünfzehn Jahren betreffen, die auf der Annahme basierten, dass RSA für immer ausreichen würde.

Der dritte Punkt ist die Einschränkung, für die niemand ein Budget bereitstellt: post‑quantum Signaturen sind groß. Eine ML‑DSA‑65‑Signatur ist etwa fünfzigmal so groß wie eine ECDSA P‑256‑Signatur, und SLH‑DSA ist noch größer. Das führt zu Problemen bei Handshake‑Größen, eingeschränkten Geräten, Protokollen mit fest codierten Feldgrenzen, Satelliten‑ und IoT‑Verbindungen. Diese Probleme entdeckt man durch Tests, nicht durch das Lesen eines Standards.

Eines der Probleme bei der post‑quantum Migration ist, dass Organisationen möglicherweise nicht einmal wissen, wo überall Kryptografie in ihren Anwendungen, Infrastrukturen, Geräten und Drittanbieter‑Abhängigkeiten eingesetzt wird. Wie sollten Unternehmen ein kryptografisches Inventar und Crypto‑Agility angehen, damit die nächste große Algorithmus‑Transition nicht zu einem Notfall wird?

Beginnen Sie mit einer unbequemen Wahrheit: Sie können kein kryptografisches Inventar erstellen, indem Sie Ihren Lieferanten einen Fragebogen zusenden. Sie erhalten eine Mischung aus Marketingtexten, ehrlicher Unsicherheit und Antworten, die vor drei Releases noch korrekt waren. Das sage ich, weil ich kürzlich viel Zeit damit verbracht habe, Dokumentationen von Hardware‑Herstellern in einem verwandten Bereich zu lesen, und die Diskrepanz zwischen den Angaben in der Dokumentation und dem tatsächlichen Produkt größer ist, als die meisten Käufer annehmen.

Man muss hinschauen. Es gibt drei Ebenen, die unterschiedliche Techniken erfordern. Code, den Sie geschrieben haben: statische Analyse, Abhängigkeits‑Scanning und das Suchen nach Algorithmus‑Bezeichnern, die Sie vor Jahren hart kodiert haben. Code, den Sie gelinkt haben: Software‑Bills‑of‑Materials, erweitert zu kryptografischen Bills‑of‑Materials, wo die CBOM‑Arbeit wirklich nützlich ist. Dinge, die Sie gekauft oder angeschlossen haben: Netzwerk‑Beobachtung, weil das, was Ihre Systeme tatsächlich auf der Leitung aushandeln, die wahre Realität ist und häufig nicht dem entspricht, was jemand angenommen hat.

Bei der Agilität gilt das Prinzip: einfach, aber die Praxis ist es nicht – der Algorithmus sollte eine Konfigurationsentscheidung sein, kein Code‑Änderung. Wenn das Ändern eines Cipher einen Entwickler, einen Build, einen Testzyklus und ein Release erfordert, haben Sie keine Agilität, sondern ein Projekt. Zentralisieren Sie kryptografische Vorgänge hinter einer von Ihnen kontrollierten Schnittstelle, sodass es nur einen Ort zum Ändern gibt statt vierhundert.

Und dann der Teil, den fast jeder überspringt: probieren Sie es aus. Agilität, die Sie nie genutzt haben, ist ein Anspruch, keine Fähigkeit. Nehmen Sie ein ruhiges Wochenende, schalten Sie einen Algorithmus in einer Nicht‑Produktionsumgebung ab und prüfen Sie, was kaputt geht. Etwas wird brechen. Es ist besser, das nach Ihrem Zeitplan zu entdecken, als während einer vorgeschriebenen Notfall‑Transition.

Ein nützliches Zwangselement ist die Zertifikatslebensdauer. Die Branche bewegt sich zu deutlich kürzer lebenden Zertifikaten, was manuelle Zertifikatsverwaltung unhaltbar macht und die Automatisierung erzwingt, die Sie ohnehin benötigen würden. Wenn Sie die Ausstellung und Rotation von Zertifikaten korrekt automatisieren, haben Sie bereits den Großteil der Infrastruktur geschaffen, die ein zukünftiger Algorithmus‑Wechsel erfordert.

KI verändert sowohl die Cyber‑Sicherheitsabwehr als auch die Fähigkeiten von Angreifern. Wo glauben Sie, dass KI die Sicherheitsgleichung wirklich verändert, und wo denken Sie, dass Organisationen zu sehr auf die Technologie setzen und dabei grundlegendere Schwächen übersehen?

KI verändert tatsächlich einen Aspekt, und ich kann aus eigener Erfahrung darüber sprechen.

Eine beträchtliche Anzahl der in diesem Jahr in OpenSSL veröffentlichten Schwachstellen wurde durch KI‑gestützte Analysen gefunden. Im Januar veröffentlichten wir ein Update, das zwölf Probleme behebt, im Wesentlichen alle von einer Forschungsgruppe, die automatisierte Analysen einsetzte, und sie lieferten Patches zusammen mit den Berichten. Im Juni beheben wir ein hochkritisches Use‑After‑Free in der PKCS#7‑Verifizierung, das von einem Forscher mit einem KI‑System entdeckt wurde. Das ist eine echte Fähigkeitsänderung beim Auffinden von Speicher‑ und Parsing‑Fehlern in reifem C‑Code, der seit Jahren von Experten geprüft wird. Ich habe dasselbe Muster in anderen kryptografischen Bibliotheken beobachtet. Bei der Analyse einer Reihe von Bouncy‑Castle‑CVE‑Einträgen aus diesem Jahr ist das Finger‑Print automatisierter Code‑Analyse deutlich erkennbar.

Die offensichtliche Folgerung ist, dass dies in beide Richtungen wirkt. Die gleichen Techniken stehen jedem zur Verfügung, der sie nutzen will, auf denselben Codebasen, und Verteidiger haben keinen exklusiven Zugriff.

Die weniger offensichtliche Konsequenz, die ich betonen möchte, ist die Belastung der Maintainer. Einen plausibel aussehenden Schwachstellenbericht zu erstellen, ist jetzt fast kostenlos. Das Triagen dagegen nicht. Es kostet immer noch die reale Zeit eines Experten. Open‑Source‑Sicherheitsteams, die meist klein und häufig ehrenamtlich sind, müssen ein wachsendes Volumen von Berichten unterschiedlicher Qualität bewältigen. Die guten, wie die erwähnte Forschung, kommen mit Reproduktionsschritten und Patches. Die schlechten stellen eine Denial‑of‑Service‑Attacke auf die Personen dar, von denen Sie abhängen. Wenn Ihre Organisation KI gegen Open‑Source‑Code einsetzt, finanzieren Sie die Triage‑Kapazität auf der anderen Seite.

Wo ich die Aufmerksamkeit fehl am Platz sehe: KI patcht Ihre Systeme nicht. Sie inventarisiert nicht Ihre Assets, rotiert nicht Ihre Zugangsdaten, ersetzt nicht Ihre nicht mehr unterstützte Hardware und macht niemanden für das nächste Monat ablaufende Zertifikat verantwortlich. Organisationen, die KI‑Sicherheitswerkzeuge kaufen, während sie Software mit bekannten, ungepatchten Schwachstellen betreiben, haben die Reihenfolge falsch. Die unspektakuläre Arbeit bleibt das eigentliche Risiko.

Viele Organisationen investieren stark in Werkzeuge, bleiben aber aufgrund von Konfigurationsfehlern, veralteten Systemen, schwachen Prozessen oder mangelhafter Vorfallvorbereitung verwundbar. Welche sicherheitsrelevanten Fehler sehen Sie weiterhin am häufigsten, und was sollten Führungsteams vor einem tatsächlichen Angriff bereitstellen?

Der gravierendste Fehler besteht darin, Sicherheit als Beschaffungsaktivität zu behandeln. Werkzeuge werden gekauft, Budgets eingehalten, Dashboards zeigen Grün, und niemand hat gefragt, ob die Organisation die grundlegenden Dinge tatsächlich umsetzen kann.

Der zweite Fehler ist, nicht zu wissen, was Sie betreiben. Sie können keine Software patchen, von der Sie nicht wissen, dass Sie sie besitzen, und die meisten Organisationen entdecken den wahren Bestand ihrer Umgebung erst während eines Vorfalls. Deshalb ist die Arbeit an Bills‑of‑Materials wichtig, nicht als Compliance‑Dokument, sondern als das, worauf Sie um 2 Uhr morgens zurückgreifen, wenn ein kritischer Hinweis erscheint und jemand fragt, ob Sie betroffen sind.

Der dritte Fehler sind Standardeinstellungen. Systeme werden installiert, funktionieren, und die Konfiguration wird nie erneut überprüft. Fünf Jahre später ist diese Konfiguration eine Haftungsquelle, und niemand, der an der ursprünglichen Entscheidung beteiligt war, arbeitet noch dort.

Der vierte Fehler ist das Schlüssel‑ und Zertifikatsmanagement, das einzelnen Personen überlassen wird. Ein bemerkenswerter Anteil selbstverursachter Ausfälle sind abgelaufene Zertifikate, die von einer Person stillschweigend in einer Tabelle verfolgt wurden, bis sie den Job wechselte.

Vor einem Vorfall muss die Führungsebene vier Dinge bereitstellen: Einen benannten Entscheidungsträger mit der Befugnis, das Geschäft offline zu nehmen, im Voraus und schriftlich festgelegt, weil das Argument darüber, wer diese Befugnis hat, nicht live geführt werden sollte. Bereits unterschriebene Retainer mit externen Forensik‑ und Fachberatern, weil die Beschaffung Wochen dauert und Sie nur Stunden haben. Einen Kommunikationskanal, der nicht von den möglicherweise kompromittierten Systemen abhängt. Und eine Wiederherstellungsfähigkeit, die tatsächlich End‑to‑End‑getestet wurde, nicht ein Backup‑Regime, das nur insofern verifiziert wurde, dass die Jobs erfolgreich abgeschlossen wurden.

Danach üben Sie es. Ein jährliches Table‑Top‑Exercise auf Führungsebene deckt mehr echte Lücken auf als ein weiteres Werkzeug.

Wenn ein schwerer Cyberangriff stattfindet, können Führungskräfte plötzlich technische, rechtliche, operative und kommunikative Entscheidungen unter enormem Druck treffen. Was unterscheidet Organisationen, die effektiv reagieren, von denen, die einen Vorfall erheblich verschlimmern lassen?

Organisationen, die gut damit umgehen, haben die wichtigen Entscheidungen bereits vor dem Vorfall getroffen, sodass sie während des Vorfalls handeln statt zu diskutieren. Das ist der größte Teil.

Abgesehen von der Vorbereitung trennen einige Dinge konsequent gute von schlechten Reaktionen.

Sie trennen die technische Untersuchung vom Executive‑ und Kommunikationsbereich, mit einer definierten Schnittstelle dazwischen. Wenn dieselben Personen versuchen, einen Eindringling zu isolieren und gleichzeitig eine Kundenbenachrichtigung zu verfassen, werden beide Aufgaben schlecht erledigt.

Sie bewahren Beweise, bevor sie Gegenmaßnahmen ergreifen. Der Impuls, die kompromittierte Maschine sofort neu aufzubauen, ist stark und zerstört die Informationen, die Sie benötigen, um den Umfang zu bestimmen. Wenn Sie nicht beantworten können, „was haben sie noch berührt“, können Sie niemandem glaubhaft mitteilen, dass der Vorfall beendet ist.

Sie akzeptieren, dass frühe Informationen vorläufig sind, und kommunizieren dem entsprechend. Die meiste von mir beobachtete Rufschädigung resultierte nicht aus dem Verstoß selbst, sondern aus zuversichtlichen frühen Aussagen, die zurückgezogen werden mussten. Zu sagen: „Das ist, was wir wissen, das ist, was wir noch nicht wissen, das ist, wann wir Sie aktualisieren“, ist keine Schwäche. Es ist die einzige Position, die Sie nicht rückgängig machen müssen.

Und entscheidend: Sie schaffen Bedingungen, unter denen Ingenieure den Führungskräften schlechte Nachrichten übermitteln können. Das häufigste Fehlermuster, das ich beobachtet habe, ist eine Organisation, in der die rechtliche Gefahr so offensichtlich war, dass niemand die Person sein wollte, die festhält, was tatsächlich geschehen ist. Der Vorfall verschlimmert sich dann stillschweigend. Wenn Ihre Ingenieure ihre eigene Haftung statt des Vorfalls managen, haben Sie ein Governance‑Problem, das keine Menge an Werkzeugen lösen kann.

OpenSSL befindet sich in einer ungewöhnlichen Position als kritische Open‑Source‑Infrastruktur, die im gesamten Technologiekosmos verwendet wird, während die OpenSSL Corporation kommerzielle Gemeinschaften zusammen mit der unabhängig betriebenen OpenSSL Foundation bedient. Wie balancieren Sie die Bedürfnisse von Unternehmen, Entwicklern, Regulierungsbehörden und der breiteren Open‑Source‑Community, wenn Entscheidungen zu Sicherheit und Kompatibilität einen so großen Teil des Internets betreffen?

Die ehrliche Antwort lautet, dass Sie sie nicht ausbalancieren, indem Sie versuchen, jeden bei jeder Entscheidung glücklich zu machen. Sie balancieren sie, indem Sie eine veröffentlichte Richtlinie haben und diese vorhersehbar anwenden, sodass Menschen um Sie herum planen können, selbst wenn sie ein bestimmtes Ergebnis nicht mögen.

Vorhersehbarkeit ist das, was wir unseren Nutzern schulden. Wir veröffentlichen Funktions‑Releases im April und Oktober. Wir teilen im Voraus mit, welche Version langfristig stabil ist und bis wann. Wir kündigen bedeutende Entfernungen lange im Voraus an. Die Entfernung von ENGINE in 4.0 wurde Monate vor dem Release öffentlich beschrieben und von sowohl der Corporation als auch der Foundation vereinbart. Wer im April überrascht war, hat nicht aufgepasst, und wir haben es so einfach wie möglich gemacht, aufmerksam zu sein.

Die strukturelle Antwort ist die Trennung selbst. Die Foundation dient der Open‑Source‑Bibliothek und der Community darum herum. Die Corporation dient Organisationen mit kommerziellen Anforderungen (Support‑Verpflichtungen, FIPS‑Validierung, spezifische Zeitpläne) und sorgt dafür, dass das Ganze finanziell nachhaltig ist. Diese Unterscheidung bedeutet, dass keine der beiden Bedürfnissätze stillschweigend zugunsten des anderen gelöst wird. Wenn Unternehmens‑ und Community‑Anforderungen tatsächlich im Konflikt stehen, geschieht dieser Konflikt zwischen zwei Organisationen mit klaren Mandaten und nicht im Kopf einer einzelnen Person.

Der andere Teil ist das richtige Zuhören, das tatsächliche Mechanismen erfordert und nicht bloße Annahmen. Das ist ein großer Grund, warum wir die Konferenz veranstalten, die im Oktober in Prag stattfindet, und warum die Community‑Infrastruktur existiert. Es ist sehr einfach für Maintainer, selbstsichere Theorien darüber zu entwickeln, was Nutzer benötigen. Es ist deutlich nützlicher, mit ihnen im selben Raum zu sein.

Blicken Sie auf das nächste Jahrzehnt, welche Sicherheits‑ oder Kryptografie‑Transition halten Sie für heute noch unterschätzt, und welche Lehren aus der Entwicklung von SSL, OpenSSL und den letzten 30 Jahren Internetsicherheit sollten Führungskräfte bei der Vorbereitung darauf berücksichtigen?

Die Transition, die meiner Meinung nach am meisten unterschätzt wird, ist nicht die post‑quantum‑Kryptografie als Algorithmus‑Problem, sondern die Maschinenidentität und die Zertifikathierarchie, die allem zugrunde liegt.

Der post‑quantum Schlüsselaustausch wird weitgehend durch Standardeinstellungen gelöst, und ein Großteil ist bereits so. Was jedoch nicht durch Standardeinstellungen gelöst wird, ist die Vertrauensinfrastruktur: Root‑Zertifikate in Hardware, Firmware‑Signaturschlüssel, die in Geräte eingebrannt sind, HSMs mit einem Jahrzehnt Restlebensdauer, Industrie‑ und Medizinsysteme, die bis 2040 laufen und bei denen kryptografische Annahmen bereits bei der Herstellung fest verankert wurden. Diese können nicht durch das Ausliefern einer neuen Bibliotheksversion aktualisiert werden und in manchen Fällen gar nicht. Das Ausmaß dieses Ersatzproblems spiegelt sich derzeit in keiner Kapitalplanung wider.

Parallel dazu findet ein regulatorischer Wandel statt. Der Cyber Resilience Act in Europa und vergleichbare Rahmenwerke anderswo werden die Pflichten ändern, die mit dem Ausliefern von Software verbunden sind, die Komponenten enthält, die Sie nicht selbst geschrieben haben. Die meisten Organisationen haben noch nicht durchdacht, was das für ihre Abhängigkeit von Open‑Source und für die Personen, die diese pflegen, bedeutet.

1. Übergänge dauern ein Jahrzehnt länger als angekündigt. SSLv3 wurde 2015 eingestellt, 2016 standardmäßig deaktiviert, und wir haben den Code schließlich im April 2026 entfernt. Das sind elf Jahre für ein Protokoll, von dem alle einig waren, dass es defekt ist. Planen Sie die post‑quantum Migration anhand dieser Realität, nicht anhand der Pressemitteilung.
2. Standardwerte sind die einzige Sicherheitskontrolle, die in großem Maßstab funktioniert. Alles, was erfordert, dass jeder Administrator eine korrekte Entscheidung trifft, wird nicht funktionieren. Der Grund, warum der hybride post‑quantum Schlüsselaustausch so schnell eingeführt wurde, liegt darin, dass er standardmäßig aktiviert ist und keinerlei Entscheidung erfordert. Gestalten Sie für die Personen, die Ihre Dokumentation nie lesen werden, denn das sind fast alle.
3. Sie sind von weniger Personen abhängig, als Sie denken. Fast jede Organisation weltweit nutzt kryptografischen Code, der von einer sehr kleinen Anzahl von Personen gepflegt wird. Das war bereits der Fall, als wir zu zweit in Brisbane waren, und die Struktur hat sich grundlegend nicht verändert, obwohl die Einsätze um Größenordnungen gestiegen sind. Was auch immer Sie für das nächste Jahrzehnt planen, ein Teil davon beruht auf einem Maintainer, den Sie nie kontaktiert haben und der nicht finanziert wird. Das sollte man wissen, bevor man ihn braucht.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten OpenSSL besuchen.