Tim Hudson, Prezes OpenSSL Corporation – Seria wywiadów

Tim Hudson jest współautorem SSLeay i jednym z organizatorów OpenSSL Conference, Praga, 13‑15 października 2026. Ma ponad 30 lat doświadczenia w bezpieczeństwie systemów i sieci oraz pełni funkcję Prezesa OpenSSL Corporation i Dyrektora Technicznego w Cryptsoft Pty Ltd. Od 1995 roku jego praca obejmowała współzałożenie SSLeay razem z Ericem Youngiem – biblioteki kryptograficznej, z której wyewoluowała OpenSSL Library, współzałożenie centrum rozwoju RSA Security Australia, udział w zmianach amerykańskich przepisów eksportowych dotyczących szyfrowania, prowadzenie ponad 30 walidacji FIPS 140, współprzewodniczenie Komitetom Technicznym OASIS KMIP i SAM oraz wystąpienia na czołowych konferencjach bezpieczeństwa, w tym RSA Conference, AusCERT, ICMC, LinuxConf i OpenSSL Conference.

OpenSSL to globalny, współpracujący projekt open source, który rozwija i utrzymuje OpenSSL Library, jedną z najpowszechniej używanych na świecie bibliotek kryptograficznych. Wykorzystywana w systemach operacyjnych, platformach chmurowych, oprogramowaniu korporacyjnym i urządzeniach podłączonych do sieci, biblioteka OpenSSL pomaga codziennie chronić miliardy bezpiecznych interakcji online. Dzięki OpenSSL Foundation i OpenSSL Corporation projekt zobowiązuje się do rozwoju zaufanej kryptografii, wspierania zrównoważonego rozwoju open source oraz wzmacniania bezpieczeństwa Internetu.

Współzałożyłeś SSLeay z Ericem Youngiem w 1995 r., dostrzegając potrzebę nieamerykańskiej implementacji SSL, a ta praca ostatecznie stała się fundamentem OpenSSL. Jakim problemem pierwotnie chciałeś rozwiązać i czy w tamtym czasie miałeś pojęcie, że technologia może stać się tak fundamentalną częścią zabezpieczania Internetu?

Problem był całkowicie konkretny i najpierw miał charakter komercyjny. Pracowałem w Mincom w Brisbane i mieliśmy klientów, którym trzeba było zabezpieczyć komunikację. Nie było możliwości zakupu takiej funkcjonalności. Amerykańskie ograniczenia eksportowe dotyczące kryptografii oznaczały, że amerykańskie produkty albo nie mogły być nam dostarczone w ogóle, albo były dostępne jedynie z tak ograniczonymi rozmiarami kluczy, że ich wdrożenie byłoby nieuczciwe. Nie była to filozoficzna sprzeciw wobec polityki eksportowej, lecz problem inżynieryjny: potrzebny komponent po prostu nie istniał w żadnej formie, którą mógłbym zakupić, a klienci czekali.

Miałem jednak wiedzę o czymś, o czym większość ludzi zapomniała. Eric Young kilka lat wcześniej napisał implementację DES: dobrą, czystą, wolnodostępną kodową bazę, stworzoną dla samej przyjemności programowania i całkowicie niezwiązaną z tą kwestią. Eric nie pracował nad SSL. Nie znał SSL. Kiedy Netscape opublikowało specyfikację, przeczytałem ją, podszedłem do Erica z problemem i przedstawiłem go jako stosunkowo niewielki krok w stosunku do tego, co już miał.

To nie była pełna historia. Każda część była prosta, ale ich liczba była znaczna. Implementacja DES daje jeden szyfr symetryczny. SSL wymaga kryptografii klucza publicznego, arytmetyki o dowolnej precyzji, ASN.1, obsługi certyfikatów X.509 oraz maszyny stanów protokołu – i wszystko to musi być poprawne, bo w kryptografii „prawie poprawne” i „zepsute” to to samo. Przedstawiłem skalę projektu optymistycznie. Eric wkrótce zorientował się, jak duży jest zakres, i z zapałem się zaangażował, ponieważ to właśnie rozmiar okazał się przyciągającym czynnikiem, a nie przeszkodą. Nie jestem pewien, czy w innym wypadku projekt by się rozpoczął.

Eric zajął się rdzeniem kryptograficznym, dlatego biblioteka nosi jego inicjały. Ja zająłem się częścią, która zamienia bibliotekę w coś, co inni mogą faktycznie wdrożyć: integracją aplikacji, testowaniem, dokumentacją i stroną społecznościową. Aktywnie poszukiwałem wszędzie, gdzie używano konkurencyjnych bibliotek szyfrujących i zamieniałem je lub zastępowałem. SSLtelnet, SSLftp, NCSA httpd i wiele innych pakietów to moja praca, aplikacje zbudowane na bazie algorytmów i protokołów kryptograficznych zaimplementowanych przez Erica. To połączenie pozwoliło każdemu z nas skupić się na tym, co naprawdę nas interesowało – i jest to główny powód, dla którego projekt przetrwał.

Bycie w Australii umożliwiło rozwiązanie problemu, a potem okazało się, że wiele innych osób ma dokładnie ten sam problem z tych samych powodów. Coś stworzonego w odpowiedzi na konkretną potrzebę klienta w Brisbane stało się użyteczne dla wszystkich poza Stanami Zjednoczonymi, a w końcu także dla wielu wewnątrz nich.

Czy wiedzieliśmy, czym to będzie? Nie. Nikt nie zamierza budować krytycznej infrastruktury. Krytyczna infrastruktura to coś, co odkrywasz dopiero po kilku latach, kiedy dowiadujesz się, kto na niej polega. My myśleliśmy, że rozwiązujemy bieżący problem, a potem odpowiadamy na pytania innych, którzy natrafili na ten sam mur. Ta część „odpowiadania na pytania” okazała się równie ważna, co kod.

Pracujesz w kryptografii i bezpieczeństwie Internetu od ponad trzech dekad. Co zmieniło się najbardziej dramatycznie w krajobrazie zagrożeń w tym okresie i które problemy bezpieczeństwa pozostały zaskakująco podobne pomimo ogromnych postępów technologicznych?

Największą zmianą jest to, że atakowanie systemów stało się profesją z własnym modelem ekonomicznym. W połowie lat 90. osoby włamujące się do systemów robiły to głównie dlatego, że było to interesujące. Dziś istnieje cała branża, z wyspecjalizowaniem, narzędziami, łańcuchami dostaw, wsparciem klienta i w niektórych przypadkach finansowaniem państwowym. To zmienia wszystko, co trzeba brać pod uwagę, bo nie broni się już przed ciekawością, lecz przed kimś z budżetem, terminem i uzasadnieniem biznesowym.

Drugą zmianą jest skala i zależność. Średnia aplikacja w 1995 r. była czymś, co sam napisałeś. Średnia aplikacja dziś to coś, co złożyłeś, a większość kodu w niej napisana jest przez ludzi, których nigdy nie spotkałeś i nie możesz wymienić po imieniu. Powierzchnia ataku przeniosła się z twojego kodu na twoje zależności i większość organizacji nie dostosowała do tego swojego myślenia.

Co pozostało niezwykle stałe, to tryby awarii. Nadal piszemy błędy w kodzie, który parsuje nieufne dane wejściowe. Nadal wypuszczamy systemy z domyślnymi ustawieniami, które nikt nie przeglądał. Certyfikaty nadal wygasają w sobotę. Dane uwierzytelniające wciąż lądują w niewłaściwych miejscach. I kryptografia nadal prawie nigdy nie jest łamana na poziomie matematycznym. Jest omijana, źle konfigurowana lub po prostu wyłączona. Gdybyś podał mi listę dziesięciu głównych przyczyn naruszeń z 1996 r. i listę z zeszłego miesiąca, miałbyś trudność, by je odróżnić. Technologia przeszła całkowitą transformację. Błędy nie.

OpenSSL 4.0 został wydany w kwietniu 2026 r., będąc pierwszym dużym wydaniem projektu od kilku lat. Co to wydanie mówi nam o kierunku rozwoju infrastruktury kryptograficznej i które zmiany będą ostatecznie najważniejsze dla organizacji polegających na OpenSSL?

Najbardziej przydatną rzeczą do zrozumienia w wersji 4.0 jest to, że jest ona przede wszystkim wydaniem „odejmowania”, i właśnie o to w niej chodzi.

Całkowicie usunęliśmy interfejs ENGINE. Usunęliśmy SSLv3 oraz ClientHello SSLv2. Wyłączono przestarzałe krzywe eliptyczne i jawne krzywe EC w czasie kompilacji. Uczyniliśmy ASN1_STRING nieprzezroczystym i zaostrzyliśmy wiele sygnatur API. To są zmiany, które generują pracę dla ludzi i to są zmiany, które mają znaczenie, ponieważ biblioteka kryptograficzna, która jedynie się gromadzi, nie może pozostać bezpieczna. Każda przestarzała ścieżka kodu, którą utrzymujesz przy życiu, to powierzchnia ataku, którą ktoś utrzymuje w twoim imieniu i nikt nie testuje.

Dodano: Encrypted Client Hello, obsługę RFC 8998 w tym hybrydową grupę SM2/ML‑KEM, cSHAKE, KDF‑y SNMP i SRTP, negocjowane FFDHE dla TLS 1.2. ECH w szczególności zamyka prawdziwą lukę prywatności, ponieważ Server Name Indication od czasu wprowadzenia TLS 1.3 wycieka tożsamość każdej odwiedzanej witryny. Ale to usunięcia stanowią sedno.

Najważniejsze, co chciałbym, aby organizacje wyniosły, to: 4.0 nie jest wydaniem LTS. Jest wspierane do maja 2027 r. Obecnie długoterminowo stabilnym wydaniem jest 3.5, wspierane do kwietnia 2030 r., a 3.5 już zawiera algorytmy post‑kwantowe. Jeśli chcesz najnowszy kod, użyj 4.0. Jeśli potrzebujesz stabilnego celu, wokół którego możesz zbudować pięcioletni plan migracji, użyj 3.5. Wybieranie wyższej liczby tylko dlatego, że jest wyższa, to błąd, który widzimy w każdym cyklu.

Kryptografia post‑kwantowa przeszła od problemu badawczego do wyzwania migracyjnego, a OpenSSL już obsługuje ML‑KEM, ML‑DSA i SLH‑DSA oraz hybrydową wymianę kluczy post‑kwantową. Dla liderów biznesu, którzy zakładają, że komputery kwantowe są jeszcze zbyt odległe, aby się o nie martwić, jakie ryzyka pomijają dzisiaj?

Najczęstszy błąd to traktowanie tego jako pytania o moment, w którym pojawi się kryptograficznie istotny komputer kwantowy. To niewłaściwa zmienna. Prawidłowe pytanie brzmi: jak długo twoje dane muszą pozostać poufne i jak długo potrwa migracja? Odejmij drugi parametr od pierwszego i otrzymasz rzeczywisty termin, a dla wielu organizacji ten termin już minął.

Zaszyfrowany ruch może być dziś przechwycony i przechowywany w nieskończoność. Jeśli informacja ma dwudziestoletni horyzont wrażliwości (rekordy pacjentów, dokumenty personalne, własność intelektualna, materiały dyplomatyczne, pozycje finansowe), przeciwnik nie potrzebuje komputera kwantowego teraz. Potrzebuje go kiedyś, a w międzyczasie taniej pamięci masowej. To nie jest spekulacyjny atak; to decyzja operacyjna.

Drugą pomijaną kwestią jest to, że migracja nie jest jednym projektem. Wymiana kluczy to łatwa część, a wiele organizacji już to robi: OpenSSL 3.5 uczynił hybrydową wymianę kluczy post‑kwantowych domyślną w TLS, więc wiele podmiotów już używa post‑kwantowego uzgadniania kluczy, nie podjęwszy o tym decyzji. Podpisy i hierarchia certyfikatów to trudna część, ponieważ obejmują one urzędy certyfikacji, sprzętowe korzenie zaufania, klucze podpisujące firmware, moduły bezpieczeństwa sprzętowego oraz urządzenia o piętnastoletniej żywotności, które zostały zaprojektowane przy założeniu, że RSA będzie działać wiecznie.

Trzecią kwestią jest ograniczenie, na które nikt nie budżetuje: podpisy post‑kwantowe są duże. Podpis ML‑DSA‑65 ma rozmiar około pięćdziesięciokrotnie większy niż podpis ECDSA P‑256, a SLH‑DSA jest jeszcze większy. To łamie: rozmiary handshake’ów, urządzenia o ograniczonych zasobach, protokoły z sztywnymi limitami pól, łącza satelitarne i IoT. Te problemy odkrywa się poprzez testy, nie poprzez czytanie standardu.

Jednym z wyzwań migracji post‑kwantowej jest to, że organizacje mogą nie wiedzieć, gdzie w ich aplikacjach, infrastrukturze, urządzeniach i zależnościach stron trzecich wykorzystywana jest kryptografia. Jak firmy powinny podchodzić do inwentaryzacji kryptograficznej i elastyczności kryptograficznej, aby kolejna duża zmiana algorytmiczna nie stała się sytuacją awaryjną?

Zacznij od niewygodnej prawdy: nie możesz zbudować inwentaryzacji kryptograficznej, wysyłając dostawcom ankietę. Otrzymasz mieszankę materiałów marketingowych, szczerej niepewności i odpowiedzi, które były prawdziwe trzy wydania temu. Mówię to, mając niedawno sporo czasu na czytanie dokumentacji dostawców sprzętu w pokrewnej dziedzinie, a rozbieżność między tym, co dokumentacja deklaruje, a tym, co produkt naprawdę robi, jest większa niż większość nabywców zakłada.

Trzeba spojrzeć. Są trzy warstwy i potrzebują różnych technik. Kod, który napisałeś: analiza statyczna, skanowanie zależności i wyszukiwanie identyfikatorów algorytmów, które zakodowałeś lata temu. Kod, który połączyłeś: listy materiałów oprogramowania, rozszerzone o listy materiałów kryptograficznych – to miejsce, gdzie praca nad CBOM jest naprawdę przydatna. Rzeczy, które kupiłeś lub podłączyłeś: obserwacja sieci, ponieważ to, co twoje systemy faktycznie negocjują na łączu, jest prawdą i często nie jest tym, w co wierzyło się w teorii.

Jeśli chodzi o elastyczność, zasada jest prosta, a praktyka nie: algorytm powinien być decyzją konfiguracyjną, nie zmianą kodu. Jeśli zmiana szyfru wymaga programisty, budowy, cyklu testowego i wydania, nie masz elastyczności. Masz projekt. Centralizuj operacje kryptograficzne za pośrednictwem interfejsu, którym sterujesz, tak by zmiana odbywała się w jednym miejscu, a nie w czterechset.

A potem część, którą prawie wszyscy pomijają: przetestuj to. Elastyczność, której nigdy nie użyłeś, to twierdzenie, nie zdolność. Wybierz spokojny weekend, wyłącz algorytm w środowisku nieprodukcyjnym i zobacz, co się zepsuje. Coś się zepsuje. Lepiej odkryć to w swoim harmonogramie niż w trakcie wymuszonej awaryjnej migracji.

Jedną z użytecznych funkcji wymuszających jest okres ważności certyfikatów. Branża przechodzi na znacznie krótsze certyfikaty, co czyni ręczne zarządzanie niepraktycznym i wymusza automatyzację, której i tak potrzebowałeś. Jeśli prawidłowo zautomatyzujesz wystawianie i rotację certyfikatów, zbudujesz większość mechanizmów, które będzie wymagała przyszła zmiana algorytmu.

Sztuczna inteligencja zmienia zarówno obronę cyberbezpieczeństwa, jak i możliwości atakujących. Gdzie twoim zdaniem AI naprawdę zmienia równanie bezpieczeństwa, a gdzie organizacje mogą zbytnio skupiać się na technologii, pomijając bardziej podstawowe słabości?

AI naprawdę zmienia jedną rzecz, i mogę o tym mówić z własnego doświadczenia.

Znaczna liczba luk ujawnionych w OpenSSL w tym roku została znaleziona dzięki analizie napędzanej AI. W styczniu wydaliśmy wersję naprawiającą dwanaście problemów, praktycznie wszystkie od jednej grupy badawczej korzystającej z automatycznej analizy, i dostarczyli oni poprawki wraz z raportami. W czerwcu naprawiliśmy poważny błąd typu use‑after‑free w weryfikacji PKCS#7, wykryty przez badacza pracującego z systemem AI. To prawdziwa zmiana zdolności w wykrywaniu błędów bezpieczeństwa pamięci i parsowania w dojrzałym kodzie C, który był przeglądany przez ekspertów przez lata. Zauważyłem podobny wzorzec w innych bibliotekach kryptograficznych. Analizując zestaw CVE Bouncy Castle z tego roku, wyraźnie widać odcisk automatycznej analizy kodu.

Oczywista konsekwencja jest taka, że to działa w dwie strony. Te same techniki są dostępne dla każdego, kto chce ich użyć, na tych samych bazach kodu, a obrońcy nie mają wyłącznego dostępu.

Mniej oczywista konsekwencja, którą chciałbym podkreślić, to obciążenie utrzymujących projekt. Generowanie wiarygodnie wyglądającego raportu o podatności jest dziś prawie darmowe. Ich triage nie jest. Wciąż wymaga czasu ludzkiego eksperta. Zespoły bezpieczeństwa open source, które zazwyczaj są małe i często wolontariackie, absorbują rosnącą liczbę raportów o bardzo zmiennej jakości. Dobre, jak wspomniane badania, przychodzą z reproduktorami i poprawkami. Złe są atakiem odmowy usługi na ludzi, od których zależy projekt. Jeśli twoja organizacja wdraża AI przeciwko kodowi open source, sfinansuj pojemność triage po drugiej stronie.

Gdzie, moim zdaniem, skupienie jest niewłaściwe: AI nie łata twoich systemów. Nie inwentaryzuje twoich zasobów, nie rotuje twoich poświadczeń, nie wycofuje nieobsługiwanego sprzętu ani nie pociąga nikogo do odpowiedzialności za certyfikat, który wygaśnie w przyszłym miesiącu. Firmy kupujące narzędzia AI do bezpieczeństwa, jednocześnie uruchamiające oprogramowanie z znanymi niezałatanymi podatnościami, mylą kolejność działań. Nieatrakcyjna, ale rzeczywista praca wciąż jest miejscem ryzyka.

Wiele organizacji intensywnie inwestuje w narzędzia, ale pozostaje podatnych z powodu błędów konfiguracyjnych, przestarzałych systemów, słabych procesów lub słabej gotowości na incydenty. Jakie są najpoważniejsze błędy bezpieczeństwa, które wciąż obserwujesz, i co zespoły zarządzające powinny mieć gotowe zanim atak faktycznie nastąpi?

Najpoważniejszy błąd to traktowanie bezpieczeństwa jako czynności zakupowej. Narzędzia są kupowane, budżety spełnione, panele kontrolne zielone, a nikt nie pyta, czy organizacja naprawdę potrafi wykonać podstawowe działania.

Drugi to nieznajomość własnego środowiska. Nie możesz łatać oprogramowania, którego nie wiesz, że posiadasz, a większość organizacji odkrywa prawdziwą zawartość swojego zasobu dopiero podczas incydentu. Dlatego praca nad listą materiałów ma znaczenie, nie jako artefakt zgodności, lecz jako rzecz, do której sięga się o 2 nad ranem, gdy wypada krytyczne ostrzeżenie i ktoś pyta, czy jesteś dotknięty.

Trzeci to domyślne ustawienia. Systemy są instalowane, działają i konfiguracja nigdy nie jest ponownie przeglądana. Pięć lat później ta konfiguracja jest zobowiązaniem, a nikt z pierwotnych decydentów już nie pracuje w firmie.

Czwarty to zarządzanie kluczami i certyfikatami pozostawione jednostkom. Zaskakująco duża liczba awarii spowodowanych jest wygasłymi certyfikatami, które jedna osoba śledziła w arkuszu kalkulacyjnym, aż do zmiany pracy.

Przed incydentem przywództwo potrzebuje czterech rzeczy. Osoby decyzyjnej z upoważnieniem do wyłączenia działalności, wyznaczonej z wyprzedzeniem i na piśmie, ponieważ spór o to, kto ma takie uprawnienia, nie jest pożądany w kryzysie. Zawarcie umów retencyjnych z zewnętrznymi firmami forensycznymi i specjalistycznymi doradcami, bo ich pozyskanie zajmuje tygodnie, a ty będziesz mieć godziny. Kanału komunikacji, który nie zależy od systemów mogących zostać skompromitowane. I możliwości przywrócenia, które faktycznie zostały przetestowane end‑to‑end, a nie jedynie systemu kopii zapasowych zweryfikowanego jedynie pod kątem pomyślnego zakończenia zadań.

Następnie przećwicz to. Ćwiczenie przy stole wśród kadry zarządzającej, raz w roku, ujawni więcej rzeczywistych luk niż kolejny kolejny zestaw narzędzi.

Kiedy dochodzi do poważnego cyberataku, kadra zarządzająca może nagle znaleźć się w sytuacji podejmowania decyzji technicznych, prawnych, operacyjnych i komunikacyjnych pod ogromną presją. Co odróżnia organizacje, które reagują skutecznie, od tych, które pozwalają incydentowi znacznie się pogorszyć?

Organizacje, które radzą sobie dobrze, podjęły kluczowe decyzje przed incydentem, więc w trakcie incydentu wykonują, a nie dyskutują. To w dużej mierze cała sprawa.

Poza przygotowaniem, kilka rzeczy konsekwentnie odróżnia dobre reakcje od złych.

Oddzielają dochodzenie techniczne od ścieżki zarządczej i komunikacyjnej, definiując wyraźny interfejs między nimi. Gdy te same osoby próbują jednocześnie powstrzymać włamanie i przygotować powiadomienie dla klientów, obie prace są wykonywane słabo.

Zachowują dowody przed naprawą. Instynkt natychmiastowego przywrócenia zhakowanego systemu jest silny i niszczy informacje potrzebne do określenia zakresu. Jeśli nie potrafisz odpowiedzieć „co jeszcze dotknęli”, nie możesz wiarygodnie powiedzieć, że incydent się zakończył.

Uznają, że wczesne informacje są prowizoryczne i komunikują to odpowiednio. Większość szkód reputacyjnych, które zaobserwowałem, wynika nie z samego wycieku, ale z pewnych wczesnych oświadczeń, które musiały zostać wycofane. Mówienie „oto co wiemy, oto czego jeszcze nie wiemy, oto kiedy damy kolejną aktualizację” nie jest słabością. To jedyna pozycja, której nie będziesz musiał odwracać.

Co najważniejsze: tworzą warunki, w których inżynierowie mogą przekazać kadrze złe wieści. Najczęstszy schemat niepowodzenia to organizacja, w której ryzyko prawne jest tak oczywiste, że nikt nie chce być osobą, która zapisze, co naprawdę się stało. Incydent wówczas pogarsza się w milczeniu. Jeśli twoi inżynierowie zarządzają własną odpowiedzialnością zamiast incydentem, masz problem zarządczy, którego żadne narzędzia nie naprawią.

OpenSSL znajduje się w nietypowej pozycji jako krytyczna infrastruktura open source używana w całym ekosystemie technologicznym, podczas gdy OpenSSL Corporation skupia się na obsłudze społeczności komercyjnych obok niezależnie działającej OpenSSL Foundation. Jak równoważysz potrzeby przedsiębiorstw, deweloperów, regulatorów i szerszej społeczności open source, gdy decyzje o bezpieczeństwie i kompatybilności mogą wpływać na tak dużą część Internetu?

Szczera odpowiedź brzmi, że nie równoważysz ich, starając się zadowolić wszystkich w każdej decyzji. Równoważysz je, mając opublikowaną politykę i stosując ją konsekwentnie, tak by ludzie mogli planować wokół ciebie, nawet jeśli nie podoba im się konkretny wynik.

Przewidywalność to to, co jesteśmy winni naszym użytkownikom. Wydajemy wydania funkcjonalne w kwietniu i październiku. Z góry informujemy, które wydanie jest długoterminowo stabilne i do kiedy. Ogłaszamy znaczące usunięcia z dużym wyprzedzeniem. Usunięcie ENGINE w wersji 4.0 zostało opisane publicznie miesiące przed wydaniem i uzgodnione zarówno przez Korporację, jak i Fundację. Każdy, kto był zaskoczony w kwietniu, nie zwracał uwagi, a my uczyniliśmy to tak łatwym, jak to rozsądnie możliwe.

Strukturalna odpowiedź to sama separacja. Fundacja istnieje, aby służyć bibliotece open source i społeczności wokół niej. Korporacja istnieje, aby obsługiwać organizacje z wymaganiami komercyjnymi (zobowiązania wsparcia, walidacje FIPS, konkretne terminy) i uczynić cały projekt finansowo zrównoważonym. Utrzymanie tych dwóch podmiotów odrębnie oznacza, że żadne z potrzeb nie jest dyskretnie rozwiązywane na niekorzyść drugiego. Gdy wymagania przedsiębiorstw i społeczności rzeczywiście kolidują, konflikt odbywa się pomiędzy dwoma organizacjami o wyraźnych mandatów, a nie w głowie jednej osoby.

Druga część to właściwe słuchanie, które wymaga rzeczywistych mechanizmów, a nie założeń. To duża część powodu, dla którego organizujemy konferencję, odbywającą się w Pradze w październiku, i dlaczego istnieje infrastruktura społecznościowa. Łatwo jest utrzymującym tworzyć pewne teorie o potrzebach użytkowników. Znacznie użyteczniejsze jest być w pokoju z nimi.

Patrząc na nadchodzącą dekadę, jaki przejściowy problem bezpieczeństwa lub kryptografii uważasz, że organizacje nadal niedoceniają, i jakich lekcji z ewolucji SSL, OpenSSL i ostatnich 30 lat bezpieczeństwa Internetu powinni zastosować liderzy przygotowując się na to wyzwanie?

Przejściem, które moim zdaniem jest najbardziej niedoceniane, nie jest kryptografia post‑kwantowa jako problem algorytmiczny. To tożsamość maszynowa i hierarchia certyfikatów leżąca pod wszystkim.

Post‑kwantowa wymiana kluczy zostanie w dużej mierze rozwiązana przez domyślne ustawienia i wiele już tak jest. Co nie zostanie rozwiązane domyślnie, to infrastruktura zaufania: certyfikaty root w sprzęcie, klucze podpisujące firmware wbudowane w urządzenia, HSM‑y z dziesięcioletnim okresem eksploatacji, systemy przemysłowe i medyczne, które będą działać w 2040 r. z założeniami kryptograficznymi wbudowanymi w proces produkcji. Nie można ich zaktualizować, po prostu wypuszczając nową wersję biblioteki, a w niektórych przypadkach w ogóle nie da się ich zaktualizować. Skala tego problemu wymiany nie jest obecnie odzwierciedlona w żadnym planowaniu kapitałowym.

Równolegle zachodzi przejście regulacyjne. Cyber Resilience Act w Europie i podobne ramy gdzie indziej zmienią obowiązki związane z dystrybucją oprogramowania zawierającego komponenty, których nie napisałeś. Większość organizacji nie przeanalizowała, co to oznacza dla ich zależności od open source i dla ludzi, którzy go utrzymują.

Trzy lekcje z trzydziestu lat:

1. Przejścia trwają dekadę dłużej niż zapowiadano. SSLv3 został wycofany w 2015 r., wyłączony domyślnie w 2016 r., a kod ostatecznie usunięto w kwietniu 2026 r. To jedenaście lat dla protokołu, co wszyscy uznali za zepsuty. Planuj migrację post‑kwantową wobec tej rzeczywistości, a nie wobec komunikatu prasowego.
2. Domyślne ustawienia to jedyne zabezpieczenie, które działa w skali. Wszystko, co wymaga od każdego administratora podjęcia poprawnej decyzji, nie zostanie zrealizowane. Powód, dla którego hybrydowa wymiana kluczy post‑kwantowych rozprzestrzeniła się tak szybko, to fakt, że jest włączona domyślnie i nie wymaga żadnej decyzji. Projektuj z myślą o ludziach, którzy nigdy nie przeczytają twojej dokumentacji, bo to prawie wszyscy.
3. Polegasz na mniejszej liczbie osób, niż myślisz. Prawie każda organizacja na świecie opiera się na kodzie kryptograficznym utrzymywanym przez bardzo małą liczbę osób. To było prawdziwe, gdy byliśmy we dwoje w Brisbane, i struktura nie zmieniła się zasadniczo, mimo że stawki wzrosły o rzędy wielkości. Cokolwiek planujesz na najbliższą dekadę, jakaś jej część opiera się na utrzymującym, z którym nigdy nie miałeś kontaktu i którego nie finansujesz. Warto to wiedzieć, zanim ich potrzebujesz.

Thank you for the great interview. Readers who wish to learn more should visit OpenSSL.