Тім Хадсон, Президент 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 справді корисна. Речі, які ви купували або підключали: мережеве спостереження, бо те, що ваші системи фактично домовляються по мережі, є реальністю, і часто це не те, у що хтось вірив.

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

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

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

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

Штучний інтелект дійсно змінює одну річ, і я можу поговорити з ним безпосередньо, тому що це сталося з нами.

Значну кількість вразливостей, розкритих у OpenSSL цього року, було виявлено за допомогою аналізу за допомогою ШІ. У січні ми надіслали випуск, у якому вирішено дванадцять проблем, по суті всі від однієї дослідницької групи за допомогою автоматизованого аналізу, і вони внесли виправлення разом зі звітами. У червні ми виправили серйозну помилку використання після безкоштовного використання в PKCS#7, виявлену дослідником, який працював із системою ШІ. Це реальна зміна можливостей у пошуку помилок безпеки пам’яті та синтаксичного аналізу в зрілому коді C, який перевірявся експертами протягом багатьох років. Я бачив таку саму схему в інших криптографічних бібліотеках. Аналізуючи серію CVE Bouncy Castle за цей рік, відбиток автоматизованого аналізу коду очевидний.

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

Менш очевидний наслідок, на якому я хотів би підкреслити, це тягар, який він покладає на супроводжувачів. Створення правдоподібного звіту про вразливості тепер майже безкоштовне. Сортування один не є. Це все ще коштує людського експерта в реальному часі. Групи безпеки з відкритим кодом, які зазвичай невеликі та часто працюють на волонтерських засадах, поглинають зростаючий обсяг звітів різної якості. Хороші, як-от дослідження, про яке я згадав, постачаються з відтворювачами та патчами. Погані – це атаки типу «відмова в обслуговуванні» на людей, від яких ви залежите. Якщо ваша організація розгортає штучний інтелект з відкритим вихідним кодом, профінансуйте можливості сортування на іншому кінці.

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

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

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

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

Третій – це за замовчуванням. Системи встановлюються, вони працюють, і конфігурація ніколи не переглядається. Через п’ять років ця конфігурація є проблемою, і ніхто з тих, хто був причетний до початкового рішення, досі там не працює.

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

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

Потім відрепетируйте. Настільна вправа на керівному рівні раз на рік виявить більше справжніх прогалин, ніж інший інструмент.

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

Організації, які добре справляються з цим, прийняли важливі рішення до інциденту, тому під час інциденту вони виконують, а не обмірковують. Це більша частина.

Крім підготовки, кілька речей постійно відрізняють хороші відповіді від поганих.

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

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

Вони визнають, що рання інформація є тимчасовою, і повідомляють відповідно. Більшість репутаційних збитків, які я спостерігав, походять не від порушення, а від впевнених ранніх заяв, які довелося відкликати. Сказати «ось що ми знаємо, ось чого ми ще не знаємо, ось коли ми вам оновимо» — це не слабкість. Це єдина позиція, яку вам не доведеться змінювати.

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

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

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

Передбачуваність – це те, чим ми зобов’язані нашим користувачам. Ми надсилаємо випуски функцій у квітні та жовтні. Ми заздалегідь говоримо, який випуск довгостроково стабільний і до якого часу. Ми оголошуємо про значне видалення задовго до того, як воно відбудеться. Видалення ENGINE у версії 4.0 було описано публічно за кілька місяців до випуску та погоджено як Корпорацією, так і Фондом. Усі, хто був здивований цим у квітні, не звертали уваги, і ми зробили це настільки легким, наскільки могли, щоб звернути увагу.

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

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

Дивлячись на наступне десятиліття, яку безпеку чи криптографічний перехід, на вашу думку, організації все ще недооцінюють сьогодні, і які уроки з еволюції SSL, OpenSSL і останніх 30 років безпеки в Інтернеті варто застосувати керівникам, готуючись до цього?

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

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

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

Три уроки тридцяти років:

1. Переходи тривають на десятиліття довше, ніж оголошують. SSLv3 визнали застарілим у 2015 році, вимкнули за замовчуванням у 2016-му, а код ми остаточно видалили у квітні 2026 року. Це одинадцять років для протоколу, щодо несправності якого всі погоджувалися. Плануйте постквантову міграцію з огляду на цю реальність, а не на пресреліз.
2. Налаштування за замовчуванням — єдиний засіб захисту, який працює у великих масштабах. Усе, що вимагає правильного рішення від кожного адміністратора, не буде реалізовано. Гібридний постквантовий обмін ключами впроваджується так швидко тому, що він увімкнений за замовчуванням і взагалі не потребує рішення. Проєктуйте для людей, які ніколи не читатимуть вашу документацію, адже таких майже всі.
3. Ви залежите від меншої кількості людей, ніж думаєте. Майже кожна організація у світі покладається на криптографічний код, який підтримує дуже невелика кількість людей. Так було, коли нас було двоє у Брісбені, і структура принципово не змінилася, хоча ставки зросли на кілька порядків. Що б ви не планували на наступне десятиліття, частина цього спирається на роботу розробника, з яким ви ніколи не зв’язувалися і якого не фінансуєте. Варто знати це до того, як він вам знадобиться.

Дякую за чудове інтерв’ю. Читачі, які хочуть дізнатися більше, повинні відвідати OpenSSL.