Tim Hudson, president van OpenSSL Corporation – Interviewserie

Tim Hudson is mede-auteur van SSLeay en een van de organisatoren van de OpenSSL Conference, Praag 13-15 oktober 2026. Hij heeft meer dan 30 jaar ervaring in systeem- en netwerkbeveiliging en is president van OpenSSL Corporation en chief technology officer bij Cryptsoft Pty Ltd. Sinds 1995 omvat zijn werk het mede-oprichten van SSLeay met Eric Young, de cryptografische bibliotheek die de OpenSSL Library werd, het mede-oprichten van het RSA Security Australia‑ontwikkelingscentrum, bijdragen aan wijzigingen in de Amerikaanse exportregels voor encryptie, het leiden van meer dan 30 FIPS 140‑validaties, het mede‑voorzitten van de OASIS KMIP‑ en SAM‑technical committees, en spreken op toonaangevende beveiligingsconferenties, waaronder RSA Conference, AusCERT, ICMC, LinuxConf en de OpenSSL Conference.

OpenSSL is een wereldwijd collaboratief open source project dat de OpenSSL Library ontwikkelt en onderhoudt, een van de meest gebruikte cryptografische bibliotheken ter wereld. Gebruikt op besturingssystemen, cloudplatformen, bedrijfssoftware en verbonden apparaten, helpt de OpenSSL Library elke dag miljarden veilige online interacties te beschermen. Via de OpenSSL Foundation en OpenSSL Corporation zet het project zich in voor het bevorderen van vertrouwde cryptografie, het ondersteunen van duurzame open source ontwikkeling en het versterken van de beveiliging van het internet.

U hebt SSLeay in 1995 mede-opgericht met Eric Young nadat u de behoefte herkende aan een niet‑Amerikaanse implementatie van SSL, en dat werk werd uiteindelijk de basis voor OpenSSL. Welk probleem probeerde u oorspronkelijk op te lossen, en had u destijds al het gevoel dat de technologie zo’n fundamenteel onderdeel van het beveiligen van het internet kon worden?

Het probleem was volledig concreet, en het was een commercieel probleem voordat het iets anders was. Ik werkte bij Mincom in Brisbane, en we hadden klanten die hun communicatie moesten beveiligen. Er was geen manier om die functionaliteit te kopen. Amerikaanse exportcontroles op cryptografie betekenden dat Amerikaanse producten ons helemaal niet konden leveren of dat ze alleen beschikbaar waren met zo sterk beperkte sleutelgroottes dat implementatie oneerlijk zou zijn geweest. Het was geen filosofisch bezwaar tegen exportbeleid. Het was een technisch probleem waarbij de benodigde component in geen enkele vorm verkrijgbaar was, en ik had klanten die wachtten.

Wat ik wel had, was kennis van iets dat de meeste mensen waren vergeten. Eric Young had enkele jaren eerder een DES‑implementatie geschreven: goede, schone, vrij beschikbare code, geschreven omwille van zichzelf en volledig losstaand van dit alles. Eric werkte niet aan SSL. Hij was niet op de hoogte van SSL. Toen Netscape de specificatie publiceerde, las ik die, benaderde Eric met het probleem en stelde het voor als een relatief bescheiden stap ten opzichte van waar hij al stond.

Dit was niet het volledige plaatje. Elk onderdeel was eenvoudig, maar er waren aanzienlijk veel onderdelen. Een DES‑implementatie levert één symmetrische cipher. SSL vereist publieke‑sleutelcryptografie, rekenkunde met willekeurige precisie, ASN.1, X.509‑certificaatverwerking en een protocol‑state‑machine, en alles moet correct zijn, want in cryptografie is bijna correct net zo slecht als gebroken. Ik had de omvang optimistisch geschetst. Eric kwam al snel erachter hoeveel er was, en genoot ervan, omdat de schaal juist de aantrekkingskracht bleek te zijn in plaats van een obstakel. Ik weet niet zeker of het anders zou zijn begonnen.

Hij deed de cryptografische kern, waardoor de bibliotheek zijn initialen draagt. Ik nam de onderdelen op die een bibliotheek omzetten in iets dat anderen daadwerkelijk kunnen inzetten: de applicatie‑integratie, de tests, de documentatie en het community‑gedeelte. Ik zocht ook actief naar plaatsen waar een concurrerende encryptiebibliotheek werd gebruikt en verving of converteerde die. SSLtelnet, SSLftp, NCSA httpd en tal van andere pakketten waren mijn werk, applicaties gebouwd bovenop de cryptografische algoritmen en protocollen die Eric had geïmplementeerd. Die combinatie stelde ons elk in staat zich te concentreren op wat ons werkelijk interesseerde, wat volgens mij de belangrijkste reden is dat het bleef bestaan.

In Australië zijn was wat het überhaupt mogelijk maakte, en toen bleek dat heel veel andere mensen exact hetzelfde probleem hadden om precies dezelfde reden. Iets dat was gebouwd om te voldoen aan een specifieke klantvraag in Brisbane, werd nuttig voor iedereen buiten de Verenigde Staten, en uiteindelijk ook voor veel mensen binnen die regio.

Wisten we wat het zou worden? Nee. Niemand zet zich op om kritieke infrastructuur te bouwen. Kritieke infrastructuur is wat je ontdekt dat je hebt gebouwd, enkele jaren later, wanneer je ziet wie erop vertrouwt. Wat wij dachten te doen was een probleem voor ons oplossen en vervolgens vragen beantwoorden van anderen die tegen dezelfde muur waren aangelopen. Het beantwoorden van die vragen bleek net zo belangrijk als de code.

U werkt al meer dan drie decennia in cryptografie en internetbeveiliging. Wat is er in die periode het meest dramatisch veranderd aan het dreigingslandschap, en welke beveiligingsproblemen zijn verrassend gelijk gebleven ondanks enorme technologische vooruitgang?

De grootste verandering is dat het aanvallen van systemen een beroep is geworden met een economisch model erachter. Halverwege de jaren negentig deden de mensen die systemen binnendrongen het vooral omdat het interessant was. Vandaag is er een industrie, met specialisatie, gereedschap, toeleveringsketens, klantenondersteuning en in sommige gevallen staatsfinanciering. Dat verandert alles in de manier waarop je moet denken, want je verdedigt niet langer tegen nieuwsgierigheid, maar tegen iemand met een budget, een deadline en een businesscase.

De tweede verandering is schaal en afhankelijkheid. De gemiddelde applicatie in 1995 was iets dat je zelf schreef. De gemiddelde applicatie van vandaag is iets dat je in elkaar zet, en het grootste deel van de code is geschreven door mensen die je nooit hebt ontmoet en niet kunt benoemen. Het aanvalsoppervlak is verschoven van jouw code naar jouw afhankelijkheden, en de meeste organisaties hebben hun denkwijze hier niet op aangepast.

Wat opmerkelijk constant is gebleven, zijn de faalmodi. We schrijven nog steeds bugs in code die onbetrouwbare invoer parseert. We leveren nog steeds systemen met standaardinstellingen die niemand opnieuw heeft bekeken. Certificaten verlopen nog steeds op een zaterdag. Inloggegevens belanden nog steeds op plekken waar ze niet horen. En cryptografie wordt nog steeds bijna nooit gebroken op wiskundig niveau. Het wordt omzeild, verkeerd geconfigureerd, of simpelweg niet ingeschakeld. Als je me een lijst gaf van de top tien oorzaken van inbreuken in 1996 en een lijst van vorige maand, zou je moeite hebben ze van elkaar te onderscheiden. De technologie is volledig getransformeerd. De fouten niet.

OpenSSL 4.0 werd in april 2026 uitgebracht, wat de eerste grote release van het project in meerdere jaren markeert. Wat vertelt deze release ons over de richting van cryptografische infrastructuur, en welke veranderingen zullen uiteindelijk het belangrijkste zijn voor organisaties die afhankelijk zijn van OpenSSL?

Het meest bruikbare om te begrijpen over 4.0 is dat het voornamelijk een subtractierelease is, en dat dat precies de bedoeling was.

We hebben de ENGINE‑interface volledig verwijderd. We hebben SSLv3 en de SSLv2 ClientHello verwijderd. We hebben verouderde elliptische curven en expliciete EC‑curves uitgeschakeld bij compilatie. We hebben ASN1_STRING opaque gemaakt en een groot aantal API‑handtekeningen aangescherpt. Dat zijn de veranderingen die werk voor mensen genereren, en dat zijn de veranderingen die er toe doen, want een cryptografische bibliotheek die alleen maar groeit kan niet veilig blijven. Elke verouderde code‑pad die je in leven houdt, is een aanvalsoppervlak dat iemand namens jou onderhoudt en niemand test.

Er zijn aanvullingen: Encrypted Client Hello, RFC 8998‑ondersteuning inclusief de hybride SM2/ML‑KEM‑groep, cSHAKE, SNMP‑ en SRTP‑KDF’s, onderhandelde FFDHE voor TLS 1.2. ECH sluit met name een reëel privacy‑gat, omdat Server Name Indication sinds TLS 1.3 de identiteit van elke site die je bezoekt lekt. Maar de verwijderingen vormen het verhaal.

Het belangrijkste dat ik organisaties wil meegeven is dit: 4.0 is niet de LTS‑release. Hij wordt ondersteund tot mei 2027. De huidige langetermijn‑stabiele release is 3.5, ondersteund tot april 2030, en 3.5 bevat al de post‑quantum‑algoritmen. Als je de nieuwste code wilt, gebruik 4.0. Als je een stabiel doel wilt waar je een vijf‑jaren migratieplan omheen kunt bouwen, gebruik 3.5. Het kiezen van het hogere getal alleen omdat het hoger is, is een fout die we elke cyclus zien.

Post‑quantum‑cryptografie is van een onderzoeksprobleem naar een migratie‑uitdaging verschoven, waarbij OpenSSL al ML‑KEM, ML‑DSA en SLH‑DSA ondersteunt en hybride post‑quantum‑sleuteluitwisseling biedt. Voor bedrijfsleiders die denken dat kwantumcomputers nog te ver weg zijn, welke risico’s over het hoofd zien ze vandaag?

De meest voorkomende fout is dit zien als een vraag over wanneer een cryptografisch relevant kwantumcomputer arriveert. Dat is de verkeerde variabele. De juiste vraag is hoe lang uw data vertrouwelijk moet blijven en hoe lang uw migratie zal duren. Trek het tweede af van het eerste en u heeft uw daadwerkelijke deadline, en voor veel organisaties ligt die deadline al in het verleden.

Versleuteld verkeer kan vandaag worden vastgelegd en onbeperkt worden opgeslagen. Als de informatie een gevoeligheidsperiode van twintig jaar heeft (patiëntendossiers, personeelsbestanden, intellectueel eigendom, diplomatiek materiaal, financiële posities), dan heeft een tegenstander nu geen kwantumcomputer nodig. Hij heeft er uiteindelijk één nodig, en goedkope opslag in de tussentijd. Dat is geen speculatieve aanval; het is een beslissingsvraag.

Het tweede over het hoofd geziene punt is dat migratie geen enkel project is. Sleuteluitwisseling is het gemakkelijke deel, en een groot deel daarvan gebeurt al: OpenSSL 3.5 maakt hybride post‑quantum‑sleuteluitwisseling de TLS‑standaard, dus veel organisaties gebruiken nu al post‑quantum‑sleutelafstemming zonder een beslissing te hebben genomen. Handtekeningen en de certificaathierarchie zijn het moeilijke deel, omdat die certificaatautoriteiten, hardware‑roots‑of‑trust, firmware‑ondertekeningssleutels, hardware‑security‑modules en apparaten met een levensduur van vijftien jaar omvatten die gebouwd zijn onder de veronderstelling dat RSA voor altijd goed zou zijn.

Het derde punt is de beperking waar niemand een budget voor heeft: post‑quantum‑handtekeningen zijn groot. Een ML‑DSA‑65‑handtekening is ongeveer vijftig keer zo groot als een ECDSA P‑256‑handtekening, en SLH‑DSA is nog groter. Dat veroorzaakt problemen: handshake‑groottes, beperkte apparaten, protocollen met vaste veldlimieten, satelliet‑ en IoT‑verbindingen. Deze problemen ontdek je door te testen, niet door een standaard te lezen.

Een van de uitdagingen bij post‑quantum‑migratie is dat organisaties misschien niet eens weten waar cryptografie overal wordt gebruikt in hun applicaties, infrastructuur, apparaten en externe afhankelijkheden. Hoe moeten bedrijven cryptografische inventaris en crypto‑agility benaderen zodat de volgende grote algoritme‑overgang geen noodsituatie wordt?

Begin met een ongemakkelijke waarheid: je kunt geen cryptografische inventaris opbouwen door je leveranciers een vragenlijst te sturen. Je krijgt een mix van marketingteksten, eerlijke onzekerheid en antwoorden die drie releases geleden nog klopten. Ik zeg dit na recent veel tijd te hebben besteed aan het lezen van hardware‑leveranciersdocumentatie in een verwant veld, en de kloof tussen wat documentatie claimt en wat een product daadwerkelijk doet, is groter dan de meeste kopers aannemen.

Je moet zelf kijken. Er zijn drie lagen, en ze vereisen verschillende technieken. Code die je schreef: statische analyse, afhankelijkheidsscan, en zoeken naar de algoritme‑identifiers die je jaren geleden hard‑gecodeerd hebt. Code die je gelinkt hebt: software‑bill‑of‑materials, uitgebreid tot cryptografische bill‑of‑materials, waar het CBOM‑werk echt nuttig is. Dingen die je gekocht of aangesloten hebt: netwerk‑observatie, want wat je systemen daadwerkelijk onderhandelen op het netwerk is de grondwaarheid en is vaak niet wat men dacht.

Wat agility betreft, het principe is simpel en de praktijk niet: het algoritme moet een configuratie‑beslissing zijn, geen code‑wijziging. Als het wijzigen van een cipher een ontwikkelaar, een build, een testcyclus en een release vereist, heb je geen agility. Je hebt een project. Centraliseer cryptografische operaties achter een interface die jij beheert, zodat er één plek is om te wijzigen in plaats van vierhonderd.

En dan het deel dat bijna iedereen overslaat: oefen het. Agility die je nooit hebt gebruikt is een bewering, geen capaciteit. Kies een rustig weekend, schakel een algoritme uit in een niet‑productieomgeving, en kijk wat er breekt. Er zal iets breken. Beter om het op je eigen schema te ontdekken dan tijdens een gedwongen nood‑migratie.

Een nuttige drijfveer is de certificaatlevensduur. De industrie beweegt naar drastisch kortere certificaten, waardoor handmatig beheer onhoudbaar wordt en automatisering afdwingt die je toch nodig had. Als je certificaatuitgifte en rotatie goed automatiseert, heb je het grootste deel van de infrastructuur gebouwd die een toekomstige algoritme‑overgang nodig heeft.

AI verandert zowel de verdediging in cybersecurity als de mogelijkheden van aanvallers. Waar denkt u dat AI echt de beveiligingsvergelijking verandert, en waar denkt u dat organisaties zich te veel op de technologie richten terwijl ze meer fundamentele zwaktes over het hoofd zien?

AI verandert echt één ding, en ik kan er direct over spreken omdat het ons is overkomen.

Een aanzienlijk aantal kwetsbaarheden dat dit jaar in OpenSSL werd bekendgemaakt, werd gevonden door AI‑gedreven analyse. In januari brachten we een release uit met twaalf issues, vrijwel allemaal van één onderzoeksgroep die geautomatiseerde analyse gebruikte, en zij leverden patches bij de rapporten. In juni repareerden we een high‑severity use‑after‑free in PKCS#7‑verificatie gevonden door een onderzoeker die met een AI‑systeem werkte. Dat is een echte capaciteitsverandering in het vinden van geheugen‑veiligheids‑ en parse‑bugs in volwassen C‑code die al jaren door experts is gereviewd. Ik heb hetzelfde patroon gezien in andere cryptografische bibliotheken. Bij het analyseren van een reeks Bouncy Castle CVE’s van dit jaar is de vingerafdruk van geautomatiseerde code‑analyse duidelijk.

De voor de hand liggende implicatie is dat dit twee kanten op werkt. Dezelfde technieken zijn beschikbaar voor iedereen die ze wil gebruiken, op dezelfde codebases, en verdedigers hebben geen exclusieve toegang.

De minder voor de hand liggende implicatie, en die ik wil benadrukken, is de last die het legt op maintainers. Het genereren van een plausibel‑uitziend kwetsbaarheidsrapport is nu bijna gratis. Het triagen ervan is dat niet. Het kost nog steeds een menselijke expert echte tijd. Open‑source‑beveiligingsteams, die meestal klein en vaak vrijwilligers zijn, krijgen een toenemend volume aan rapporten van sterk variërende kwaliteit. De goede, zoals het onderzoek dat ik noemde, komen met reproducerende testcases en patches. De slechte zijn een denial‑of‑service‑aanval op de mensen van wie je afhankelijk bent. Als uw organisatie AI inzet tegen open‑source‑code, financier dan de triage‑capaciteit aan de andere kant.

Waar ik denk dat de aandacht verkeerd ligt: AI patcht uw systemen niet. Het inventoryt uw assets niet, roteert uw referenties niet, vervangt uw verouderde hardware niet, of maakt iemand verantwoordelijk voor het certificaat dat volgende maand verloopt. Organisaties die AI‑beveiligings‑tools kopen terwijl ze software draaien met bekende ongerepareerde kwetsbaarheden, hebben hun volgorde verkeerd. Het onaantrekkelijke werk is nog steeds waar het risico zit.

Veel organisaties investeren zwaar in tools maar blijven kwetsbaar door configuratiefouten, verouderde systemen, zwakke processen of slechte incidentvoorbereiding. Wat zijn de meest ingrijpende beveiligingsfouten die u nog steeds ziet, en wat moeten leiders in place hebben voordat een aanval daadwerkelijk plaatsvindt?

De meest ingrijpende fout is beveiliging behandelen als een inkoopactiviteit. Tools worden aangeschaft, budgetten gehaald, dashboards zijn groen, en niemand heeft gevraagd of de organisatie de fundamentele zaken daadwerkelijk kan uitvoeren.

De tweede is niet weten wat u draait. U kunt geen software patchen die u niet weet te hebben, en de meeste organisaties ontdekken de ware inhoud van hun omgeving pas tijdens een incident. Daarom is het bill‑of‑materials‑werk belangrijk, niet als een compliance‑artefact maar als het ding dat u om twee uur ’s ochtends pakt wanneer een kritieke advisory valt en iemand vraagt of u getroffen bent.

De derde is standaardinstellingen. Systemen worden geïnstalleerd, ze werken, en de configuratie wordt nooit opnieuw bekeken. Vijf jaar later is die configuratie een aansprakelijkheid, en niemand die bij de oorspronkelijke beslissing betrokken was, werkt er nog.

De vierde is sleutel‑ en certificaatbeheer dat bij individuen wordt gelaten. Een opmerkelijk groot deel van zelf‑opgewekte storingen zijn verlopen certificaten die één persoon stilletjes bijhield in een spreadsheet tot hij van baan veranderde.

Voor een incident heeft het leiderschap vier zaken nodig. Een benoemde besluitvormer met de autoriteit om het bedrijf offline te halen, vooraf bepaald en schriftelijk, omdat het debat over wie die autoriteit heeft, niet live moet worden gevoerd. Retainers al ondertekend met externe forensische en specialistische adviseurs, want die inkoop duurt weken en u heeft uren. Een communicatieskanaal dat niet afhankelijk is van de systemen die mogelijk gecompromitteerd zijn. En een herstelcapaciteit die daadwerkelijk end‑to‑end is getest, niet een back‑upregime dat alleen is geverifieerd in de zin dat de taken succesvol zijn voltooid.

Daarna oefen het. Een tabletop‑oefening op directieniveau, eenmaal per jaar, zal meer echte hiaten blootleggen dan nog een tool.

Wanneer een ernstige cyberaanval plaatsvindt, kunnen executives plotseling technische, juridische, operationele en communicatieve beslissingen moeten nemen onder enorme druk. Wat onderscheidt organisaties die effectief reageren van diegenen die een incident aanzienlijk erger laten worden?

De organisaties die het goed afhandelen, hebben de belangrijke beslissingen al vóór het incident genomen, zodat ze tijdens het incident uitvoeren in plaats van overleggen. Dat is het grootste deel.

Naast voorbereiding scheiden een paar zaken consequent goede reacties van slechte.

Zij scheiden het technische onderzoek van de executive‑ en communicatietrack, met een gedefinieerde interface ertussen. Wanneer dezelfde mensen zowel een inbraak proberen te beperken als een klantmelding opstellen, worden beide taken slecht uitgevoerd.

Zij bewaren bewijsmateriaal voordat ze herstellen. De drang om de gecompromitteerde machine onmiddellijk opnieuw op te bouwen is sterk en vernietigt de informatie die u nodig heeft om de reikwijdte vast te stellen. Als u niet kunt beantwoorden “wat hebben ze nog meer aangeraakt”, kunt u niemand geloofwaardig vertellen dat het incident voorbij is.

Zij accepteren dat vroege informatie voorlopig is en communiceren dienovereenkomstig. Het grootste deel van de reputatieschade die ik heb waargenomen kwam niet door de inbreuk zelf, maar door zelfverzekerde vroege uitspraken die later moesten worden ingetrokken. Zeggen “dit is wat we weten, dit is wat we nog niet weten, dit is wanneer we u updaten” is geen zwakte. Het is de enige positie die u niet hoeft terug te draaien.

En cruciaal: ze creëren omstandigheden waarin engineers slecht nieuws aan executives kunnen vertellen. Het patroon dat ik het vaakst zie, is een organisatie waar de juridische blootstelling zo evident is dat niemand de persoon wil zijn die opschrijft wat er daadwerkelijk is gebeurd. Het incident wordt dan in stilte erger. Als uw engineers hun eigen aansprakelijkheid beheren in plaats van het incident, heeft u een governance‑probleem dat geen enkele tool kan oplossen.

OpenSSL bevindt zich in een ongebruikelijke positie als kritieke open‑source‑infrastructuur die door het hele technologische ecosysteem wordt gebruikt, terwijl OpenSSL Corporation zich richt op het bedienen van commerciële gemeenschappen naast de onafhankelijk opererende OpenSSL Foundation. Hoe balanceert u de behoeften van ondernemingen, ontwikkelaars, regelgevers en de bredere open‑source‑gemeenschap wanneer beslissingen over beveiliging en compatibiliteit zo’n groot deel van het internet kunnen beïnvloeden?

Het eerlijke antwoord is dat u ze niet balanceert door iedereen bij elke beslissing tevreden te stellen. U balanceert ze door een gepubliceerd beleid te hebben en dit voorspelbaar toe te passen, zodat mensen rond u kunnen plannen, zelfs als ze een bepaalde uitkomst niet prettig vinden.

Voorspelbaarheid is wat we onze gebruikers verschuldigd zijn. We brengen functiereleases uit in april en oktober. We geven van tevoren aan welke release langetermijn‑stabiel is en tot wanneer. We kondigen belangrijke verwijderingen ruim van tevoren aan. De ENGINE‑verwijdering in 4.0 werd publiekelijk maanden voor de release beschreven, en overeengekomen door zowel de Corporation als de Foundation. Iedereen die er in april verrast door was niet oplettend, en wij hadden het zo gemakkelijk mogelijk gemaakt om alert te blijven.

Het structurele antwoord is de scheiding zelf. De Foundation bestaat om de open‑source‑bibliotheek en de gemeenschap eromheen te dienen. De Corporation bestaat om organisaties met commerciële eisen (ondersteuningsverplichtingen, FIPS‑validatie, specifieke tijdlijnen) te bedienen en om het geheel financieel duurzaam te maken. Het gescheiden houden betekent dat geen van beide behoeften stilletjes in het voordeel van de ander wordt opgelost. Wanneer enterprise‑eisen en community‑eisen echt conflicteren, gebeurt dat conflict tussen twee organisaties met duidelijke mandaten in plaats van in het hoofd van één persoon.

Het andere deel is goed luisteren, wat echte mechanismen vereist in plaats van aannames. Dat is een groot deel van de reden waarom we de conferentie organiseren, die in oktober in Praag plaatsvindt, en waarom de community‑infrastructuur bestaat. Het is heel gemakkelijk voor maintainers om zelfverzekerde theorieën te ontwikkelen over wat gebruikers nodig hebben. Het is veel bruikbaarder om in een ruimte met hen te zijn.

Kijkend naar het komende decennium, welke beveiligings‑ of cryptografische transitie denkt u dat organisaties nog steeds onderschatten, en welke lessen uit de evolutie van SSL, OpenSSL en de afgelopen 30 jaar internetbeveiliging moeten leiders toepassen bij de voorbereiding?

De transitie die ik het meest onderschat zie, is niet post‑quantum‑cryptografie als een algoritme‑probleem. Het gaat om machine‑identiteit en de certificaathierarchie onder alles.

Post‑quantum‑sleuteluitwisseling zal grotendeels door standaardinstellingen worden opgelost, en veel daarvan is al gebeurd. Wat niet door standaardinstellingen wordt opgelost, is de vertrouwensinfrastructuur: root‑certificaten in hardware, firmware‑ondertekeningssleutels gebrand in apparaten, HSM’s met een decennium resterende levensduur, industriële en medische systemen die in 2040 nog steeds draaien met cryptografische aannames die bij de fabricage zijn ingebakken. Die kunnen niet worden bijgewerkt door een nieuwe bibliotheekversie te leveren, en in sommige gevallen kunnen ze helemaal niet worden bijgewerkt. De schaal van dat vervangingsprobleem wordt momenteel niet weerspiegeld in iemands kapitaalplanning.

Daarbij loopt een regelgevende transitie. De Cyber Resilience Act in Europa, en vergelijkbare kaders elders, zullen de verplichtingen wijzigen voor het leveren van software met componenten die u niet zelf heeft geschreven. De meeste organisaties hebben nog niet uitgewerkt wat dat betekent voor hun afhankelijkheid van open source, of voor de mensen die het onderhouden.

1. Overgangen duren een decennium langer dan aangekondigd. SSLv3 werd in 2015 afgeschaft, in 2016 standaard uitgeschakeld, en we verwijderden de code pas in april 2026. Dat is elf jaar, voor een protocol waarvan iedereen overeenkwam dat het gebroken was. Plan post‑quantum‑migratie op basis van die realiteit, niet op basis van het persbericht.
2. Standaardinstellingen zijn de enige beveiligingscontrole die op schaal werkt. Alles wat vereist dat elke beheerder een juiste beslissing neemt, zal niet gebeuren. De reden dat hybride post‑quantum‑sleuteluitwisseling zo snel is uitgerold, is dat het standaard ingeschakeld is en geen enkele beslissing vereist. Ontwerp voor de mensen die uw documentatie nooit zullen lezen, want dat is bijna iedereen.
3. U bent afhankelijk van minder mensen dan u denkt. Bijna elke organisatie op aarde vertrouwt op cryptografische code die wordt onderhouden door een zeer klein aantal individuen. Dat was zo toen het ons tweeën in Brisbane was, en de structuur is in wezen niet veranderd, zelfs niet nu de inzet met orders van grootte is gestegen. Wat u ook voor het komende decennium plant, een deel ervan rust op een maintainer die u nooit hebt gecontacteerd en die u niet financiert. Het is de moeite waard om dat te weten voordat u ze nodig heeft.

Dank u voor het geweldige interview. Lezers die meer willen weten, kunnen terecht op OpenSSL.