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

Сколько лет Интернету – вопрос многогранный. Дмитрий Бурков пишет, что отсчитывать годы нужно с момента разработки BGP (и это довольно логично, так как BGP в современной Сети используется для обмена информацией о маршрутах доставки пакетов).

Провайдер Timeweb, как я заметил, включил поддержку DNS over TLS на двух (как минимум) из своих массовых авторитативных серверов имён (NS): ns2.timeweb.ru., ns4.timeweb.org. Это означает, что резолверы могут использовать TLS при подключении к этим серверам, что автоматом делает DNS over TLS (DoT) довольно распространённой в Рунете технологией, если считать по зонам, так как упомянутые NS использует больше двух с половиной сотен тысяч DNS-зон в .RU.

DoT полезно внедрять на авторитативных серверах. Это защищает трафик резолвера при рекурсивном опросе. Подробно про DoT я недавно писал на “Хабре”.

Скриншот отчёта сервиса проверки настроек DNS:

Пишут, что под Android браузерные скрипты “Метрики” от “Яндекса” и Pixel от Facebook (принцип тот же) идентифицируют посетителя веб-страницы, обмениваясь токенами с собственным приложением на localhost. Приложение, понятно, должно быть “родственным”: либо от Facebook, либо от “Яндекса” (для каждой корпорации – своё).

Механизм: приложение слушает номер порта на localhost, куда браузерный скрипт отправляет данные и получает ответ, идентифицирующий пользователя. Браузеры доступ не блокируют (дефект, по нынешним временам), а решение “Яндекса” использует ещё и технический домен, который с адресом 127.0.0.1 в A-записи – такой вот половинчатый “DNS rebinding” (это, впрочем, не редкость).

Немного странно, конечно, что этот метод авторы вообще обозначают как “novel tracking method” (то есть, “новый, оригинальный метод отслеживания”). Но, очевидно, подобное блокировать должны именно браузеры (у “Яндекса”, впрочем, есть собственная сборка Chrome/Chromium, которая, как пишут, тоже слушает дополнительный номер порта).

(via)

Сервис ТЦИ audit.statdom.ru, позволяющий в онлайн-режиме проверять настройки интернет-узлов, теперь не в бета: новая версия – v.1.0. И в новой версии добавлено, кроме прочего, отображение данных по SCT-меткам в TLS-сертификатах веб-узлов: выводится таймстемп, оператор лога, название лога, данные о криптосистеме.

Очередной пример усиленной сегментации этих вот интернетов: пишут, что Google заблокировал в своём удостоверяющем центре всю DNS-зону spb.ru, ссылаясь на штатовские санкционные списки. Это, в частности, приводит к тому, что TLS на “веб-фронте” Cloudflare перестал работать для адресов в spb.ru. Со списками – не очень понятно: официальное объяснение найти пока не удалось, но на форуме Cloudflare пишут, что, возможно, это из-за названия “СПБ Биржи” (SPB Exchange). Если так, то ситуация совсем печальная: мало того, что активно отключают доступ к веб-узлам, используя TLS и “исторически сложившееся” исключительное положение хорошо известных УЦ в браузерах и CDN-провайдерах, так ещё и Google адреса путает.

Google сообщает, что после 30 мая 2025 года “системы, использующие шифр 3DES для SMTP-соединений, не смогут доставлять электронную почту на аккаунты Gmail”. Про 3DES и SMTP-соединения – это буквально так и написано в исходном сообщении (“systems using 3DES for SMTP connections”). Но, насколько можно судить по прочим деталям, имеется в виду всё же TLS, а не непосредственно SMTP.

3DES – это схема использования очень старого симметричного шифра DES с подмешиванием дополнительных ключей, что повышает общую оценку стойкости до 112 бит (оригинальный DES – это 56 бит максимум; практически ничего, по современным меркам). Естественно, схема эта устаревшая, и безальтернативное её использование в 2025 году выглядит странно. Каких-то суперэффективных атак, полностью убивающих 3DES, пока не публиковалось, но 112 бит – это всего лишь 112 бит. И тем не менее, в почтовой системе может быть применена реализация TLS на уровне “хоть какой-то”, это всё равно лучше, чем передача в открытом виде.

С другой стороны – насколько это вообще критично для электронной почты, с точки зрения входных почтовых релеев сервиса Google? TLS для SMTP нужен, кто бы сомневался. Но, во-первых, то, что почту на сервер Gmail кто-то принёс через TLS, совсем не означает, что эта почта и на предыдущих этапах ходила только в защищённом виде. Во-вторых, сообщения всё равно обрабатываются в открытом виде на стороне Google. Тут важен баланс рисков. Так что единственная причина, которую можно придумать, это то, что исключается необходимость поддерживать устаревшие реализации элементов TLS на стороне Google, тем самым оптимизируется технологический стек. Это весьма логично. Однако те, кто не сумел поправить на своей стороне, больше не смогут доставлять почту в Gmail. То есть, теперь доставка почты отключается даже не только по наличию TLS (без TLS Gmail и так уже не принимает сообщения), но по наличию устаревшего шифра. Строгость растёт.

Есть и иной аспект. Если посмотреть на опубликованный список шифров, которые поддерживаются в конфигурации TLS на почтовых серверах Gmail, то станет ясно, что там, за вычетом 3DES, остаётся только AES и ChaCha20. При этом, если не использовать TLS 1.3, то остаётся единственный вариант – AES.

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

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

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

Хорошо известный удостоверяющий центр SSL.com выпускал TLS-сертификаты для доменов без проверки права управления. Как пишут, статус “подтверждённого имени” получал всякий домен, на произвольный почтовый адрес в котором пользователь смог получить код подтверждения для любого другого домена. То есть, можно было разместить заказ на TLS-сертификат для example.com, выбрать способ подтверждения с отправкой кода по адресу email, указанному в TXT-записи (и такое бывает), – например, akhmet@test.ru, – подтвердить получение кода, и доменное имя из состава адреса, – то есть, test.ru, – тоже получало статус прошедшего проверку права управления.

Очередное подтверждение того, что проверка права управления (DCV) должна проводиться перед выпуском каждого сертификата, для всех имён, указываемых позже в сертификате, и только для этих имён, но строго после получения соответствующего заказа (и процесс подтверждения должен быть привязан к конкретному заказу и к конкретному ключу из заказа). И, конечно, никаких проверок по email для TLS-сертификатов.

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

Скопирую сюда своё сообщение с “Хабра”:

В связи с интенсивным сокращением максимального срока действия TLS-сертификатов (пока что обещают 47 дней, но для всех и к 2030 году), коллеги саркастически поинтересовались, можно ли сделать так, чтобы сертификат выписывался на каждый TLS-запрос. Шутки – шутками, но сделать-то можно. И даже не требуется переделывать протокол TLS – есть готовое решение.

Если внимательно посмотреть на алгоритм TLS-хендшейка, то окажется, что секретный ключ, соответствующий открытому ключу из серверного сертификата, требуется там только один раз – для формирования подписи в сообщении CertificateVerify. Соответственно, секретного ключа от сертификата вообще может не быть на сервере, а сервер будет обращаться к некоторому подписывающему узлу, у которого этот ключ есть и который подтвердит TLS-сессию, подписав значение для CertificateVerify. Это вовсе не теоретическое рассуждение, именно так делается на практике, когда входящие соединения принимает прокси-провайдер (CDN, обычно), но передавать этому провайдеру секретные ключи от сертификатов для своих доменов клиент не желает. Первыми в промышленных масштабах такую услугу сделали в Cloudflare, более десяти лет назад. Называется Keyless SSL.

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

Сертификат, таким образом, окончательно превратится в безотзывный тикет доступа, мгновенного действия, а сервер будет привязан к центральному провайдеру (можно совместить с крупными CDN, у которых и так есть собственные хорошо известные УЦ). Проверку совпадения подписей, серверной и на сертификате, будет всё так же проводить браузер (речь, напомню, про веб). В браузере ничего не нужно переделывать совсем: если сервер не смог предъявить корректную подпись в CertificateVerify – TLS-сессия браузером установлена не будет.

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

Можно ли “смешать” 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. Всякий веб-узел должен будет постоянно и в автоматическом режиме отмечаться на центральном сервере, который станет выдавать (или не выдавать) подтверждение, что браузерам всё ещё разрешено к этому веб-узлу подключаться.