Tim Hudson, president i OpenSSL Corporation – Intervjuserie

Tim Hudson er medforfatter av SSLeay og en av arrangørene av OpenSSL Conference, Praha 13.–15. oktober 2026. Han har mer enn 30 års erfaring med system‑ og nettverkssikkerhet og er president i OpenSSL Corporation og Chief Technology Officer i Cryptsoft Pty Ltd. Siden 1995 har hans arbeid inkludert medstiftelse av SSLeay sammen med Eric Young, det kryptografiske biblioteket som ble OpenSSL Library, medstiftelse av RSA Security Australia‑utviklingssenteret, bidrag til endringer i amerikanske eksportregler for kryptering, ledelse av mer enn 30 FIPS‑140‑valideringer, medstyre i OASIS KMIP‑ og SAM‑tekniske komiteer, samt foredrag på ledende sikkerhetskonferanser, inkludert RSA Conference, AusCERT, ICMC, LinuxConf og OpenSSL Conference.

OpenSSL er et globalt samarbeidende åpen kildekode‑prosjekt som utvikler og vedlikeholder OpenSSL Library, et av verdens mest brukte kryptografiske biblioteker. Brukt på tvers av operativsystemer, skyplattformer, bedriftsprogramvare og tilkoblede enheter, hjelper OpenSSL Library med å beskytte milliarder av sikre nettinteraksjoner hver dag. Gjennom OpenSSL Foundation og OpenSSL Corporation er prosjektet forpliktet til å fremme pålitelig kryptografi, støtte bærekraftig åpen kildekode‑utvikling og styrke internettets sikkerhet.

Du medstiftet SSLeay sammen med Eric Young i 1995 etter å ha innsett behovet for en ikke‑amerikansk implementering av SSL, og dette arbeidet ble til slutt grunnlaget for OpenSSL. Hvilket problem prøvde du opprinnelig å løse, og hadde du på den tiden noen anelse om at teknologien kunne bli en så grunnleggende del av internett‑sikkerheten?

Problemet var helt konkret, og det var et kommersielt problem før det var noe annet. Jeg jobbet i Mincom i Brisbane, og vi hadde kunder som trengte å sikre kommunikasjonen sin. Det fantes ingen måte å kjøpe den funksjonaliteten på. Amerikanske eksportkontroller for kryptografi betydde at amerikanske produkter enten ikke kunne leveres til oss i det hele tatt, eller kom med nøkkelstørrelser så begrenset at implementering ville vært uærlig. Dette var ikke en filosofisk innvending mot eksportpolitikken. Det var et ingeniørproblem hvor komponenten jeg trengte ikke eksisterte i noen form jeg kunne kjøpe, og jeg hadde kunder som ventet.

Det jeg hadde, var kunnskap om noe de fleste hadde glemt. Eric Young hadde skrevet en DES‑implementasjon noen år tidligere: god, ren, fritt tilgjengelig kode, skrevet for sin egen skyld og fullstendig uavhengig av dette. Eric jobbet ikke med SSL. Han var ikke klar over SSL. Da Netscape publiserte spesifikasjonen, leste jeg den, gikk til Eric med problemet, og presenterte det som et relativt beskjedent steg fra der han allerede var.

Dette var ikke hele bildet. Hver del var enkel, men det var et betydelig antall deler. En DES‑implementasjon gir deg én symmetrisk cipher. SSL krever offentlig nøkkel‑kryptografi, aritmetikk med vilkårlig presisjon, ASN.1, X.509‑sertifikatbehandling og en protokoll‑tilstandsmaskin, alt korrekt, fordi i kryptografi er nesten korrekt og ødelagt det samme. Jeg hadde presentert omfanget optimistisk. Eric skjønte raskt hvor mye av det som var, og nøt det, fordi omfanget viste seg å være tiltrekningen snarere enn hindringen. Jeg er ikke sikker på om det ville ha startet på en annen måte.

Hans del var den kryptografiske kjernen, og derfor bærer biblioteket hans initialer. Jeg tok på meg delene som gjør et bibliotek til noe andre kan faktisk distribuere: applikasjonsintegrasjon, testing, dokumentasjon og fellesskapsdelen. Jeg søkte også aktivt etter steder hvor et konkurrerende krypteringsbibliotek ble brukt og konverterte eller erstattet det. SSLtelnet, SSLftp, NCSA httpd og mange andre pakker var mitt arbeid, applikasjoner bygget på de kryptografiske algoritmene og protokollene Eric implementerte. Denne blandingen lot hver av oss fokusere på det som faktisk var interessant for oss, noe jeg tror er hovedårsaken til at prosjektet fortsatte.

Det å være i Australia gjorde det mulig å løse problemet i det hele tatt, og så viste det seg at mange andre hadde nøyaktig det samme problemet av samme grunn. Noe som ble bygget for å møte et spesifikt kundekrav i Brisbane, ble nyttig for alle utenfor USA, og etter hvert også for mange innenfor USA.

Visste vi hva det ville bli? Nei. Ingen har som mål å bygge kritisk infrastruktur. Kritisk infrastruktur er det du oppdager at du har bygget, noen år senere, når du finner ut hvem som er avhengige av det. Det vi trodde vi gjorde, var å løse et problem foran oss og så svare på spørsmål fra andre som hadde støtt på samme vegg. Del­en med å svare på spørsmål viste seg å være like viktig som koden.

Du har jobbet med kryptografi og internett‑sikkerhet i mer enn tre tiår. Hva har endret seg mest dramatisk i trussellandskapet i den perioden, og hvilke sikkerhetsproblemer har forblitt overraskende like til tross for enorme teknologiske fremskritt?

Den største endringen er at angrep på systemer har blitt en profesjon med en økonomisk modell bak seg. På midten av nittitallet var de som brøt seg inn i systemer stort sett motivert av interesse. I dag finnes det en industri, med spesialisering, verktøy, forsyningskjeder, kundestøtte og i noen tilfeller statlig finansiering. Det endrer alt i hvordan du må tenke, fordi du ikke lenger forsvarer deg mot nysgjerrighet. Du forsvarer deg mot noen med budsjett, tidsfrist og forretningsgrunnlag.

Den andre endringen er skala og avhengighet. Den gjennomsnittlige applikasjonen i 1995 var noe du skrev selv. Den gjennomsnittlige applikasjonen i dag er noe du setter sammen, og flertallet av koden i den er skrevet av personer du aldri har møtt og ikke kan navngi. Angrepsflaten har flyttet seg fra din egen kode til dine avhengigheter, og de fleste organisasjoner har ikke tilpasset tenkningen sin deretter.

Det som har forblitt bemerkelsesverdig konstant, er feilmodusene. Vi skriver fortsatt feil i kode som parser upålitelig input. Vi leverer fortsatt systemer med standardinnstillinger som ingen har gått gjennom igjen. Sertifikater utløper fortsatt på en lørdag. Påloggingsinformasjon havner fortsatt på steder den ikke skal være. Og kryptografi blir fortsatt nesten aldri brutt på det matematiske nivået. Den blir omgått, feilkonfigurert eller rett og slett ikke aktivert. Hvis du ga meg en liste over de ti viktigste årsakene til brudd i 1996 og en liste fra forrige måned, ville du slite med å skille dem. Teknologien har endret seg fullstendig. Feilene har ikke gjort det.

OpenSSL 4.0 ble utgitt i april 2026, og markerer prosjektets første store utgivelse på flere år. Hva forteller denne utgivelsen oss om hvor kryptografisk infrastruktur er på vei, og hvilke endringer tror du vil være mest betydningsfulle for organisasjoner som er avhengige av OpenSSL?

Det mest nyttige å forstå med 4.0 er at den i hovedsak er en subtraksjonsutgivelse, og at dette var poenget med den.

Vi fjernet ENGINE‑grensesnittet helt. Vi fjernet SSLv3 og SSLv2‑ClientHello. Vi deaktiverte utdaterte elliptiske kurver og eksplisitte EC‑kurver ved kompilering. Vi gjorde ASN1_STRING opak og strammet inn et stort antall API‑signaturer. Dette er endringene som skaper arbeid for folk, og det er endringene som betyr noe, fordi et kryptografisk bibliotek som bare akkumulerer ikke kan forbli sikkert. Hver utdaterte kodevei du holder i live er en angrepsflate noen vedlikeholder på dine vegne, og ingen tester den.

Det er tillegg: Encrypted Client Hello, støtte for RFC 8998 inkludert den hybride SM2/ML‑KEM‑gruppen, cSHAKE, SNMP‑ og SRTP‑KDF‑er, forhandlet FFDHE for TLS 1.2. ECH lukker spesielt et reelt personvernshull, fordi Server Name Indication har lekket identiteten til hvert nettsted du besøker siden TLS 1.3 ble lansert. Men fjerningene er historien.

Det jeg vil at organisasjoner skal ta med seg, er dette: 4.0 er ikke LTS‑utgivelsen. Den støttes til mai 2027. Den nåværende langsiktige stabile utgivelsen er 3.5, støttet til april 2030, og 3.5 inneholder allerede post‑kvante‑algoritmene. Hvis du vil ha den nyeste koden, bruk 4.0. Hvis du vil ha et stabilt mål du kan bygge en femårs migrasjonsplan rundt, bruk 3.5. Å velge det høyere tallet bare fordi det er høyere, er en feil vi ser folk gjøre hver syklus.

Post‑kvante‑kryptografi har gått fra et forskningsproblem til en migrasjonsutfordring, og OpenSSL støtter allerede ML‑KEM, ML‑DSA og SLH‑DSA samt hybrid post‑kvante‑nøkkelutveksling. For bedriftsledere som antar at kvantedatamaskiner fortsatt er for langt unna til å bekymre seg, hvilke risikoer overser de i dag?

Den vanligste feilen er å behandle dette som et spørsmål om når en kryptografisk relevant kvantedatamaskin vil komme. Det er feil variabel. Det riktige spørsmålet er hvor lenge dataene dine må forbli konfidensielle, og hvor lang tid migrasjonen vil ta. Trekk den andre fra den første, så har du den faktiske fristen, og for mange organisasjoner er den fristen allerede passert.

Kryptert trafikk kan fanges i dag og lagres på ubestemt tid. Hvis informasjonen har en sensitivitetshorisont på tjue år (pasientjournaler, personalmapper, immateriell eiendom, diplomatisk materiale, finansielle posisjoner), trenger en motstander ikke en kvantedatamaskin nå. De trenger en en etter hvert, og billig lagring i mellomtiden. Det er ikke et spekulativt angrep; det er en lagringsbeslutning.

Det andre som overses, er at migrasjon ikke er ett prosjekt. Nøkkelutveksling er den enkle delen, og mye av den skjer allerede: OpenSSL 3.5 gjorde hybrid post‑kvante‑nøkkelutveksling til TLS‑standard, så mange organisasjoner bruker post‑kvante‑nøkkelavtale nå uten å ha tatt en beslutning om det. Signaturer og sertifikat‑hierarkiet er den vanskelige delen, fordi de involverer sertifiseringsmyndigheter, maskinvare‑roter av tillit, firmware‑signeringsnøkler, hardware security modules, og enheter med femten år i feltet som ble bygget med antakelsen om at RSA ville vare evig.

Det tredje er begrensningen ingen budsjetterer for: post‑kvante‑signaturer er store. En ML‑DSA‑65‑signatur er omtrent femti ganger størrelsen på en ECDSA P‑256‑signatur, og SLH‑DSA er enda større. Det bryter ting: håndtrykkstørrelser, begrensede enheter, protokoller med fastkodede feltgrenser, satellitt‑ og IoT‑lenker. Du oppdager disse problemene ved testing, ikke ved å lese en standard.

En av utfordringene med post‑kvante‑migrasjon er at organisasjoner kanskje ikke engang vet hvor kryptografi brukes i sine applikasjoner, infrastruktur, enheter og tredjepartsavhengigheter. Hvordan bør selskaper gå frem for kryptografisk inventar og kryptografisk smidighet slik at neste store algoritmeovergang ikke blir en nødsituasjon?

Start med en ubehagelig sannhet: du kan ikke bygge et kryptografisk inventar ved å sende leverandørene dine et spørreskjema. Du får tilbake en blanding av markedsføringsmateriale, ærlig usikkerhet og svar som var sanne for tre versjoner siden. Jeg sier dette etter å ha brukt betydelig tid nylig på å lese maskinvarellevandørdokumentasjon i et beslektet felt, og gapet mellom hva dokumentasjonen påstår og hva et produkt gjør, er større enn de fleste kjøpere antar.

Du må lete. Det er tre lag, og de krever ulike teknikker. Kode du skrev: statisk analyse, avhengighetsskanning og søk etter algoritme‑identifikatorer du hardkodet for år siden. Kode du lenket: programvare‑bill of materials, utvidet til kryptografiske bill of materials, hvor CBOM‑arbeidet virkelig er nyttig. Ting du kjøpte eller koblet til: nettverksobservasjon, fordi det systemene dine faktisk forhandler på ledningen er den faktiske sannheten, og den er ofte ikke det noen trodde.

Når det gjelder smidighet, er prinsippet enkelt, men praksisen er ikke det: algoritmen bør være en konfigurasjonsbeslutning, ikke en kodeendring. Hvis endring av en cipher krever en utvikler, en bygging, en testsyklus og en utgivelse, har du ikke smidighet. Du har et prosjekt. Sentraliser kryptografiske operasjoner bak et grensesnitt du kontrollerer, slik at det er ett sted å endre i stedet for fire hundre.

Og så er det delen nesten alle hopper over: prøv det. Smidighet du aldri har brukt er en påstand, ikke en evne. Velg en rolig helg, slå av en algoritme i et ikke‑produksjonsmiljø, og finn ut hva som bryter. Noe vil det. Det er bedre å oppdage det på din egen tidsplan enn under en pålagt nødovergang.

En nyttig tvangsfaktor er sertifikatlevetid. Bransjen går mot dramatisk kortere levetid på sertifikater, noe som gjør manuell sertifikatadministrasjon uholdbar og tvinger frem automatiseringen du uansett ville trenge. Hvis du automatiserer utstedelse og rotasjon av sertifikater på riktig måte, har du bygget mesteparten av maskineriet som en fremtidig algoritmeovergang vil kreve.

AI endrer både cybersikkerhetsforsvar og mulighetene tilgjengelige for angripere. Hvor tror du AI virkelig endrer sikkerhetslikningen, og hvor tror du organisasjoner fokuserer for mye på teknologien mens de overser mer grunnleggende svakheter?

AI endrer virkelig én ting, og jeg kan snakke om det direkte fordi det har skjedd med oss.

Et betydelig antall av sårbarhetene som ble offentliggjort i OpenSSL i år, ble funnet ved AI‑drevet analyse. I januar leverte vi en utgivelse som fikset tolv problemer, i hovedsak alle fra én forskningsgruppe som brukte automatisert analyse, og de bidro med rettelser sammen med rapportene. I juni fikset vi en høy‑prioritets use‑after‑free i PKCS#7‑verifisering funnet av en forsker som jobbet med et AI‑system. Det er en reell endring i evnen til å finne minnesikkerhets‑ og parsingsfeil i moden C‑kode som har blitt gjennomgått av eksperter i flere år. Jeg har sett samme mønster i andre kryptografiske biblioteker. Når man analyserer en batch med Bouncy Castle‑CVE‑er fra i år, er fingeravtrykket av automatisert kodeanalyse tydelig.

Den åpenbare implikasjonen er at dette går begge veier. De samme teknikkene er tilgjengelige for hvem som helst som vil bruke dem, på de samme kodebasene, og forsvarere har ikke eksklusiv tilgang.

Den mindre åpenbare implikasjonen, og den jeg vil understreke, er belastningen den pålegger vedlikeholdere. Å generere en plausibel sårbarhetsrapport er nå nesten gratis. Å triagere en er det ikke. Det koster fortsatt en menneskelig ekspert reell tid. Åpne kildekode‑sikkerhetsteam, som vanligvis er små og ofte frivillige, absorberer en økende mengde rapporter av svært variabel kvalitet. De gode, som forskningen jeg nevnte, kommer med reproduksjoner og rettelser. De dårlige er et denial‑of‑service‑angrep på menneskene du er avhengig av. Hvis organisasjonen din bruker AI mot åpen kildekode, finansier triage‑kapasiteten på den andre siden.

Hvor jeg tror oppmerksomheten er feilplassert: AI reparerer ikke systemene dine. Den lager ikke inventar over eiendelene dine, roterer påloggingsinformasjonen din, avvikler maskinvare som ikke støttes, eller gjør noen ansvarlig for sertifikatet som utløper neste måned. Organisasjoner som kjøper AI‑sikkerhetsverktøy mens de kjører programvare med kjente, urettede sårbarheter, har feil rekkefølge. Det lite glamorøse arbeidet er fortsatt der risikoen ligger.

Mange organisasjoner investerer tungt i verktøy, men forblir sårbare på grunn av konfigurasjonsfeil, utdaterte systemer, svake prosesser eller dårlig beredskap for hendelser. Hva er de mest betydningsfulle sikkerhetsfeilene du fortsatt ser, og hva bør lederteam ha på plass før et angrep faktisk inntreffer?

Den mest betydningsfulle feilen er å behandle sikkerhet som en innkjøpsaktivitet. Verktøy kjøpes, budsjetter oppfylles, dashbord er grønne, og ingen har spurt om organisasjonen faktisk kan gjøre de grunnleggende tingene.

Den andre er at man ikke vet hva man kjører. Du kan ikke oppdatere programvare du ikke vet at du har, og de fleste organisasjoner oppdager den faktiske sammensetningen av sin eiendom under en hendelse. Dette er grunnen til at arbeid med bill‑of‑materials er viktig, ikke som et etterlevelsesdokument, men som det du tar frem klokken to om natten når et kritisk varsel slippes og noen spør om du er berørt.

Den tredje er standardinnstillinger. Systemer blir installert, de fungerer, og konfigurasjonen blir aldri gjennomgått igjen. Fem år senere er den konfigurasjonen en forpliktelse, og ingen som var med i den opprinnelige beslutningen jobber der lenger.

Den fjerde er nøkkel‑ og sertifikatstyring overlatt til enkeltpersoner. En bemerkelsesverdig andel av selvpåførte driftsavbrudd er utløpte sertifikater som én person holdt stille i et regneark til de byttet jobb.

Før en hendelse trenger ledelsen fire ting på plass. En navngitt beslut