Тім Хадсон, Президент OpenSSL Corporation — Серія інтерв’ю

Tim Hudson — співавтор SSLeay та один з організаторів OpenSSL Conference, Прага, 13‑15 жовтня 2026 року. Має понад 30‑річний досвід у системній та мережевій безпеці, є президентом OpenSSL Corporation та головним технічним директором Cryptsoft Pty Ltd. З 1995 року його діяльність включає спіфонування SSLeay разом з Еріком Янгом, криптографічної бібліотеки, що стала OpenSSL Library, створення центру розробки RSA Security Australia, внесок у зміну американських правил експорту шифрування, керування більш ніж 30 валідаціями FIPS 140, співголосування технічних комітетів OASIS KMIP та SAM, а також виступи на провідних конференціях з безпеки, включаючи RSA Conference, AusCERT, ICMC, LinuxConf та OpenSSL Conference.

OpenSSL — це глобальний колаборативний проєкт з відкритим кодом, який розробляє та підтримує OpenSSL Library, одну з найширше використовуваних у світі криптографічних бібліотек. Використовується в операційних системах, хмарних платформах, корпоративному програмному забезпеченні та підключених пристроях, OpenSSL Library допомагає щодня захищати мільярди безпечних онлайн‑взаємодій. Через OpenSSL Foundation і OpenSSL Corporation проєкт зобов’язується розвивати довірену криптографію, підтримувати стале розроблення з відкритим кодом та зміцнювати безпеку інтернету.

Ви спіфонували SSLeay разом з Еріком Янгом у 1995 році, усвідомивши потребу у не‑американській реалізації SSL, і ця робота зрештою стала основою OpenSSL. Яку проблему ви спочатку намагалися вирішити і чи мали ви тоді уявлення, що ця технологія може стати настільки фундаментальною для забезпечення безпеки інтернету?

Проблема була цілком конкретною і спочатку комерційною. Я працював у Mincom у Брісбені, і у нас були клієнти, яким треба було захистити їхні комунікації. Не існувало способу придбати таку можливість. Експортний контроль США на криптографію означав, що американські продукти або взагалі не могли нам постачатися, або постачалися з розмірами ключів, настільки обмеженими, що їхнє використання було б нечесним. Це не була філософська заперечність щодо політики експорту. Це була інженерна проблема, коли потрібний мені компонент не існував у жодній формі, яку можна було б купити, а клієнти чекали.

У мене був знання про те, що більшість людей забули. Еріком Янгом кілька років тому була написана реалізація DES: хороший, чистий, вільно доступний код, створений сам по собі і повністю не пов’язаний із цим. Ерік не працював над SSL і не знав про нього. Коли Netscape опублікував специфікацію, я її прочитав, звернувся до Еріка з проблемою і представив її як відносно скромний крок від того, що він вже мав.

Це не була повна картина. Кожна частина була проста, проте їх було багато. Реалізація DES дає один симетричний шифр. SSL потребує криптографії з відкритим ключем, арифметики довільної точності, ASN.1, обробки сертифікатів X.509 та протокольної машини станів, і все це має бути правильним, бо в криптографії майже правильне і зламане — це одне й те саме. Я оптимістично представив масштаб роботи. Ерік швидко зрозумів, скільки всього треба, і отримав задоволення, бо саме масштаб став привабливістю, а не перешкодою. Я не впевнений, чи розпочалося б це іншим шляхом.

Він займався криптографічним ядром, тому бібліотека несе його ініціали. Я взяв на себе частини, які перетворюють бібліотеку на те, що інші можуть реально розгорнути: інтеграцію в застосунки, тестування, документацію та роботу з спільнотою. Я також активно шукав будь‑які місця, де використовувалась конкурентна бібліотека шифрування, і конвертував або заміняв її. SSLtelnet, SSLftp, NCSA httpd та багато інших пакетів — це моя робота, застосунки, побудовані на криптографічних алгоритмах і протоколах, які реалізував Ерік. Така комбінація дозволила кожному з нас зосередитися на тому, що нам дійсно цікаво, і, на мій погляд, це головна причина, чому проєкт продовжився.

Те, що ми були в Австралії, зробило можливим вирішення проблеми, а потім виявилось, що багато інших людей мали точно таку ж проблему з тієї ж причини. Те, що було створено для задоволення конкретного запиту клієнта в Брісбені, стало корисним для всіх поза межами Сполучених Штатів і зрештою для багатьох людей всередині них.

Чи знали ми, чим це стане? Ні. Ніхто не ставить за мету будувати критичну інфраструктуру. Критична інфраструктура — це те, що ви виявляєте, що створили, кілька років потому, коли розумієте, хто від неї залежить. Ми думали, що вирішуємо проблему, що стоїть перед нами, і відповідаємо на питання інших людей, які зіткнулися з тією ж перепоною. Частина з відповідями на питання виявилась такою ж важливою, як і код.

Ви працюєте у галузі криптографії та інтернет‑безпеки понад три десятиліття. Що змінилося найсильніше в ландшафті загроз за цей час і які проблеми безпеки залишились дивно схожими, незважаючи на величезний технологічний прогрес?

Найбільша зміна — це те, що атаки на системи стали професією з економічною моделлю. У середині дев’яностих більшість людей, які зламували системи, робили це, бо це було цікаво. Сьогодні існує індустрія зі спеціалізацією, інструментами, ланцюгами постачання, підтримкою клієнтів і в деяких випадках державним фінансуванням. Це змінює все, як треба мислити, бо ви більше не захищаєтеся від цікавості, а від когось з бюджетом, дедлайном і бізнес‑кейсом.

Друга зміна — масштаб і залежність. Середній застосунок у 1995 році був тим, що ви писали. Сьогодні середній застосунок — це те, що ви збираєте, а більшість коду в ньому написали люди, яких ви ніколи не зустрічали і не можете назвати. Поверхня атаки перемістилася від вашого коду до ваших залежностей, і більшість організацій не адаптували своє мислення відповідно.

Те, що залишилось надзвичайно стабільним, — це способи відмов. Ми все ще пишемо помилки в коді, що аналізує ненадійний ввід. Ми продовжуємо постачати системи з налаштуваннями за замовчуванням, які ніхто не переглядав. Сертифікати все ще закінчуються в суботу. Облікові дані все ще потрапляють у місця, де їх не повинно бути. І криптографія майже ніколи не зламується на рівні математики; її обходять, неправильно налаштовують або просто не вмикають. Якщо б ви дали мені список десяти головних причин порушень безпеки 1996 року і список за минулий місяць, ви б важко їх розрізнили. Технології повністю трансформувалися. Помилки залишились такими ж.

OpenSSL 4.0 був випущений у квітні 2026 року, позначаючи перший за кілька років великий реліз проєкту. Що цей реліз розповідає про майбутнє криптографічної інфраструктури і які зміни, на вашу думку, будуть найважливішими для організацій, що залежать від OpenSSL?

Найкорисніше, що треба зрозуміти про 4.0, — це те, що це переважно «вилучаючий» реліз, і саме в цьому його сутність.

Ми повністю видалили інтерфейс ENGINE. Ми прибрали SSLv3 та ClientHello SSLv2. Ми вимкнули застарілі еліптичні криві та явні EC‑криві під час компіляції. Ми зробили ASN1_STRING непрозорим і посилили безліч підписів API. Це зміни, які створюють роботу для людей, і саме вони важливі, бо криптографічна бібліотека, що лише накопичується, не може залишатися безпечною. Кожен застарілий шлях коду, який ви залишаєте активним, — це поверхня атаки, яку хтось підтримує за вас, і ніхто її не тестує.

Є додатки: Encrypted Client Hello, підтримка RFC 8998, включаючи гібридну групу SM2/ML‑KEM, cSHAKE, KDF для SNMP та SRTP, узгоджений FFDHE для TLS 1.2. Особливо ECH закриває реальну прогалину в конфіденційності, бо Server Name Indication розкриває ідентичність кожного сайту, який ви відвідуєте, з моменту випуску TLS 1.3. Але саме вилучення є суттю.

Головне, що я хочу, щоб організації зрозуміли, це: 4.0 не є LTS‑релізом. Підтримка триває до травня 2027 р. Поточний довгостроковий стабільний реліз — 3.5, підтримка до квітня 2030 р., і в 3.5 вже є пост‑квантові алгоритми. Якщо вам потрібен найновіший код, використовуйте 4.0. Якщо потрібна стабільна ціль, навколо якої можна побудувати п’ятирічний план міграції, використовуйте 3.5. Вибирати вищий номер лише тому, що він вищий, — це помилка, яку ми бачимо що цикл.

Пост‑квантова криптографія перейшла від дослідницької проблеми до виклику міграції, причому OpenSSL вже підтримує ML‑KEM, ML‑DSA та SLH‑DSA, а також гібридний пост‑квантовий обмін ключами. Для бізнес‑лідерів, які вважають, що квантові обчислення ще надто далекі, які ризики вони ігнорують сьогодні?

Найпоширеніша помилка — розглядати це як питання про те, коли з’явиться квантовий комп’ютер, релевантний до криптографії. Це не той параметр. Правильне питання — як довго ваші дані повинні залишатися конфіденційними і скільки часу займе міграція. Віднявши друге від першого, ви отримуєте реальний дедлайн, і для багатьох організацій цей дедлайн вже минув.

Зашифрований трафік можна сьогодні захопити і зберігати необмежено. Якщо інформація в ньому має двадцятирічний горизонт чутливості (медичні записи, кадрові файли, інтелектуальна власність, дипломатичні матеріали, фінансові позиції), то противнику не потрібен квантовий комп’ютер зараз. Він потрібен зрештою, а тим часом потрібне дешеве сховище. Це не спекулятивна атака; це рішення про зберігання.

Друга недооцінена річ — міграція це не один проєкт. Обмін ключами — легка частина, і багато чого вже відбувається: OpenSSL 3.5 зробив гібридний пост‑квантовий обмін ключами TLS‑за‑замовчуванням, тому багато організацій вже використовують пост‑квантове узгодження ключів, не прийнявши рішення про це. Підписи та ієрархія сертифікатів — складна частина, бо вони включають центри сертифікації, апаратні корені довіри, ключі підпису прошивки, модулі безпеки апаратури та пристрої з п’ятнадцятирічним строком експлуатації, створені за припущенням, що RSA буде працювати вічно.

Третя річ — це обмеження, на яке ніхто не виділяє бюджет: пост‑квантові підписи великі. Підпис ML‑DSA‑65 приблизно в п’ятдесят разів більший за підпис ECDSA P‑256, а SLH‑DSA ще більший. Це порушує багато аспектів: розміри рукостискань, обмежені пристрої, протоколи з жорстко закодованими полями, супутникові та IoT‑з’єднання. Ви виявляєте ці проблеми шляхом тестування, а не читанням стандарту.

Одним із викликів пост‑квантової міграції є те, що організації можуть навіть не знати, де саме використовується криптографія у їхніх застосунках, інфраструктурі, пристроях та сторонніх залежностях. Як компаніям підходити до інвентаризації криптографії та крипто‑гнучкості, щоб наступний великий перехід алгоритмів не став надзвичайною ситуацією?

Почніть з неприємної правди: ви не можете створити інвентаризацію криптографії, розсилаючи постачальникам анкету. Ви отримаєте суміш маркетингових матеріалів, щирих невизначеностей і відповідей, які були правдивими три випуски тому. Я кажу це, маючи нещодавно значний досвід читання документації апаратних постачальників у суміжній галузі, і розрив між тим, що заявляє документація, і тим, що робить продукт, ширший, ніж припускає більшість покупців.

Потрібно шукати. Є три рівні, і кожен потребує різних методик. Код, який ви писали: статичний аналіз, сканування залежностей і пошук (grep) ідентифікаторів алгоритмів, які ви жорстко закодували роками тому. Код, який ви підключали: списки матеріалів (SBOM) програмного забезпечення, розширені до криптографічних SBOM, де робота з CBOM справді корисна. Речі, які ви купували або підключали: мережеве спостереження, бо те, що ваші системи фактично домовляються по мережі, є реальністю, і часто це не те, у що хтось вірив.

Щодо гнучкості, принцип простий, а практика — ні: алгоритм має бути рішенням конфігурації, а не зміною коду. Якщо зміна шифру потребує розробника, збірки, тестового циклу та випуску, у вас немає гнучкості. Це проєкт. Централізуйте криптографічні операції за інтерфейсом, яким ви керуєте, щоб мати одне місце для зміни, а не чотириста.

І ще частина, яку майже всі пропускають: випробуйте її. Гнучкість, яку ви ніколи не використовували, — це лише заявка, а не можливість. Виберіть спокійний уїк‑енд, вимкніть алгоритм у непроизводному середовищі і дізнайтеся, що зламається. Щось зламається. Краще виявити це за власним графіком, ніж під час примусової надзвичайної міграції.

Корисним примусовим фактором є термін дії сертифікатів. Індустрія переходить до значно коротших сертифікатів, що робить ручне керування сертифікатами нездійсненним і змушує автоматизацію, яку ви все одно планували. Якщо ви правильно автоматизуєте випуск і ротацію сертифікатів, ви створили більшість механізмів, необхідних для майбутньої міграції алгоритмів.

ШІ змінює як захист у кібербезпеці, так і можливості атакуючих. Де, на вашу думку, ШІ справді змінює рівняння безпеки, а де організації можуть надто зосереджуватись на технології, ігноруючи більш фундаментальні вразливості?

ШІ справді змінює одну