Tim Hudson, OpenSSL Corporationin toimitusjohtaja – Haastattelusarja

Tim Hudson on SSLeay:n yhteiskirjoittaja ja yksi OpenSSL Conference -tapahtuman järjestäjistä, Praha, 13–15 lokakuuta 2026. Hänellä on yli 30 vuoden kokemus järjestelmä- ja verkkoturvallisuudesta, ja hän on OpenSSL Corporationin presidentti sekä Cryptsoft Pty Ltd. Vuodesta 1995 lähtien hänen työnsä on sisältänyt SSLeay:n perustamisen yhdessä Eric Youngin kanssa, kryptografisen kirjaston, josta tuli OpenSSL Library, RSA Security Australia -kehityskeskuksen perustamisen, Yhdysvaltain salausvientisääntöjen muutoksiin vaikuttamisen, yli 30 FIPS 140 -validoinnin johtamisen, OASIS KMIP- ja SAM-tekniikkakomiteoiden yhteispuheenjohtamisen sekä puhumisen johtavilla turvallisuuskonferensseilla, kuten RSA Conference, AusCERT, ICMC, LinuxConf ja OpenSSL Conference.

OpenSSL on maailmanlaajuinen yhteistyöhön perustuva avoimen lähdekoodin projekti, joka kehittää ja ylläpitää OpenSSL Library -kirjastoa, yhtä maailman laajimmin käytetyistä kryptografisista kirjastoista. Käytettynä eri käyttöjärjestelmissä, pilvialustoilla, yritysohjelmistoissa ja yhdistetyissä laitteissa, OpenSSL Library auttaa suojaamaan miljardeja turvallisia verkkoyhteyksiä päivittäin. OpenSSL Foundationin ja OpenSSL Corporationin kautta projekti on sitoutunut edistämään luotettavaa kryptografiaa, tukemaan kestävää avoimen lähdekoodin kehitystä ja vahvistamaan internetin turvallisuutta.

Peristit SSLeay:n yhdessä Eric Youngin kanssa vuonna 1995 havaittuasi tarpeen ei‑Yhdysvaltain SSL‑toteutukselle, ja tuo työ lopulta muodostui OpenSSL:n perustaksi. Mikä ongelma alun perin oli ratkaistavana, ja tunsitko silloin, että teknologia voisi kasvaa näin keskeiseksi osaksi internetin suojaamista?

Ongelma oli täysin konkreettinen, ja se oli ensisijaisesti kaupallinen ennen kuin mitään muuta. Työskentelin Mincomilla Brisbane:ssa, ja meillä oli asiakkaita, jotka tarvitsivat viestintänsä suojaamista. Kyseistä ominaisuutta ei ollut mahdollista ostaa. Yhdysvaltain salausvientisäännökset tarkoittivat, että amerikkalaisia tuotteita ei voitu toimittaa meille lainkaan tai ne tulivat avainkokoina niin rajoitettuina, että niiden käyttöönotto olisi ollut epärehellistä. Tämä ei ollut filosofinen vastustus vientipolitiikkaa kohtaan. Kyseessä oli insinööritekninen ongelma, jossa tarvitsemaani komponenttia ei ollut saatavilla missään ostettavassa muodossa, ja asiakkaat odottivat.

Minulla oli kuitenkin tieto jostakin, jonka suurin osa oli unohtanut. Eric Young oli vuosia aiemmin kirjoittanut DES‑toteutuksen: hyvää, puhdasta, vapaasti saatavilla olevaa koodia, joka oli kirjoitettu omaksi ilokseen eikä millään tavalla liittynyt tähän. Eric ei työskennellyt SSL:n parissa eikä ollut tietoinen siitä. Kun Netscape julkaisi spesifikaation, luin sen, menin Ericin luo ongelman kanssa ja esitin sen melko vaatimattomana jatkumona siitä, missä hän jo oli.

Tämä ei ollut koko kuva. Jokainen osa oli suoraviivainen, mutta niitä oli merkittävä määrä. DES‑toteutus tarjoaa yhden symmetrisen salakirjoituksen. SSL vaatii julkisen avaimen kryptografiaa, mielivaltaisen tarkkuuden aritmetiikkaa, ASN.1:stä, X.509‑sertifikaattien käsittelyä ja protokollan tilakoneen, ja kaiken täytyy olla oikein, koska kryptografiassa lähes oikea ja rikottu ovat sama asia. Esitin sen mittakaavan optimistisesti. Eric tajusi pian, kuinka paljon sitä oli, ja nautti siitä, koska mittakaava osoittautui houkuttelevaksi eikä esteeksi. En ole varma, että se olisi alkanut toisin.

Hän hoiti kryptografisen ytimen, mistä johtuu, että kirjastossa on hänen alkukirjaimensa. Minä otin vastuulleni ne osat, jotka muuntavat kirjaston joksikin, mitä muut voivat todella ottaa käyttöön: sovellusintegraation, testauksen, dokumentaation ja yhteisöpuolen. Etsin myös aktiivisesti kaikkialta, missä kilpailija‑salauskirjasto oli käytössä, ja muutin tai korvasin sen. SSLtelnet, SSLftp, NCSA httpd ja monet muut paketit olivat minun työnäni, sovelluksia, jotka rakennettiin Ericin toteuttamien kryptografisten algoritmien ja protokollien päälle. Tämä yhdistelmä antoi kummallekin keskittyä siihen, mikä oli meille todella mielenkiintoista, ja uskon sen olevan tärkein syy sen jatkumiseen.

Australia oli se, mikä teki ratkaisun mahdolliseksi, ja kävi ilmi, että monilla muilla oli täsmälleen sama ongelma samasta syystä. Brisbane:ssa tiettyä asiakasvaatimusta varten rakennettu ratkaisu tuli hyödylliseksi kaikille Yhdysvaltojen ulkopuolella, ja lopulta myös monille niiden sisällä.

Tiesimmekö, mitä siitä tulisi? Ei. Kukaan ei pyri rakentamaan kriittistä infrastruktuuria. Kriittinen infrastruktuuri on se, jonka huomaat rakentaneesi vuosia myöhemmin, kun selviää, kuka siihen luottaa. Me ajattelimme ratkaisemme olevan juuri edessä oleva ongelma, ja sitten vastasimme muiden kysymyksiin, jotka olivat kohdanneet saman esteen. Kysymyksiin vastaaminen osoittautui yhtä tärkeäksi kuin koodi.

Olet työskennellyt kryptografian ja internet‑turvallisuuden parissa yli kolmen vuosikymmenen ajan. Mikä on muuttunut dramaattisimmin uhkakentässä tänä aikana, ja mitkä turvallisuusongelmat ovat säilyneet yllättävän samankaltaisina huolimatta valtavista teknologisista edistysaskelista?

Yksi suurimmista muutoksista on se, että järjestelmien hyökkääminen on muuttunut ammatiksi, jonka takana on taloudellinen malli. 1990‑luvun puolivälissä järjestelmiin murtautuvat tekivät sen pääosin siksi, että se oli mielenkiintoista. Nykyään on olemassa teollisuus, jossa on erikoistumista, työkaluja, toimitusketjuja, asiakastukea ja joissakin tapauksissa valtion rahoitusta. Tämä muuttaa kaikkea ajattelutapaa, koska et enää puolustaudu uteliaisuutta vastaan. Puolustat itse asiassa jotakuta, jolla on budjetti, aikataulu ja liiketoimintaperuste.

Toinen muutos on mittakaava ja riippuvuus. Keskimääräinen sovellus vuonna 1995 oli jotain, jonka itse kirjoitit. Nykyinen keskimääräinen sovellus on jotain, jonka koostat, ja suurin osa sen koodista on kirjoitettu ihmisiltä, joita et ole koskaan tavannut etkä voi nimetä. Hyökkäyspinta siirtyi omasta koodistasi riippuvuuksiin, eikä useimmat organisaatiot ole mukauttaneet ajatteluaan sen mukaisesti.

Mitä on pysynyt poikkeuksellisen vakiona, ovat epäonnistumismallit. Kirjoitamme edelleen bugeja koodiin, joka jäsentää epäluotettavaa syötettä. Julkaisemme edelleen järjestelmiä oletusasetuksilla, joita kukaan ei ole tarkistanut. Sertifikaatit vanhenevat edelleen lauantaina. Tunnistetiedot päätyvät edelleen paikkoihin, joissa niiden ei pitäisi olla. Kryptografiaa ei lähes koskaan murretaan matemaattisesti; sitä kiertää, se on virheellisesti konfiguroitu tai yksinkertaisesti ei ole otettu käyttöön. Jos olisit antanut minulle listan kymmenestä tärkeimmästä tietomurron perussyystä vuodelta 1996 ja toisen viime kuulta, sinulla olisi vaikeaa erottaa ne toisistaan. Teknologia on muuttunut täysin. Virheet eivät ole.

OpenSSL 4.0 julkaistiin huhtikuussa 2026, mikä merkitsi projektin ensimmäistä suurta julkaisua useiden vuosien jälkeen. Mitä tämä julkaisu kertoo kryptografisen infrastruktuurin suunnasta, ja mitkä muutokset mielestäsi ovat merkityksellisimpiä organisaatioille, jotka luottavat OpenSSL:ään?

Yksi hyödyllisimmistä asioista 4.0:ssa on se, että se on pääasiassa poistojulkaisu, ja juuri se oli sen tarkoitus.

Poistimme kokonaan ENGINE‑rajapinnan. Poistimme SSLv3:n ja SSLv2 ClientHello -viestin. Poistimme käytöstä vanhentuneet elliptiset käyrät ja eksplisiittiset EC‑käyrät käännösvaiheessa. Teimme ASN1_STRING‑rakenteesta läpinäkymättömän ja tiukensimme lukuisia API‑allekirjoituksia. Nämä ovat muutoksia, jotka aiheuttavat työtä ihmisille, ja ne ovat muutoksia, joilla on merkitystä, koska kryptografinen kirjasto, joka vain kerää ominaisuuksia, ei voi pysyä turvallisena. Jokainen ylläpidetty vanhentunut koodipolku on hyökkäyspinta, jonka joku ylläpitää puolestasi, eikä kukaan testaa sitä.

Lisäyksiä on: Encrypted Client Hello, RFC 8998 -tuki mukaan lukien hybridiryhmä SM2/ML‑KEM, cSHAKE, SNMP‑ ja SRTP‑KDF:t, neuvoteltu FFDHE TLS 1.2:lle. ECH erityisesti sulkee todellisen yksityisyysaukion, koska Server Name Indication on vuodattanut jokaisen käymäsi sivuston identiteetin TLS 1.3:n käyttöönotosta lähtien. Mutta poistot ovat tarinan ydin.

Haluan organisaatioiden ottavan tästä seuraavan pointin: 4.0 ei ole LTS‑julkaisu. Se saa tukea toukokuuhun 2027 asti. Nykyinen pitkäaikaisesti vakaa julkaisu on 3.5, jonka tuki jatkuu huhtikuuhun 2030, ja 3.5 sisältää jo post‑kvantti‑algoritmit. Jos haluat uusimman koodin, käytä 4.0:aa. Jos haluat vakaan kohteen, jonka ympärille voit rakentaa viiden vuoden migraatiosuunnitelman, käytä 3.5:aa. Korkeamman numeron valitseminen pelkästään sen perusteella, että se on korkeampi, on virhe, jonka näemme ihmisten tekevän jokaisessa syklissä.

Post‑kvanttinen kryptografia on siirtynyt tutkimusongelmasta migraatiohaasteeksi, ja OpenSSL tukee jo ML‑KEM‑, ML‑DSA‑ ja SLH‑DSA‑algoritmeja sekä hybridi‑post‑kvanttista avaintenvaihtoa. Mitkä riskit liiketoimintajohtajat, jotka olettavat kvanttilaskennan olevan vielä liian kaukana, jättävät huomiotta tänään?

Yleisin virhe on käsitellä tätä kysymyksenä siitä, milloin kryptografisesti merkityksellinen kvanttitietokone saapuu. Se on väärä muuttuja. Oikea kysymys on, kuinka kauan tietojesi täytyy pysyä luottamuksellisina ja kuinka kauan migraatio kestää. Vähennä toinen ensimmäisestä, niin saat todellisen määräaikasi, ja monille organisaatioille se määräaika on jo menneisyydessä.

Salattua liikennettä voidaan tänään kaapata ja säilyttää loputtomiin. Jos sen sisältämällä tiedolla on kaksikymmentä vuotta kestävä arkaluontoisuus (potilastiedot, henkilöstötiedostot, immateriaalioikeudet, diplomaattinen materiaali, taloudelliset asemat), hyökkääjä ei tarvitse kvanttitietokonetta juuri nyt. Hän tarvitsee sen lopulta, ja välimatkalla edullista tallennustilaa. Tämä ei ole spekulatiivinen hyökkäys; se on arkistointipäätös.

Toinen huomiosta puuttuva seikka on, että migraatio ei ole yksi projekti. Avainten vaihto on helppo osa, ja suuri osa siitä tapahtuu jo: OpenSSL 3.5 teki hybridipost‑kvanttisen avaintenvaihdon TLS‑oletusasetukseksi, joten monet organisaatiot käyttävät jo post‑kvanttista avaintenvaihtoa ilman, että ovat tehneet päätöstä siitä. Allekirjoitukset ja sertifikaattihierarkia ovat vaikeita, koska ne liittyvät sertifikaatti­virastoihin, laitteistopohjaisiin luottamusjuuriin, laiteohjelmistojen allekirjoitusavaimiin, HSM‑laitteisiin ja laitteisiin, joilla on viisitoista‑vuotinen käyttöikä ja jotka on rakennettu oletuksella, että RSA on ikuisesti riittävä.

Kolmas seikka on rajoitus, johon kukaan ei budjetoi: post‑kvanttiallekirjoitukset ovat suuria. ML‑DSA‑65‑allekirjoitus on noin viisikymmentä kertaa ECDSA P‑256‑allekirjoituksen koko, ja SLH‑DSA on vielä suurempi. Tämä rikkoo asioita: käsissävyt, rajoitetut laitteet, protokollat, joissa on kiinteästi koodatut kenttärajat, satelliitti‑ ja IoT‑yhteydet. Nämä ongelmat havaitaan testaamalla, ei standardia lukemalla.

Yksi post‑kvanttisen migraation haasteista on, että organisaatiot eivät ehkä tiedä kaikkialla, missä kryptografiaa käytetään sovelluksissaan, infrastruktuurissaan, laitteissaan ja kolmansien osapuolten riippuvuuksissa. Miten yritysten tulisi lähestyä kryptografista inventaariota ja kryptografiakuvaa, jotta seuraava suuri algoritmisiirtymä ei muutu hätätilanteeksi?

Aloita epämukavasta totuudesta: kryptografista inventaariota ei voi rakentaa lähettämällä toimittajille kyselylomake. Saat takaisin sekoituksen markkinointitekstiä, rehellistä epävarmuutta ja vastauksia, jotka olivat totta kolme julkaisua sitten. Sanon näin, koska olen äskettäin käyttänyt merkittävän määrän aikaa laitteistotoimittajien dokumentaation lukemiseen samankaltaisella alalla, ja dokumentaation väite- ja tuotteen todellisuuden välinen kuilu on laajempi kuin useimmat ostajat olettavat.

Sinun täytyy katsoa. Kolme tasoa, ja ne vaativat erilaisia tekniikoita. Kirjoittamasi koodi: staattinen analyysi, riippuvuuksien skannaus ja hakeminen algoritmi­tunnisteista, jotka koodasit vuosia sitten. Linkittämäsi koodi: ohjelmistojen materiaalilistat (SBOM), laajennettuina kryptografisiksi materiaalilistoiksi, missä CBOM‑työ on todellakin hyödyllistä. Ostoprosesseissa tai liitetyt laitteet: verkon havainnointi, koska se, mitä järjestelmäsi todella neuvottelee verkossa, on todellinen totuus, ja se poikkeaa usein siitä, mitä kukaan uskoo.

Ketteryys osalta periaate on yksinkertainen, mutta käytäntö ei ole: algoritmin tulisi olla konfiguraatiopäätös, ei koodimuutos. Jos salakirjoituksen vaihtaminen vaatii kehittäjän, käännöksen, testausjakson ja julkaisun, sinulla ei ole ketteryyttä. Sinulla on projekti. Keskitetään kryptografiset toiminnot hallitsemaasi rajapintaan, jotta muutokset tehdään yhdessä paikassa eikä neljäsataa eri paikkaa.

Ja sitten osa, jonka lähes kaikki ohittavat: testaa se. Ketteryys, jota et ole koskaan käyttänyt, on väite, ei kyky. Valitse hiljainen viikonloppu, poista algoritmi käytöstä ei‑tuotantoympäristössä ja katso, mikä rikkoontuu. Jokin rikkoontuu. Parempi havaita se omassa aikataulussasi kuin pakollisen hätätilanteen aikana.

Yksi hyödyllinen pakottava tekijä on sertifikaatin elinikä. Ala siirtyy kohtuullisen lyhytaikaisiin sertifikaatteihin, mikä tekee manuaalisesta sertifikaatin hallinnasta kestämättömän ja pakottaa automaation, jota olit muutenkin tarvitseva. Jos automatisoit sertifikaattien myöntämisen ja kierron kunnolla, olet rakentanut suurimman osan koneistosta, jonka tuleva algoritmisiirtymä vaatii.

AI muuttaa sekä kyberturvallisuuden puolustusta että hyökkääjien mahdollisuuksia. Missä uskot AI:n aidosti muuttavan turvallisuusyhtälöä, ja missä uskot organisaatioiden keskittyvän liikaa teknologiaan unohtaen perustavanlaatuiset heikkoudet?

AI muuttaa aidosti yhtä asiaa, ja voin puhua siitä suoraan, koska se on tapahtunut meille.

Merkittävä määrä OpenSSL:ssä tänä vuonna paljastuneista haavoittuvuuksista löytyi AI‑ohjatussa analyysissä. Tammikuussa julkaisemme version, jossa korjattiin kaksitoista ongelmaa, lähes kaikki yhdeltä tutkimusryhmältä, joka käytti automatisoitua analyysia, ja he toimittivat myös korjausohjelmat raporttien yhteydessä. Kesäkuussa korjasimme korkean vakavuuden käytön‑jälkeen‑vapautuksen PKCS#7‑todennuksessa, jonka löysi AI‑järjestelmää käyttävä tutkija. Tämä on todellinen kyvykkyyden muutos muistin‑safety‑ ja jäsentämisvirheiden löytämisessä kypsässä C‑koodissa, jota asiantuntijat ovat tarkistaneet vuosia. Olen nähnyt saman kaavan muissa kryptografisissa kirjastoissa. Analysoitaessa tämän vuoden Bouncy Castle CVE‑joukkoa, automatisoidun koodianalyysin jälki on selvä.

Ilmeinen seuraus on, että tämä hyödyttää molempia suuntia. Samat tekniikat ovat saatavilla kenelle tahansa, joka haluaa käyttää niitä, samoilla koodikannoilla, eikä puolustajilla ole eksklusiivista pääsyä.

Vähemmän ilmeinen seuraus, ja se, jonka korostaisin, on se, että se asettaa kuormituksen ylläpitäjille. Todennäköisen näköisen haavoittuvuusraportin luominen on nyt lähes ilmaista. Sen priorisointi ei ole. Se vaatii edelleen ihmisen asiantuntijan todellista aikaa. Avoimen lähdekoodin turvallisuustiimit, jotka ovat yleensä pieniä ja usein vapaaehtoisia, vastaanottavat kasvavan määrän raportteja, joiden laatu vaihtelee suuresti. Hyvät, kuten mainitsemani tutkimus, sisältävät reproduktioita ja korjauksia. Huonot ovat palvelunestohyökkäys niille, joihin luotat. Jos organisaatiosi käyttää AI:ta avoimen lähdekoodin koodiin, rahoita triage‑kapasiteettia toisaalla.

Mitä pidän huomiosta harhaanjohtavana: AI ei korjaa järjestelmiäsi. Se ei inventoi omaisuuttasi, kierrätä tunnistetietojasi, poisteta tukematonta laitteistoa tai tee ketään vastuulliseksi seuraavan kuukauden vanhenevan sertifikaatin osalta. Organisaatiot, jotka ostavat AI‑turvallisuustyökaluja ajettaessa ohjelmistoja, joilla on tiedossa olevia korjaamattomia haavoittuvuuksia, ovat väärässä järjestyksessä. Epäglamourinen työ on edelleen se, missä riski on.

Monet organisaatiot investoivat voimakkaasti työkaluihin, mutta pysyvät haavoittuvina konfiguraatiovirheiden, vanhentuneiden järjestelmien, heikkojen prosessien tai huonon tapahtumavalmiuden vuoksi. Mitkä ovat merkittävimmät turvallisuusvirheet, joita edelleen näet, ja mitä johtoryhmien tulisi olla valmiina ennen kuin hyökkäys tapahtuu?

Merkittävin virhe on käsitellä turvallisuutta hankintatoimintana. Työkalut ostetaan, budjetit täytetään, kojelaudat ovat vihreitä, eikä kukaan ole kysynyt, pystyykö organisaatio todella tekemään perustavanlaatuiset asiat.

Toinen on, ettei tiedä, mitä ajetaan. Et voi päivittää ohjelmistoa, jonka et tiedä omistavasi, ja useimmat organ