Tim Hudson, VD för OpenSSL Corporation – Intervjuserie

Tim Hudson är medförfattare till SSLeay och en av arrangörerna av OpenSSL Conference, Prag 13‑15 oktober 2026. Han har över 30 år av erfarenhet av system‑ och nätverkssäkerhet och är President för OpenSSL Corporation och Chief Technology Officer på Cryptsoft Pty Ltd. Sedan 1995 har hans arbete inkluderat medgrundandet av SSLeay med Eric Young, det kryptografiska biblioteket som blev OpenSSL Library, medgrundandet av RSA Security Australia‑utvecklingscentret, bidrag till förändringar i USA:s exportregler för kryptering, ledning av mer än 30 FIPS 140‑valideringar, medordförandeskap i OASIS KMIP‑ och SAM‑tekniska kommittéer samt tal på ledande säkerhetskonferenser, inklusive RSA Conference, AusCERT, ICMC, LinuxConf och OpenSSL Conference.

OpenSSL är ett globalt samarbetsprojekt med öppen källkod som utvecklar och underhåller OpenSSL Library, ett av världens mest använda kryptografiska bibliotek. Biblioteket används i operativsystem, molnplattformar, företagsprogramvara och anslutna enheter och hjälper till att skydda miljarder säkra onlinetransaktioner varje dag. Genom OpenSSL Foundation och OpenSSL Corporation är projektet engagerat i att främja pålitlig kryptografi, stödja hållbar utveckling av öppen källkod och stärka internets säkerhet.

Du medgrundade SSLeay med Eric Young 1995 efter att ha insett behovet av en icke‑amerikansk implementation av SSL, och det arbetet blev så småningom grunden för OpenSSL. Vilket problem försökte du ursprungligen lösa, och hade du någon aning då att tekniken skulle bli en så grundläggande del av internets säkerhet?

Problemet var helt konkret, och det var ett kommersiellt problem innan det var något annat. Jag jobbade på Mincom i Brisbane, och vi hade kunder som behövde säkra sina kommunikationer. Det fanns inget sätt att köpa den förmågan. Amerikanska exportkontroller för kryptografi innebar att amerikanska produkter antingen inte kunde levereras till oss alls eller kom med så starka nyckelstorlekar att deras användning skulle ha varit oärlig. Detta var inte ett filosofiskt motstånd mot exportpolitiken. Det var ett ingenjörsproblem där den komponent jag behövde inte fanns i någon form jag kunde köpa, och jag hade kunder som väntade.

Det jag hade var kunskap om något som de flesta hade glömt. Eric Young hade skrivit en DES‑implementation några år tidigare: bra, ren, fritt tillgänglig kod, skriven för sin egen skull och helt orelaterad till detta. Eric arbetade inte med SSL. Han var inte medveten om SSL. När Netscape publicerade specifikationen läste jag den, gick till Eric med problemet och presenterade det som ett relativt litet steg från där han redan var.

Det var inte hela bilden. Varje del var enkel men det fanns ett betydande antal delar. En DES‑implementation ger dig en symmetrisk chiffer. SSL kräver asymmetrisk kryptografi, godtycklig precisionsaritmetik, ASN.1, X.509‑certifikathantering och en protokoll‑tillståndsmaskin, med allt korrekt, för i kryptografi är nästan korrekt och trasig samma sak. Jag presenterade skalan optimistiskt. Eric insåg snart hur omfattande det var, och gillade det, för skalan visade sig vara attraktionen snarare än hindret. Jag är inte säker på att det skulle ha startat på annat sätt.

Han tog hand om den kryptografiska kärnan, vilket är anledningen till att biblioteket bär hans initialer. Jag tog hand om de delar som gör ett bibliotek till något andra faktiskt kan distribuera: applikationsintegration, testning, dokumentation och community‑delen. Jag sökte också aktivt upp alla konkurrerande krypteringsbibliotek som användes och konverterade eller ersatte dem. SSLtelnet, SSLftp, NCSA httpd och många andra paket var mitt arbete, applikationer byggda ovanpå de kryptografiska algoritmerna och protokollen Eric implementerade. Den kombinationen lät oss båda fokusera på det som faktiskt var intressant för oss, vilket jag tror är huvudorsaken till att projektet fortsatte.

Att vara i Australien gjorde det möjligt att lösa problemet, och sedan visade det sig att många andra hade exakt samma problem av exakt samma anledning. Något som byggdes för att möta ett specifikt kundkrav i Brisbane blev användbart för alla utanför USA, och så småningom även för många inom USA.

Visste vi vad det skulle bli? Nej. Ingen siktar på att bygga kritisk infrastruktur. Kritisk infrastruktur är vad du upptäcker att du har byggt några år senare, när du får reda på vem som är beroende av den. Vad vi trodde vi gjorde var att lösa ett problem framför oss och sedan svara på frågor från andra som stött på samma vägg. Delarna med att svara på frågor visade sig vara lika viktiga som koden.

Du har arbetat med kryptografi och internetsäkerhet i mer än tre decennier. Vad har förändrats mest dramatiskt i hotlandskapet under den perioden, och vilka säkerhetsproblem har förblivit förvånansvärt lika trots enorma tekniska framsteg?

Den största förändringen är att angripa system har blivit ett yrke med en ekonomisk modell bakom sig. På mitten av 1990‑talen bröt de flesta in i system för att det var intressant. Idag finns en industri, med specialisering, verktyg, leverantörskedjor, kundsupport och i vissa fall statlig finansiering. Det förändrar allt i hur du måste tänka, för du försvarar dig inte längre mot nyfikenhet. Du försvarar dig mot någon med en budget, en deadline och ett affärsfall.

Den andra förändringen är skala och beroende. Det genomsnittliga programmet 1995 var något du skrev själv. Det genomsnittliga programmet idag är något du sätter ihop, och majoriteten av koden i det har skrivits av personer du aldrig har träffat och inte kan namnge. Attackytan har flyttat från din kod till dina beroenden, och de flesta organisationer har inte anpassat sitt tänkande därefter.

Vad som har förblivit anmärkningsvärt konstant är felmoder. Vi skriver fortfarande buggar i kod som parsar opålitlig indata. Vi levererar fortfarande system med standardinställningar som ingen har granskat. Certifikat går fortfarande ut på en lördag. Referenser hamnar fortfarande på fel ställen. Och kryptografi bryts fortfarande nästan aldrig på den matematiska nivån. Det kringgås, felkonfigureras eller slås helt av. Om du hade gett mig en lista över de tio främsta grundorsakerna till intrång 1996 och en lista från förra månaden, skulle du ha svårt att skilja dem åt. Tekniken har förändrats fullständigt. Felen har inte gjort det.

OpenSSL 4.0 släpptes i april 2026, vilket markerar projektets första stora release på flera år. Vad säger den här releasen oss om vart kryptografisk infrastruktur är på väg, och vilka förändringar tror du kommer att vara viktigast för organisationer som är beroende av OpenSSL?

Det mest användbara att förstå med 4.0 är att det främst är en subtraktionsrelease, och det var poängen med den.

Vi tog bort ENGINE‑gränssnittet helt. Vi tog bort SSLv3 och SSLv2‑ClientHello. Vi inaktiverade föråldrade elliptiska kurvor och explicita EC‑kurvor vid kompilering. Vi gjorde ASN1_STRING opak och skärpte ett stort antal API‑signaturer. Det är dessa förändringar som skapar arbete för folk, och de är de som betyder något, för ett kryptografiskt bibliotek som bara ackumulerar kan inte förbli säkert. Varje föråldrad kodväg du behåller levande är en attackyta som någon underhåller åt dig och ingen testar.

Det finns tillägg: Encrypted Client Hello, stöd för RFC 8998 inklusive den hybrida SM2/ML‑KEM‑gruppen, cSHAKE, SNMP‑ och SRTP‑KDF:er, förhandlad FFDHE för TLS 1.2. ECH i synnerhet stänger ett verkligt integritetsgap, eftersom Server Name Indication har läckt identiteten på varje webbplats du besöker sedan TLS 1.3 släpptes. Men borttagningarna är historien.

Det viktigaste jag vill att organisationer ska ta med sig är detta: 4.0 är inte LTS‑releasen. Den stöds till maj 2027. Den nuvarande långsiktiga stabila releasen är 3.5, som stöds till april 2030, och 3.5 har redan de post‑kvantum‑algoritmerna. Om du vill ha den senaste koden, kör 4.0. Om du vill ha ett stabilt mål som du kan bygga en femårs migrationsplan kring, kör 3.5. Att välja det högre numret bara för att det är högre är ett misstag som vi ser folk göra varje cykel.

Post‑kvantum‑kryptografi har gått från ett forskningsproblem till en migrationsutmaning, med OpenSSL som redan stödjer ML‑KEM, ML‑DSA och SLH‑DSA samt hybrid post‑kvantum‑nyckelutbyte. För affärsledare som tror att kvantdatorer fortfarande är för avlägsna för att oroa sig, vilka risker förbiser de idag?

Det vanligaste felet är att behandla detta som en fråga om när en kryptografiskt relevant kvantdator anländer. Det är fel variabel. Den rätta frågan är hur länge dina data måste förbli konfidentiella och hur lång tid din migration kommer att ta. Subtrahera den andra från den första så får du din faktiska deadline, och för många organisationer är den deadline redan passerad.

Krypterad trafik kan fångas idag och lagras för alltid. Om informationen har en tjugoårig känslighetsperiod (patientjournaler, personalfiler, immateriella rättigheter, diplomatiskt material, finansiella positioner), så behöver en motståndare inte en kvantdator nu. De behöver en i framtiden, och billig lagring under tiden. Det är inte en spekulativ attack; det är ett arkiveringsbeslut.

Den andra förbisedda faktorn är att migration inte är ett enskilt projekt. Nyckelutbyte är den enkla delen, och mycket av det sker redan: OpenSSL 3.5 gjorde hybrid post‑kvantum‑nyckelutbyte till TLS‑standard, så många organisationer använder redan post‑kvantum‑nyckelavtal utan att ha fattat ett beslut om det. Signaturer och certifikatshierarkin är den svåra delen, eftersom de involverar certifikatutfärdare, hårdvarurotor, firmware‑signeringsnycklar, hårdvarusäkerhetsmoduler och enheter med femton års livslängd som byggdes under antagandet att RSA skulle vara bra för alltid.

Den tredje faktorn är en begränsning som ingen budgeterar för: post‑kvantum‑signaturer är stora. En ML‑DSA‑65‑signatur är ungefär femtio gånger så stor som en ECDSA P‑256‑signatur, och SLH‑DSA är ännu större. Det bryter saker: handskakningsstorlekar, begränsade enheter, protokoll med hårdkodade fältgränser, satellit‑ och IoT‑länkar. Du upptäcker dessa problem genom testning, inte genom att läsa en standard.

En av utmaningarna med post‑kvantum‑migration är att organisationer kanske inte ens vet var kryptografi används i deras applikationer, infrastruktur, enheter och tredjepartsberoenden. Hur bör företag närma sig kryptografisk inventering och crypto‑agility så att nästa stora algoritm‑övergång inte blir en nödsituation?

Börja med en obekväm sanning: du kan inte bygga en kryptografisk inventering genom att skicka ett frågeformulär till dina leverantörer. Du får tillbaka en blandning av marknadsföringstext, ärlig osäkerhet och svar som var sanna för tre versioner sedan. Jag säger detta efter att ha tillbringat en hel del tid med att läsa hårdvaruleverantörers dokumentation i ett närliggande område, och klyftan mellan vad dokumentationen påstår och vad en produkt faktiskt gör är större än vad de flesta köpare antar.

Du måste titta. Det finns tre lager, och de kräver olika tekniker. Kod du skrev: statisk analys, beroendesökning och sökning efter algoritmidentifierare du hårdkodade för år sedan. Kod du länkat: mjukvarusammansättningslistor, utökade till kryptografiska sammansättningslistor, där CBOM‑arbetet verkligen är användbart. Saker du köpt eller anslutit till: nätverksobservation, för vad dina system faktiskt förhandlar på tråden är den faktiska sanningen och den är ofta inte vad någon trodde.

När det gäller agilitet är principen enkel men praktiken är inte: algoritmen bör vara ett konfigurationsbeslut, inte en kodändring. Om byte av chiffer kräver en utvecklare, en byggprocess, en testcykel och en release, har du ingen agilitet. Du har ett projekt. Centralisera kryptografiska operationer bakom ett gränssnitt du kontrollerar, så att det finns en plats att ändra i stället för fyra hundra.

Och sedan den del som nästan alla hoppar över: testa det. Agilitet du aldrig har använt är ett påstående, inte en förmåga. Välj en lugn helg, stäng av en algoritm i en icke‑produktionsmiljö och se vad som går sönder. Något kommer att göra det. Bättre att upptäcka det på din egen tidsplan än under en påtvingad nödmigration.

En användbar tvingande funktion är certifikatlivslängd. Branschen går mot dramatiskt kortare certifikat, vilket gör manuell certifikathantering ohållbar och tvingar fram den automatisering du ändå kommer att behöva. Om du automatiserar utfärdande och rotation av certifikat på rätt sätt har du byggt den största delen av maskineriet som en framtida algoritm‑övergång kommer att kräva.

AI förändrar både cybersäkerhetsförsvar och angriparnas möjligheter. Var tror du AI faktiskt förändrar säkerhetsbilden, och var tror du organisationer lägger för mycket fokus på tekniken medan de förbiser mer grundläggande svagheter?

AI förändrar faktiskt en sak, och jag kan tala om det direkt eftersom det har hänt oss.

Ett betydande antal av de sårbarheter som avslöjats i OpenSSL i år hittades av AI‑driven analys. I januari släppte vi en version som fixade tolv problem, i princip alla från en forskargrupp som använde automatiserad analys, och de bidrog med patchar tillsammans med rapporterna. I juni fixade vi en högseveritets use‑after‑free i PKCS#7‑verifiering som hittades av en forskare som arbetade med ett AI‑system. Det är en verklig förändring i förmågan att hitta minnessäkerhets‑ och parsingsbuggar i mogen C‑kod som har granskats av experter i åratal. Jag har sett samma mönster i andra kryptografiska bibliotek. När man analyserar en samling Bouncy Castle‑CVE:n från i år är avtrycket av automatiserad kodanalys tydligt.

Den uppenbara implikationen är att detta går åt båda hållen. Samma tekniker är tillgängliga för vem som vill använda dem, på samma kodbaser, och försvarare har inte exklusiv tillgång.

Den mindre uppenbara implikationen, och den jag vill betona, är bördan den lägger på underhållerna. Att generera en trovärdig sårbarhetsrapport är nu nästan gratis. Att triagera en är inte det. Det kostar fortfarande en mänsklig expert verklig tid. Open‑source‑säkerhetsteam, som vanligtvis är små och ofta volontära, absorberar en växande mängd rapporter av mycket varierande kvalitet. De bra, som den forskning jag nämnde, kommer med reproducerbara exempel och patchar. De dåliga är en denial‑of‑service‑attack mot de personer du är beroende av. Om din organisation använder AI mot öppen källkod, finansiera triageringskapaciteten på andra sidan.

Där jag tror att uppmärksamheten är felplacerad: AI patchar inte dina system. Det inventerar inte dina tillgångar, roterar inte dina referenser, pensionerar din föråldrade hårdvara eller gör någon ansvarig för certifikatet som går ut nästa månad. Organisationer som köper AI‑säkerhetsverktyg medan de kör programvara med kända ouppdaterade sårbarheter har fel sekvens. Det ohyggliga arbetet är fortfarande där risken ligger.

Många organisationer investerar kraftigt i verktyg men förblir sårbara på grund av konfigurationsmisstag, föråldrade system, svaga processer eller bristande incidentförberedelse. Vilka är de mest betydelsefulla säkerhetsmisstagen du fortfarande ser, och vad bör ledningsgrupper ha på plats innan en attack faktiskt inträffar?

Det mest betydelsefulla misstaget är att behandla säkerhet som en inköpsaktivitet. Verktyg köps, budgetar uppfylls, instrumentpaneler är gröna, och ingen har frågat om organisationen faktiskt kan göra de grundläggande sakerna.

Det andra är att inte veta vad du kör. Du kan inte patcha programvara du inte vet att du har, och de flesta organisationer upptäcker den verkliga omfattningen av sin miljö under en incident. Det är därför arbete med materiallistor är viktigt, inte som ett efterlevnadsartefakt utan som det du tar fram klockan två på morgonen när ett kritiskt säkerhetsmeddelande släpps och någon frågar om du är påverkad.

Det tredje är standardinställningar. System installeras, de fungerar, och konfigurationen ses aldrig över igen. Fem år senare är den konfigurationen en liability, och ingen som var med i det ursprungliga beslutet arbetar där längre.

Det fjärde är nyckel‑ och certifikathantering som lämnas åt individer. En anmärkningsvärd andel av självorsakade avbrott är utgångna certifikat som en person tyst följde i ett kalkylblad tills de bytte jobb.

Före en incident behöver ledningen fyra saker på plats. En utsedd beslutsfattare med befogenhet att stänga ner verksamheten, bestämd i förväg och skriftligt, eftersom argumentet om vem som har den befogenheten är inget du vill diskutera i realtid. Avtal med externa forensik- och specialistkonsulter som redan är undertecknade, eftersom den upphandlingen tar veckor och du har timmar. En kommunikationskanal som inte är beroende av de system som kan bli komprometterade. Och en återställningsförmåga som faktiskt har testats end‑to‑end, inte ett backup‑system som bara har verifierats i den meningen att jobben slutfördes framgångsrikt.

Och sedan öva det. En tabletop‑övning på ledningsnivå, en gång per år, avslöjar fler verkliga luckor än ett annat verktyg.

När en allvarlig cyberattack inträffar kan chefer plötsligt finna sig själva fatta tekniska, juridiska, operativa och kommunikationsbeslut under enorm press. Vad skiljer organisationer som svarar effektivt från de som låter en incident bli betydligt värre?

Organisationer som hanterar det väl har fattat de viktiga besluten innan incidenten, så att de under incidenten utför snarare än diskuterar. Det är det mesta.

Utöver förberedelser finns några saker som konsekvent skiljer bra svar från dåliga.

De separerar den tekniska undersökningen från den verkställande och kommunikationsspåret, med ett definierat gränssnitt mellan dem. När samma personer försöker både begränsa en intrång och skriva ett kundmeddelande, görs båda uppgifterna dåligt.

De bevarar bevis innan de åtgärdar. Drivkraften att omedelbart återuppbygga den komprometterade maskinen är stark och förstör den information som behövs för att fastställa omfattning. Om du inte kan svara på ”vad mer rörde de?”, kan du inte trovärdigt säga att incidenten är över.

De accepterar att tidig information är preliminär och kommunicerar därefter. Det mesta av det rykte‑skada jag har observerat kom inte från intrånget utan från självsäkra tidiga uttalanden som behövde dras tillbaka. Att säga ”detta är vad vi vet, detta är vad vi ännu inte vet, detta är när vi kommer att uppdatera er” är ingen svaghet. Det är den enda positionen du inte behöver vända.

Och kritiskt: de skapar förutsättningar där ingenjörer kan ge chefer dåliga nyheter. Det vanligaste misslyckandemönstret jag sett är en organisation där den juridiska exponeringen var så tydlig att ingen ville vara den som skrev ner vad som faktiskt hände. Incidenten förvärras då i tystnad. Om dina ingenjörer hanterar sitt eget ansvar snarare än incidenten har du ett styrningsproblem som ingen mängd verktyg kan lösa.

OpenSSL befinner sig i en ovanlig position som kritisk öppen‑källkods‑infrastruktur som används i hela teknikekosystemet, medan OpenSSL Corporation fokuserar på att betjäna kommersiella samhällen tillsammans med den självständigt drivna OpenSSL Foundation. Hur balanserar du behoven hos företag, utvecklare, regulatorer och det bredare open‑source‑samhället när beslut om säkerhet och kompatibilitet kan påverka så stor del av internet?

Det ärligt svar är att du inte balanserar dem genom att försöka göra alla nöjda i varje beslut. Du balanserar dem genom att ha en publicerad policy och tillämpa den förutsägbart, så att folk kan planera kring dig även när de ogillar ett visst resultat.

Förutsägbarhet är vad vi är skyldiga våra användare. Vi släpper funktionsreleaser i april och oktober. Vi säger i förväg vilken release som är långsiktigt stabil och tills när. Vi annonserar betydande borttagningar långt innan de sker. ENGINE‑borttagningen i 4.0 beskrevs offentligt månader före releasen, och godkändes både av Företaget och Stiftelsen. Den som blev förvånad i april hade inte hållit koll, och vi hade gjort det så enkelt som rimligt att hålla koll.

Det strukturella svaret är själva separationen. Stiftelsen finns för att tjäna det öppna biblioteket och communityn kring det. Företaget finns för att tjäna organisationer med kommersiella krav (supportåtaganden, FIPS‑validering, specifika tidslinjer) och för att göra hela saken finansiellt hållbar. Att hålla dessa skilda betyder att inget behov tyst löses till fördel för det andra. När företagskrav och community‑krav faktiskt konflikterar, sker konflikten mellan två organisationer med tydliga mandat snarare än i en persons huvud.

Den andra delen är att lyssna på rätt sätt, vilket kräver faktiska mekanismer snarare än antaganden. Det är en stor del av varför vi driver konferensen, som är i Prag i oktober, och varför community‑infrastrukturen finns. Det är mycket lätt för underhållare att utveckla självsäkra teorier om vad användarna behöver. Det är betydligt mer användbart att vara i ett rum med dem.

Ser du på nästa decennium, vilken säkerhets‑ eller kryptografisk övergång tror du organisationer fortfarande underskattar idag, och vilka lärdomar från SSL:s, OpenSSL:s och de senaste 30 årens internetsäkerhet bör ledare tillämpa när de förbereder sig för den?

Den övergång jag tror är mest underskattad är inte post‑kvantum‑kryptografi som ett algoritmproblem. Det är maskinidentitet och certifikatshierarkin under allt.

Post‑kvantum‑nyckelutbyte kommer i stor grad att lösas genom standardinställningar, och mycket av det redan har gjort. Vad som inte kommer att lösas genom standardinställningar är förtroende‑infrastrukturen: rotcertifikat i hårdvara, firmware‑signeringsnycklar brända i enheter, HSM:er med ett decennium kvar av service, industri‑ och medicinska system som fortfarande kommer att köras 2040 med kryptografiska antaganden inbäddade vid tillverkning. Dessa kan inte uppdateras genom att bara skicka en ny biblioteksversion, och i vissa fall kan de inte uppdateras alls. Skalan på det ersättningsproblemet reflekteras för närvarande inte i någon organisations kapitalplanering.

Samtidigt pågår en regulatorisk övergång. Cyber Resilience Act i Europa, och jämförbara ramverk på andra håll, kommer att förändra skyldigheterna kopplade till att leverera programvara med komponenter du inte har skrivit. De flesta organisationer har inte gått igenom vad det betyder för deras beroende av öppen källkod, eller för människorna som underhåller den.

1. Övergångar tar ett decennium längre än de annonseras. SSLv3 avskaffades 2015, inaktiverades som standard 2016, och vi tog slutligen bort koden i april 2026. Det är elva år för ett protokoll som alla eniga ansåg var trasigt. Planera post‑kvantum‑migration mot den verkligheten, inte mot pressmeddelandet.
2. Standardinställningar är den enda säkerhetskontrollen som fungerar i skala. Allt som kräver att varje administratör gör ett korrekt beslut kommer inte att ske. Anledningen till att hybrid post‑kvantum‑nyckelutbyte har distribuerats så snabbt är att det är på som standard och kräver inget beslut alls. Designa för de som aldrig kommer att läsa din dokumentation, för det är nästan alla.
3. Du är beroende av färre personer än du tror. Nästan varje organisation på jorden förlitar sig på kryptografisk kod som underhålls av ett mycket litet antal individer. Det var sant när det var två av oss i Brisbane, och strukturen har inte fundamentalt förändrats även när insatserna har ökat med flera storleksordningar. Vad du än planerar för nästa decennium, så vilar någon del av det på en underhållare du aldrig har kontaktat och som du inte finansierar. Det är bra att veta innan du behöver dem innan …

Tack för det fantastiska intervjun. Läsare som vill lära sig mer bör besöka OpenSSL.