dxdt.blog: занимательный интернет-журнал

Можно ли “смешать” TLS-сертификаты для IP-адресов и для хостнеймов? Например, если говорить о TLS для HTTPS, то тут используются и адреса, и имена: поиск сайта, обычно, происходит по имени хоста (по доменному имени), но само соединение устанавливается по IP-адресу. Соответственно, TLS-клиент, – пусть это будет браузер, – на момент отправки первого TLS-сообщения серверу знает доменное имя и IP-адрес, который сам браузер поставил в соответствие этому имени (в процессе обнаружения адреса использовалась DNS, это понятно). Обычно, чтобы признать сертификат валидным, браузер ожидает, что в TLS-сертификате указано имя, соответствующее ожидаемому имени хоста – это может быть одно из нескольких имён в сертификате, может быть результат “раскрытия” wildcard-имени (“со звёздочкой”).

Технически, в TLS-сертификате, вместе с именами хостов, можно указать и IP-адреса, форматом допускается. За примерами не нужно далеко ходить – сертификат на веб-сервере dns.google содержит и DNS-имена, и IP-адреса:

X509v3 Subject Alternative Name: 
 DNS:dns.google, DNS:dns.google.com, DNS:*.dns.google.com,
 DNS:8888.google, DNS:dns64.dns.google,
 IP Address:8.8.8.8, IP Address:8.8.4.4,
 IP Address:2001:4860:4860:0:0:0:0:8888,
 IP Address:2001:4860:4860:0:0:0:0:8844,
 IP Address:2001:4860:4860:0:0:0:0:6464,
 IP Address:2001:4860:4860:0:0:0:0:64

При этом dns.google показывает на те же IP-адреса, которые перечислены в сертификате. Это, конечно, не означает, что IP-адреса из сертификата должны быть связаны с именами в том же сертификате через DNS – просто, сертификат будет валиден и для любого из указанных IP-адресов отдельно (при совпадении подписей, конечно).

Однако в теории тот же браузер может потребовать, чтобы в сертификате и имя хоста совпадало, и IP-адрес, по которому установлено TCP-подключение. Двойная проверка.

Чем такая схема, если бы её реализовать, грозит? С одной стороны, схема неожиданным образом защищает от использования секретного ключа другим сервером, если таковой сервер использует другой IP-адрес. Подключение к подставному серверу можно реализовать подменой DNS, так что имя – совпадёт. Но не IP-адрес. Может ли атакующий, вооружённый секретным серверным ключом, соответствующим ключу в сертификате, подменить и IP-узел? То есть, сделать так, чтобы перехватывающий, подменный узел стал доступен для атакуемого клиента по тому же IP-адресу, который указан в сертификате? Как ни странно, не факт – владение секретным ключом от сертификата никак не помогает в решении сетевой задачи подмены IP-узлов. При этом, если в сертификате сверяется только имя хоста, то атака сработает уже и при подмене DNS. С другой стороны, тот, кто может подменить IP-узел и DNS, может попытаться выпустить сертификат для этих реквизитов. Однако такая подмена уже потребует атаки на системы УЦ, а не на обычного клиента веб-узла.

На одном IP-адресе может размещаться большое количество веб-узлов с разными именами. Но это не является препятствием для того, чтобы вписать для всех этих узлов один и тот же IP-адрес в сертификат. Сертификат может быть выпущен только для IP-адреса. Например, такие сертификаты обещает даже Let’s Encrypt. Но если обращение к узлу происходит в контексте, где нет DNS-имён, то можно использовать сертификат только с IP-адресом, и если бы был возможен контекст, в котором есть только DNS-имя, то сгодился бы сертификат только с именем, как сейчас. Так что тут проблемы нет. Тем более, если сертификаты начинают выпускаться всего на несколько дней.

Проблемы возникнут при попытке замены IP-адресов в DNS – нужно будет согласовывать такую замену с выпуском новых сертификатов. IP-адреса могут выбираться из большого пула и, конечно, строго привязывать их при помощи TLS-сертификата и к DNS-имени, и к серверу на уровне приложения не очень-то удобно. А соответствие адресов именам в DNS, вообще-то, подтверждает DNSSEC, тоже при помощи электронной подписи. Но DNSSEC – редкая технология.

Сообщают, что CA/B-форум принял решение сократить к 2029 году максимальный срок действия TLS-сертификата до 47 дней. В принципе, это давно ожидалось. Скорее всего, могут даже сдвинуть срок раньше, да и максимальный интервал – сократить (дней до 14, скажем). Я в прошлом году писал в заметке о шестидневных сертификатах Let’s Encrypt:

Это нововведение Let’s Encrypt, не сомневайтесь, прямо означает, что браузеры, следом за Chrome/Chromium от Google, постараются оперативно перейти на короткие сертификаты, запретив срок действия дольше месяца (например).

Процесс, скорее всего, коснётся и сертификатов, которые выпускаются от собственных УЦ, не входящих в CA/B-форум.

Конечно, с одной стороны, короткий срок действия сертификатов, признаваемых браузерами, это возможность побороть проблемы отзыва (отказавшись от него) и даже обеспечить “быструю замену алгоритмов” (этот момент раньше мало кого беспокоил, но тем не менее).

Но необходимо учитывать и другую сторону решения. Сертификаты превращаются в квитанции, разрешающие доступ. Что-то вроде тикетов в каком-нибудь Kerberos. Короткие сертификаты означают, что веб-узлам придётся плотно привязаться к внешней централизованной системе. Те же 47 дней, это даже не три месяца от Let’s Encrypt. Всякий веб-узел должен будет постоянно и в автоматическом режиме отмечаться на центральном сервере, который станет выдавать (или не выдавать) подтверждение, что браузерам всё ещё разрешено к этому веб-узлу подключаться.

“Яндекс”, у которого недавно приключилась авария с полным обесточиванием одного из дата-центров, публикует разбор произошедшего. Пишут, что отключились сразу обе из имевшихся двух вводных линий, которые, как выясняется, шли от одной подстанции. Цитата:

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

Как-то потерян тот факт, что подключение к разным подстанциям (“теоретическое”), имеет ещё один важный аспект: источник – источником, он может быть и общий, но если точки подключения разные, то и разные независимые линии могут идти максимально обособленным образом. То есть, пути доставки будут защищены лучше. Опять же, в статье “Яндекса” по ссылке написано, что “опорная подстанция немного остаётся для нас «чёрным ящиком»”. Понятно, конечно, что для электрических линий реализовать такое возможно далеко не всегда, но тут-то речь даже про теоретическую ситуацию, которая, видимо, всё же сыграла на практике и общее подключение вылетело по двум линиям сразу.

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

Автономного питания, конечно, в дата-центре “Яндекса” тоже не хватило, потому что оно же не на случай полного отключения проектировалось. Цитата:

В 12:27 главный инженер обслуживающей организации связался с дата‑центром и сообщил, что на подстанции отключились обе линии 110 кВ, но причина пока неизвестна. А значит, у нас Проблема № 1: сразу две точки отказа по питанию с непонятным прогнозом, а дизель‑генераторы просто не рассчитаны на то, чтобы принять такую нагрузку.

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

Печально тут то, что во все эти “облачные сервисы”, работающие в дата-центрах с таким подходом, усиленно загоняют информационные системы, какие только можно и какие только нельзя. Не ровён час, окажется в подобном “облаке” и система управления всем прочим энергоснабжением. “Под контролем ИИ”, конечно. Времена меняются. Угроза ИИ крепнет.

Кстати, вот пара сервисов, позволяющих просматривать информацию из российских логов Certificate Transparency через веб:

ct.tlscc.ru – экземпляр crt.sh, но с российскими логами (используется TLS-сертификат ТЦИ);
precert.ru – весьма удобный самостоятельный сервис, отличается от crt.sh веб-интерфейсом, форматом вывода и возможностями расширенного поиска.

Certificate Transparency (CT) это технология публикации сведений о сертификатах, выпускаемых Удостоверяющими Центрами (УЦ). TLS-сертификатов для веба в Интернете выпускается очень много. Чтобы отдельные CT-логи не разрастались чрезмерно – придумали “таймшардинг” (от англ. time и sharding: “временно́е разбиение” (нередко также называют “сегментацией” в русскоязычных текстах)).

При “таймшардинге” отдельный лог заводится для определённого периода, например, на год. Как и везде в Certificate Transparency, тут алгоритм тоже не самый очевидный: подходящий лог выбирается по времени окончания действия сертификата (а не начала, как можно подумать). Если сертификат выпускается на 12 месяцев (365 дней) 05.03.2025 (пятого марта 2025 года), то публиковать (пре)сертификат нужно в тот лог, в интервал которого попадает дата окончания действия в марте 2026 года, например, интервал действия подходящего лога может начинаться 03.03.2026 и оканчиваться 03.10.2026.

Если (пре)сертификат не подходит по интервалу действия, лог его не примет. Этот механизм автоматически усиливает ограничение по сроку действия сертификатов: так, если логов на 2028 год нет, а метка лога (SCT-метка) необходима для того, чтобы выпустить сертификат, то выпустить оконечный сертификат на три года в 2025 году не получится. Понятно, что такие долгие сертификаты и так не считаются валидными в браузерах: текущее ограничение – 398 дней максимум (но в браузерах может быть ещё меньше, и есть тенденция к дальнейшему уменьшению).

Схемы “таймшардинга” используются (и использовались) разные, не обязательно разбивать всё на годовые интервалы. Например, сейчас Google публикует в качестве собственных доверенных восемь логов (блок “Google” по ссылке) и все эти логи имеют интервал в шесть месяцев.

В российском варианте Certificate Transparency, который используется для сертификатов собственных удостоверяющих центров (сейчас это НУЦ и ЦС ТЦИ), интервал действия для “свежих” логов установлен в один год. Раньше некоторые российские логи имели интервал в 13 месяцев, да ещё и с перекрывающимися датами, что облегчало тестирование при добавлении новых логов. Конечно, при том объёме сертификатов, которые сейчас попадают в российские логи CT, использование “таймшардинга” выглядит несколько странно: данный метод должен применяться там, где количество сертификатов, принимаемых ежемесячно, измеряется сотнями тысяч и более, а не сотнями. Возможно, при запуске учитывали риск “внезапного роста”.

Заметьте, кстати, что с целью предотвращения замусоривания публичные CT-логи обычно принимают только сертификаты, выпущенные от закрытого списка корневых ключей, то есть, только от некоторых УЦ. Поэтому разместить произвольный сертификат в произвольный лог – не получится: нужно, чтобы лог “верил” в соответствующий корень (промежуточные сертификаты можно подставить вместе с публикуемым оконечным). Поэтому, например, российские CT-логи “Яндекса” не содержат сертификатов от Let’s Encrypt.

Национальный центр кибербезопасности Великобритании (NCSC) выпустил рекомендации по переходу организаций на постквантовые криптосистемы к 2035 году, то есть, через десять лет. В качестве примеров криптосистем с постквантовой стойкостью приводятся, конечно, стандартизованные NIST ML-KEM, ML-DSA, SLH-DSA и LMS/XMSS (криптосистемы подписи). Занятно, что и в этих рекомендациях ничего нет про симметричные шифры. Считается, понятно, что последние теряют только половину битовой стойкости, но ведь никто не запрещает появление квантовых алгоритмов взлома для конкретных шифров (AES, предположим, как наиболее вероятный кандидат). Впрочем, для RSA/ECDSA алгоритм уже есть, пусть и не реализован, а это существенное отличие.

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

Шум от ИИ снова очень велик, даже для “хайпа”. Это выражается и в потоке исследований, и в потоках сгенерированного контента, но и в растущей куче однообразных публикаций в СМИ, где, уже достаточно дежурным образом, рассказывают, что “очень и очень скоро будет AGI” (то есть, некий “универсальный/сильный”, “действительно разумный” искусственный интеллект). Судя по всему, этот самый AGI “появится” уже прямо вот в этом году. Ну, как появится: скорее всего, в какой-то момент крупнейшие ИИ-корпорации договорятся, кто первый выпустит новый продукт, и СМИ тут же определят этот момент как появление AGI. Определения и область в целом – достаточно размыты, чтобы фиксировать текущий статус ИИ в стиле “фактчекинга”, то есть, через базовые публикации СМИ.

С другой стороны, нельзя исключать, что AGI и как бы уже вот-вот, на подходе, но это “вот-вот” будет тянуться и тянуться, пока есть места для дата-центров и производство чипов не остановилось. Это тоже вариант, но он находится в некотором противоречии с появлением “суперинтеллекта”: так-то после объявления про AGI можно ждать “суперинтеллекта”, а вот ждать “суперинтеллекта” без AGI – это ведь аж на одну важную веху дольше, то есть, “суперинтеллект” отдаляется достаточно, чтобы он стал выглядеть меньше и не очень-то “супер”.

Необходимо отметить, что шум – шумом, но как-то подутихла тема “опасностей ИИ” и защиты от этих опасностей. Вероятно, причина в том, что это единственная тема, которая не очень способствует дальнейшему развитию общего “хайпа”: во-первых, тут действительно есть опасность – имеющиеся ИИ-системы грозят применить там, где применять такое нельзя; во-вторых, рассуждения о рисках в данной области иногда (именно “иногда”, то есть, далеко не всегда) приводят к снижению градуса восторженности, к появлению каких-то содержательных предположений. И это автоматически глушит данное “направление безопасности”. При помощи перенаправления общего шума, в том числе.

Понятно, что растёт и количество публикаций о шуме ИИ. Вот как эта записка. Тут интересно посмотреть, в какой момент появится слой рассуждений о причинах появления таких публикаций, об их содержании. Заметьте, что тут ИИ добавляет глубины – далеко не во всех областях можно построить аж четыре слоя, как здесь: исходный предмет (1); трансформация предмета силами ИИ (2); рассуждения о результатах трансформации силами ИИ и эффектах, этими трансформациями вызываемых (3); объяснения рассуждений предыдущего слоя (4). Хм.

Вот и начался четвёртый слой.

Опубликовал на “Хабре” небольшой обзор DNS-over-TLS: как эта технология работает для авторитативных серверов DNS, с примерами “из консоли” на базе утилиты dig.

Кстати, что касается “удаления домена .SU”: попытки “удаления” этого домена начались ещё в 90-х годах прошлого века, и с тех пор продолжаются, с регулярностью (часто – весной; почему-то – “загадка природы”, видимо).

При этом домен всё ещё жив.

Вообще, пока в домене верхнего уровня, несмотря на все прошедшие годы, есть десятки тысяч используемых и работающих ресурсов, на которые ведут, как минимум, ссылки с сотен тысяч веб-страниц (и не только веб-страниц, заметьте), удалять его как-то странно. Нынче, конечно, можно ожидать всякого. Но всё же вряд ли в ICANN уже настолько плохо всё, что эта осторожная организация пойдёт на подобный шаг. Пусть даже в современной глобальной ситуации “сегментации интернетов”.

Прецеденты с удалением страновых доменов в схожих локальных обстоятельствах, конечно, были: CS – домен Чехословакии, DD – ГДР. Однако SU используется уже 34 года после официального падения Союза ССР. Так что тут и история той страны, и история домена – совсем другие.

Заметьте, что ещё веселее было бы удалить домен IO (формальные причины – те же).

Собственно, вот РосНИИРОС пишет:
“Регистратура (РосНИИРОС ) не планирует ликвидацию домена .SU и никаких формальных действий со стороны ICANN предпринято не было.”

Уже писал об этом, но напомню снова: антивирус, осуществляющий подмену TLS-сертификатов на локальном компьютере для браузера (и не только), он не “просто подменяет сертификат”, но он же и полностью ломает TLS-соединение, чтобы инспектировать трафик. Это означает, что с внешним сервером будет соединяться по TLS не браузер, а TLS-прокси из состава антивируса. Как работает данный прокси, какие библиотеки он использует для реализации TLS в целом и криптографических операций в частности, что за уязвимости в этих библиотеках – это всё вопросы отдельные.

Заметьте, впрочем, что TLS-прокси нетрудно устроить таким образом, чтобы сведения о симметричных секретах TLS-сессии утекали наружу вместе с трафиком. Есть разные способы, позволяющие реализовать такую утечку. На совсем верхнем уровне логика соответствует штатному экспорту симметричных секретов TLS. Естественно, разумно сделать канал утечки защищённым, чтобы для доступа нужно было знать специальные секретные “ключи инспектирования”. Эти ключи вовсе и не обязательно встраивать в антивирус.

Антивирусы могут использоваться в корпоративной среде, да и не только. Вот поэтому-то нужно правильно оценивать риски и учитывать, что антивирус, инспектирующий трафик грубым отключением TLS, во-первых, раскрывает в неизвестном направлении все данные, а не только “зашиту сертификатом”; во-вторых, при этом ещё и переключает доверие TLS: с браузера (или другого клиента) – на свою собственную реализацию.

В короткоживущих TLS-сертификатах Let’s Encrypt вообще не планируется указывать информацию о механизмах проверки отзыва: ни OCSP, ни CRL. То есть, будет только истечение срока действия сертификата. Новая парадигма. Актуальные требования CA/B-форума как раз позволяют для короткоживущих сертификатов так делать – изменения внесли относительно недавно: сперва сделали OCSP опциональным для всех (что очень правильно), а потом добавили исключение CRL для короткоживущих сертификатов.

Интересно, что истечение срока действия, как метод придания сертификату “недействительности”, гораздо сильнее, чем неработающая проверка отзыва. То есть, отзыв, действительно, мало кто проверяет, а вот срок действия – проверяют едва ли не повсеместно. Ну, как минимум, гораздо чаще проверяют, чем отзыв. Например, те же браузеры, как основной клиент веба, срок действия отслеживают достаточно строго. При этом, если для оформления отзыва нужно предпринимать какие-то действия со стороны УЦ, то обработка истечения срока действия – исключительно на стороне клиента.