Тим Хадсон, президент 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 помогает защищать миллиарды безопасных онлайн‑взаимодействий каждый день. Через OpenSSL Foundation и OpenSSL Corporation проект стремится продвигать надёжную криптографию, поддерживать устойчивую разработку с открытым исходным кодом и укреплять безопасность интернета.

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

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

У меня было знание о том, что большинство людей уже забыли. Эрик Янг несколько лет назад написал реализацию DES: хороший, чистый, свободно доступный код, написанный ради самого процесса и полностью не связанный с этим. Эрик не работал над SSL. Он не знал о SSL. Когда Netscape опубликовал спецификацию, я её прочитал, обратился к Эрику с проблемой и представил её как относительно скромный шаг от того, где он уже находился.

Это была не полная картина. Каждая часть была проста, но их было значительное количество. Реализация DES даёт один симметричный шифр. SSL требует криптографию с открытым ключом, арифметику произвольной точности, ASN.1, работу с сертификатами X.509 и протокольный конечный автомат, всё это должно быть безошибочно, потому что в криптографии почти правильное и сломанное — одно и то же. Я представил масштаб проекта оптимистично. Эрик достаточно быстро понял, насколько всё это объёмно, и получил от этого удовольствие, потому что масштаб оказался привлекательным, а не препятствием. Не уверен, что всё началось бы иначе.

Эрик занимался криптографическим ядром, поэтому библиотека несёт его инициалы. Я взял на себя части, превращающие библиотеку в то, что другие люди могут действительно развернуть: интеграцию в приложения, тестирование, документацию и работу с сообществом. Я также активно искал места, где использовалась конкурирующая библиотека шифрования, и заменял её. SSLtelnet, SSLftp, NCSA httpd и множество других пакетов — это моя работа, приложения, построенные поверх криптографических алгоритмов и протоколов, реализованных Эриком. Такое сочетание позволило каждому из нас сосредоточиться на том, что действительно интересно, и, как я считаю, стало основной причиной продолжения проекта.

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

Знали ли мы, чем это станет? Нет. Никто не ставит перед собой задачу построить критическую инфраструктуру. Критическая инфраструктура — это то, что вы обнаруживаете, что построили, спустя несколько лет, когда узнаёте, кто от неё зависит. Мы думали, что решаем текущую проблему, а затем отвечаем на вопросы других людей, столкнувшихся с тем же препятствием. Оказалось, что часть с ответами на вопросы была столь же важна, как и код.

Вы работаете в области криптографии и интернет‑безопасности более трёх десятилетий. Что изменилось наиболее драматично в ландшафте угроз за этот период, и какие проблемы безопасности остаются удивительно схожими, несмотря на огромные технологические достижения?

Самое крупное изменение — атаки на системы превратились в профессию с экономической моделью. В середине девяностых люди, взламывающие системы, делали это в основном из интереса. Сегодня существует индустрия со специализацией, инструментами, цепочками поставок, поддержкой клиентов и в некоторых случаях государственной финансовой поддержкой. Это меняет всё, как вы должны мыслить, потому что вы больше не защищаетесь от любопытства, а от противника с бюджетом, сроком и бизнес‑кейсом.

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

То, что остаётся удивительно постоянным, — это типы отказов. Мы всё ещё пишем баги в коде, который разбирает недоверенный ввод. Мы продолжаем поставлять системы с настройками по умолчанию, которые никто не пересматривал. Сертификаты всё ещё истекают в субботу. Учётные данные всё ещё оказываются в местах, где им не место. И криптография почти никогда не ломается на уровне математики. Она обходится, неправильно настраивается или просто не включается. Если бы вы дали мне список десяти главных причин утечек в 1996 году и список за прошлый месяц, вам было бы трудно отличить их друг от друга. Технологии полностью трансформировались. Ошибки — нет.

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

Самое важное, что нужно понять о версии 4.0, — это то, что она в первую очередь является «вычетным» релизом, и в этом и заключалась её цель.

Мы полностью удалили интерфейс ENGINE. Мы убрали SSLv3 и клиентское приветствие 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) идентификаторов алгоритмов, жёстко зашитых годами ранее. Код, который вы подключали: списки материалов программного обеспечения, расширенные до криптографических списков материалов (CBOM), где эта работа действительно полезна. Приобретённые или подключённые вещи: наблюдение за сетью, потому что то, что ваши системы действительно согласовывают по проводу, — это реальная правда, и часто это не то, что кто‑то предполагал.

Что касается гибкости, принцип прост, а практика — нет: алгоритм должен быть решением конфигурации, а не изменением кода. Если смена шифра требует разработчика, сборки, тестового цикла и релиза, у вас нет гибкости. Это проект. Централизуйте криптографические операции за интерфейсом, которым вы управляете, чтобы было одно место для изменения, а не четыреста.

И затем часть, которую почти все пропускают: проверяйте её. Гибкость, которой вы никогда не пользовались, — это утверждение, а не возможность. Выберите тихие выходные, отключите алгоритм в непроизводственной среде и посмотрите, что сломается. Что‑то сломается. Лучше обнаружить это по своему расписанию, чем во время вынужденного перехода в чрезвычайной ситуации.

Полезный принудительный фактор — срок жизни сертификата. Индустрия переходит к существенно более коротким сертификатам, что делает ручное управление сертификатами невозможным и заставляет автоматизировать процесс, который всё равно понадобится. Если вы правильно автоматизируете выдачу и ротацию сертификатов, вы построили большую часть механизмов, необходимых для будущего перехода алгоритмов.

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

ИИ действительно меняет одну вещь, и я могу говорить об этом напрямую, потому что это уже случилось с нами.

Существенная часть уязвимостей, раскрытых в OpenSSL в этом году, была обнаружена с помощью анализа, управляемого ИИ. В январе мы выпустили релиз, устраняющий двенадцать проблем, практически все из одной исследовательской группы, использующей автоматический анализ, и они предоставили патчи вместе с отчётами. В июне мы исправили уязвимость высокой степени тяжести типа use‑after‑free в проверке PKCS#7, найденную исследователем, работающим с ИИ‑системой. Это реальное изменение возможностей в обнаружении ошибок безопасности памяти и парсинга в зрелом C‑коде, который годами проверялся экспертами. Я наблюдал аналогичную закономерность в других криптографических библиотеках. При анализе пакета уязвимостей Bouncy Castle за этот год отпечаток автоматического анализа кода очевиден.

Очевидный вывод — это двусторонний эффект. Те же техники доступны тем, кто хочет их использовать, на тех же кодовых базах, и защитники не имеют исключительного доступа.

Менее очевидный вывод, который я бы подчеркнул, — нагрузка, возлагаемая на поддерживающих. Создание правдоподобного отчёта об уязвимости теперь почти бесплатно. Его сортировка — нет. Она всё ещё требует реального времени эксперта. Команды по безопасности открытого кода, обычно небольшие и часто добровольные, поглощают растущий объём отчётов разного качества. Хорошие, как упомянутое исследование, сопровождаются репродукторами и патчами. Плохие представляют собой атаку отказа в обслуживании на людей, от которых вы зависите. Если ваша организация использует ИИ против кода с открытым исходным кодом, финансируйте возможности сортировки с другой стороны.

Где, по моему мнению, внимание misplaced: ИИ не исправляет ваши системы. Он не инвентаризирует активы, не вращает учётные данные, не выводит из эксплуатации неподдерживаемое оборудование и не делает кого‑то ответственным за сертификат, истекающий в следующем месяце. Организации, покупающие инструменты ИИ‑безопасности, одновременно эксплуатирующие программное обеспечение с известными неустранёнными уязвимостями, ошибаются в последовательности действий. Неприметная работа всё ещё является источником риска.

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

Самая значительная ошибка — рассматривать безопасность как закупочную деятельность. Инструменты покупаются, бюджеты соблюдаются, панели мониторинга показывают зелёный статус, и никто не спросил, может ли организация действительно выполнять фундаментальные задачи.

Вторая — незнание того, что вы используете. Вы не можете исправлять программное обеспечение, о котором не знаете, и большинство организаций обнаруживают реальное содержание своей инфраструктуры во время инцидента. Поэтому работа с перечнем материалов важна, не как артефакт соответствия, а как то, к чему вы обращаетесь в два часа ночи, когда выходит критическое предупреждение и кто‑то спрашивает, затронуты ли вы.

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

Четвёртое — управление ключами и сертификатами, оставленное отдельным людям. Значительная часть самовызванных сбоев связана с просроченными сертификатами, которые один человек тихо отслеживал в таблице, пока не сменил работу.

До инцидента руководство должно иметь четыре вещи. Назначенного ответственного, уполномоченного отключить бизнес, определённого заранее и в письменной форме, потому что спор о том, кто имеет такие полномочия, не хочется вести в реальном времени. Уже подписанные контракты с внешними специалистами по судебной экспертизе и консультантами, поскольку их закупка занимает недели, а у вас будет часы. Канал коммуникаций, не зависящий от потенциально скомпрометированных систем. И возможность восстановления, действительно протестированную от начала до конца, а не схему резервного копирования, проверенную лишь тем, что задания завершились успешно.

Затем отрабатывайте это. Тренировка в виде настольного упражнения на уровне руководства раз в год выявит больше реальных пробелов, чем любой другой инструмент.

Когда происходит серьёзная кибератака, руководители могут внезапно оказаться перед необходимостью принимать технические, юридические, операционные и коммуникационные решения под огромным давлением. Что отличает организации, которые реагируют эффективно, от тех, кто допускает, что инцидент становится существенно хуже?

Организации, которые справляются хорошо, приняли важные решения до инцидента, поэтому во время инцидента они действуют, а не раздумывают. Это основная часть.

Помимо подготовки, несколько факторов постоянно отличают хорошие реакции от плохих.

Они разделяют техническое расследование и исполнительно‑коммуникационный поток, имея чётко определённый интерфейс между ними. Когда одни и те же люди пытаются одновременно сдержать вторжение и подготовить уведомление клиентам, обе задачи выполняются плохо.

Они сохраняют доказательства до исправления. Инстинкт сразу перестроить скомпрометированную машину сильный, но он уничтожает информацию, необходимую для определения масштаба. Если вы не можете ответить «что ещё они затронули», вы не сможете достоверно сообщить, что инцидент завершён.

Они признают, что ранняя информация предварительна, и сообщают об этом соответствующим образом. Большая часть репутационного ущерба, который я наблюдал, возникла не из‑за утечки, а из‑за уверенных ранних заявлений, которые пришлось отозвать. Сказать «это то, что мы знаем, это то, что пока неизвестно, это когда мы обновим вас» — не слабость. Это единственная позиция, которую не придётся менять.

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

OpenSSL занимает необычное положение как критически важная инфраструктура с открытым исходным кодом, используемая по всему технологическому экосистеме, в то время как OpenSSL Corporation сосредотачивается на обслуживании коммерческих сообществ вместе с независимо управляемым OpenSSL Foundation. Как вы уравновешиваете потребности предприятий, разработчиков, регуляторов и более широкого сообщества открытого кода, когда решения о безопасности и совместимости могут затронуть столь большую часть интернета?

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

Предсказуемость — то, что мы обязаны нашим пользователям. Мы выпускаем версии с новыми функциями в апреле и октябре. Мы заранее объявляем, какая версия будет долгосрочно стабильной и до какого срока. Мы объявляем о значимых удалениях задолго до их внедрения. Удаление ENGINE в версии 4.0 было публично описано за несколько месяцев до релиза и согласовано как корпорацией, так и фондом. Тот, кто был удивлён этим в апреле, просто не следил, а мы сделали всё, что могли, чтобы следить было максимально просто.

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

Вторая часть — правильно слушать, что требует реальных механизмов, а не предположений. Это одна из причин, почему мы проводим конференцию, которая проходит в Праге в этом октябре, и почему существует инфраструктура сообщества. Очень легко для поддерживающих разработчиков сформировать уверенные теории о потребностях пользователей. Гораздо полезнее находиться в комнате с ними.

Глядя на следующее десятилетие, какой переход в сфере безопасности или криптографии, по вашему мнению, организации всё ещё недооценивают, и какие уроки из эволюции SSL, OpenSSL и трёх десятилетий интернет‑безопасности должны применять лидеры, готовясь к нему?

Переход, который, по моему мнению, наиболее недооценён, — это не пост‑квантовая криптография как проблема алгоритма. Это идентичность машин и иерархия сертификатов, лежащая в основе всего.

Пост‑квантовый обмен ключами в значительной степени будет решён настройками по умолчанию, и большая часть уже решена. Что не будет решено настройками, так это инфраструктура доверия: корневые сертификаты в аппаратуре, ключи подписи прошивки, записанные в устройства, HSM с десятилетним оставшимся сроком службы, промышленные и медицинские системы, которые будут работать до 2040 года с криптографическими предположениями, заложенными при производстве. Их нельзя обновить, просто поставив новую версию библиотеки, а в некоторых случаях их невозможно обновить вовсе. Масштаб этой проблемы замены сейчас не отражён в планировании капитальных расходов никого.

Параллельно происходит регулятивный переход. Cyber Resilience Act в Европе и аналогичные рамки в других регионах изменят обязательства, связанные с поставкой программного обеспечения, содержащего компоненты, которые вы не писали. Большинство организаций ещё не проработали, что это значит для их зависимости от открытого кода и для людей, его поддерживающих.

Три урока за тридцать лет:

1. Переходы занимают на десяток лет дольше, чем объявлено. SSLv3 был объявлен устаревшим в 2015 году, по умолчанию отключён в 2016, а мы окончательно удалили код в апреле 2026. Это одиннадцать лет для протокола, который все согласились, что он сломан. Планируйте пост‑квантовую миграцию, учитывая эту реальность, а не пресс‑релиз.
2. Настройки по умолчанию — единственный контроль безопасности, работающий в масштабе. Всё, что требует от каждого администратора правильного решения, не произойдёт. Причина, по которой гибридный пост‑квантовый обмен ключами развернулся так быстро, заключается в том, что он включён по умолчанию и не требует никаких решений. Проектируйте для людей, которые никогда не прочитают вашу документацию, потому что это почти все.
3. Вы зависите от меньшего количества людей, чем думаете. Практически каждая организация в мире полагается на криптографический код, поддерживаемый очень небольшим числом людей. Это было так, когда мы были вдвоём в Брисбене, и структура по‑прежнему не изменилась, даже когда ставки выросли в разы. Что бы вы ни планировали на следующее десятилетие, часть этого опирается на поддерживающего, с которым вы никогда не контактировали и не финансируете. Это важно знать, прежде чем они вам понадобятся.

Спасибо за отличное интервью. Читатели, желающие узнать больше, должны посетить OpenSSL.