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 se, että ei tiedä mitä juoksee. Et voi korjata ohjelmistoja, joita et tiedä sinulla olevan, ja useimmat organisaatiot löytävät omaisuutensa todellisen sisällön tapahtuman aikana. Tästä syystä materiaaliluettelotyöllä on merkitystä, ei vaatimustenmukaisuuden artefaktina, vaan asiana, johon kurotat kello kaksi yöllä, kun kriittinen neuvo putoaa ja joku kysyy, vaikuttaako se sinuun.

Kolmas on oletusarvot. Järjestelmät asennetaan, ne toimivat, eikä kokoonpanoa koskaan tarkastella uudelleen. Viisi vuotta myöhemmin tämä kokoonpano on vastuullinen, eikä kukaan alkuperäiseen päätökseen osallistunut edelleen työskentele siellä.

Neljäs on avainten ja varmenteiden hallinta, joka jätetään yksityishenkilöille. Huomattava osa itse aiheutetuista katkoksista on vanhentuneita todistuksia, joita yksi henkilö seurasi hiljaa laskentataulukosta, kunnes vaihtoi työpaikkaa.

Ennen tapahtumaa johtajuuden on oltava paikallaan neljä asiaa. Nimetty päätöksentekijä, jolla on valtuudet viedä yritys offline-tilaan, päätti etukäteen ja kirjallisesti, koska väittelyä siitä, kenellä on tämä valtuutus, ei halua elää. Kiinnittäjät ovat jo allekirjoittaneet ulkopuolisen oikeuslääketieteen ja asiantuntijan kanssa, koska hankinta kestää viikkoja ja sinulla on tunteja. Viestintäkanava, joka ei ole riippuvainen järjestelmistä, jotka saattavat vaarantua. Ja palautusominaisuus, joka on itse asiassa testattu päästä päähän, ei varmuuskopiointijärjestelmä, joka on vahvistettu vain siinä mielessä, että työt on suoritettu onnistuneesti.

Harjoittele sitten sitä. Pöytäharjoittelu johdon tasolla kerran vuodessa paljastaa enemmän aitoja aukkoja kuin toinen työkalu.

Kun vakava kyberhyökkäys tapahtuu, johtajat voivat yhtäkkiä huomata tekevänsä teknisiä, oikeudellisia, operatiivisia ja viestintäpäätöksiä valtavan paineen alla. Mikä erottaa organisaatiot, jotka reagoivat tehokkaasti, niistä, jotka antavat tapahtuman pahentua huomattavasti?

Asiaa hyvin hoitavat organisaatiot ovat tehneet tärkeät päätökset ennen tapahtumaa, joten tapahtuman aikana ne pikemminkin toteuttavat kuin harkitsevat. Se on suurin osa siitä.

Valmistelun lisäksi muutama asia erottaa johdonmukaisesti hyvät vastaukset huonoista.

Ne erottavat teknisen tutkinnan toimeenpano- ja viestintäpolusta, ja niiden välillä on määritelty rajapinta. Kun samat ihmiset yrittävät hillitä tunkeutumista ja laatia asiakasilmoituksen, molemmat työt tehdään huonosti.

He säilyttävät todisteet ennen kuin korjaavat. Vaisto rakentaa vaarantunut kone välittömästi uudelleen on voimakas ja tuhoaa tiedot, joita tarvitset laajuuden määrittämiseen. Jos et voi vastata “mihin muuhun he koskettivat”, et voi uskottavasti kertoa kenellekään, että tapaus on ohi.

He hyväksyvät, että varhaiset tiedot ovat alustavia ja kommunikoivat sen mukaisesti. Suurin osa havaitsemistani mainevaurioista ei johtunut rikkomuksesta vaan varhaisista varhaisista lausunnoista, jotka oli peruutettava. Sanominen “tässä on mitä tiedämme, tässä on mitä emme vielä tiedä, tässä on milloin päivitämme sinut” ei ole heikkous. Se on ainoa asento, jota sinun ei tarvitse peruuttaa.

Ja kriittisesti: ne luovat olosuhteet, joissa insinöörit voivat kertoa johtajille huonoja uutisia. Useimmiten näkemäni epäonnistumismalli on organisaatio, jossa oikeudellinen altistuminen oli niin ilmeistä, että kukaan ei halunnut olla se henkilö, joka kirjoitti ylös, mitä todella tapahtui. Tilanne pahenee sitten hiljaisuudessa. Jos insinöörisi hallitsevat omaa vastuutaan tapahtuman sijaan, sinulla on hallinto-ongelma, jota mikään työkalu ei korjaa.

OpenSSL on epätavallisessa asemassa kriittisenä avoimen lähdekoodin infrastruktuurina, jota käytetään kaikkialla teknologiaekosysteemissä, kun taas OpenSSL Corporation keskittyy palvelemaan kaupallisia yhteisöjä itsenäisesti toimivan OpenSSL Foundationin rinnalla. Miten tasapainotat yritysten, kehittäjien, sääntelijöiden ja laajemman avoimen lähdekoodin yhteisön tarpeita, kun turvallisuutta ja yhteensopivuutta koskevat päätökset voivat vaikuttaa niin suureen osaan Internetiä?

Rehellinen vastaus on, että et tasapainota niitä yrittämällä tehdä kaikki onnelliseksi jokaisessa päätöksessä. Tasapainotat ne julkaisemalla käytännöt ja soveltamalla sitä ennustettavasti, jotta ihmiset voivat suunnitella ympärillesi, vaikka he eivät pidä tietystä tuloksesta.

Ennustettavuus on se, mitä olemme käyttäjillemme velkaa. Toimitamme ominaisuusjulkaisut huhti- ja lokakuussa. Kerromme etukäteen, mikä julkaisu on pitkällä aikavälillä vakaa ja mihin asti. Ilmoitamme merkittävistä muutot hyvissä ajoin ennen niiden toteutumista. ENGINE-poisto 4.0: ssa kuvattiin julkisesti kuukausia ennen julkaisua, ja sekä Corporation että säätiö sopivat siitä. Kuka tahansa, joka oli yllättynyt siitä huhtikuussa, ei ollut kiinnittänyt huomiota, ja olimme tehneet siitä niin helppoa kuin pystyimme kiinnittämään huomiota.

Rakenteellinen vastaus on itse erottaminen. Säätiö on olemassa palvelemaan avoimen lähdekoodin kirjastoa ja sitä ympäröivää yhteisöä. Yhtiön tarkoituksena on palvella organisaatioita, joilla on kaupallisia vaatimuksia (tukisitoumukset, FIPS validointi, tietyt aikataulut) ja tehdä koko asiasta taloudellisesti kestävää. Näiden erojen pitäminen tarkoittaa, että kumpikaan tarpeista ei ratkea hiljaa toisen eduksi. Kun yrityksen vaatimukset ja yhteisön vaatimukset ovat aidosti ristiriidassa, konflikti tapahtuu kahden organisaation välillä, joilla on selkeät tehtävät, eikä yhden henkilön pään sisällä.

Toinen osa on oikea kuunteleminen, mikä vaatii pikemminkin todellisia mekanismeja kuin olettamuksia. Se on suuri osa siitä, miksi järjestämme konferenssin, joka on Prahassa lokakuussa, ja miksi yhteisön infrastruktuuri on olemassa. Ylläpitäjien on erittäin helppoa kehittää luotettavia teorioita käyttäjien tarpeista. On huomattavasti hyödyllisempää olla huoneessa heidän kanssaan.

Mitä seuraavaa vuosikymmentä tarkasteltaessa uskot organisaatioiden aliarvioivan yhä edelleen, mitä tietoturva- tai salausmuutoksia, ja mitä SSL: n, OpenSSL: n ja viimeisten 30 vuoden Internet-turvallisuuden kehityksestä saatuja kokemuksia johtajien tulisi soveltaa siihen valmistautuessaan?

Siirtymä, joka on mielestäni kaikkein aliarvioitu, ei ole kvantinkestävä kryptografia algoritmiongelmana. Se on koneen identiteetti ja varmennehierarkia kaiken alla.

Post-kvanttiavainten vaihto ratkaistaan ​​suurelta osin oletusarvoisesti, ja suuri osa siitä on jo ratkaistu. Mitä ei oletusarvoisesti ratkaista, on luottamusinfrastruktuuri: laitteiston juurivarmenteet, laitteisiin poltetut laiteohjelmiston allekirjoitusavaimet, HSM: t, joiden käyttöikä on jäljellä vuosikymmen, teollisuus- ja lääketieteelliset järjestelmät, jotka ovat käytössä vielä vuonna 2040 ja valmistuksessa on käytetty kryptografisia oletuksia. Niitä ei voi päivittää lähettämällä uutta kirjastoversiota, ja joissain tapauksissa niitä ei voi päivittää ollenkaan. Korvausongelman laajuus ei tällä hetkellä heijastu kenenkään pääomasuunnitteluun.

Samanaikaisesti sääntely muuttuu. Cyber ​​Resilience Act Euroopassa ja vastaavat puitteet muualla muuttavat velvoitteita, jotka liittyvät ohjelmistojen toimittamiseen komponenttien kanssa, joita et ole kirjoittanut. Useimmat organisaatiot eivät ole käyneet läpi, mitä tämä tarkoittaa riippuvuudelle avoimesta lähdekoodista tai sitä ylläpitäville ihmisille.

Kolme oppituntia kolmenkymmenen vuoden ajalta:

1. Siirtymät kestävät vuosikymmenen ilmoitettua kauemmin. SSLv3 poistettiin suosituksista vuonna 2015 ja käytöstä oletusarvoisesti vuonna 2016, ja poistimme sen koodin lopulta huhtikuussa 2026. Se on yksitoista vuotta protokollalle, jonka kaikki olivat yhtä mieltä olevan rikki. Suunnitelkaa siirtyminen kvantinkestävään salaukseen tämän todellisuuden, ei lehdistötiedotteen perusteella.
2. Oletusasetukset ovat ainoa laajassa mittakaavassa toimiva tietoturvakeino. Mikään, mikä edellyttää jokaisen ylläpitäjän tekevän oikean päätöksen, ei toteudu. Hybridimuotoinen kvantinkestävä avaintenvaihto on otettu käyttöön niin nopeasti siksi, että se on oletusarvoisesti käytössä eikä edellytä lainkaan päätöksiä. Suunnitelkaa ratkaisut ihmisille, jotka eivät koskaan lue dokumentaatiotanne, sillä heitä ovat lähes kaikki.
3. Olette riippuvaisia harvemmista ihmisistä kuin luulette. Lähes jokainen maailman organisaatio käyttää salauskoodia, jota ylläpitää hyvin pieni joukko ihmisiä. Näin oli jo silloin, kun meitä oli kaksi Brisbanessa, eikä rakenne ole olennaisesti muuttunut, vaikka panokset ovat kasvaneet useita kertaluokkia. Mitä tahansa suunnittelette seuraavalle vuosikymmenelle, osa siitä on sellaisen ylläpitäjän varassa, johon ette ole koskaan olleet yhteydessä ja jota ette rahoita. Se kannattaa tietää ennen kuin tarvitsette häntä.

Kiitos mahtavasta haastattelusta. Lukijoiden, jotka haluavat oppia lisää, kannattaa käydä OpenSSL.