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

Можно ли в вебе на стороне сервера определить, какой именно версии браузер устанавливает TLS-соединение, в самом начале этого соединения? Например, для того, чтобы выбрать сертификат от подходящего УЦ (см. ниже). Хитрость в том, что привычный способ, когда браузер определяется по HTTP-заголовку User-Agent, тут не подходит: на начальном этапе установления соединения никаких HTTP-заголовков ещё нет, а вот серверный сертификат передавать нужно. И речь не про выбор сертификата на основе перечня поддерживаемых криптосистем, как это делается при настройке параллельной работы ГОСТ-алгоритмов и “обычных” алгоритмов в TLS/HTTPS – эта задача как раз решается весьма просто. Вообще, проблема находится на другом уровне: строго говоря, узнавать нужно даже не столько браузер, сколько конкретную библиотеку, реализующую TLS (так, для Firefox это будет NSS), и конкретный профиль данной библиотеки. Вообще, сделать выбор иногда можно на основе анализа состава TLS-сообщений, но так как набор этих сообщений не велик, а сам перечень может изменяться, то и точность не велика. Тем не менее, конкретная разновидность браузеров могла бы сигналить серверу, что именно такой браузер подключается. Это реализуется через дополнение TLS-сообщений, но внедрение потребует доработки TLS-стека как на стороне сервера, так и на стороне браузера.

А вот что касается именно списка поддерживаемых УЦ, то в TLS уже есть встроенный механизм, в версии 1.3 он так и называется – “certificate_authorities”. Это расширение, которое клиент может включить в состав сообщения ClienHello (начальное сообщение TLS-соединения), а сервер может обработать и – выбрать нужный сертификат, в том числе, для одной и той же криптосистемы. Вот только распространённые браузеры данное расширение не поддерживают, а если бы и поддерживали, то туда пришлось бы вписывать слишком много имён УЦ, так как в типичный дистрибутив браузера их входят многие десятки. Так что доработка, как минимум, браузера – всё равно потребуется.

Появилось открытое письмо, призывающее “приостановить эксперименты с большим искусственным интеллектом” (“Pause Giant AI Experiments”) и ввести регулирование, в том числе, “контроль и отслеживание” “мощных вычислительных средств” (“large pools of computational capability”). Занятно, что там в качестве основы шкалы используется GPT-4 – то есть, буквально, предлагается всем немедленно приостановить “обучение” систем, более мощных, чем GPT-4. Приостановить – как минимум, на шесть месяцев; но, как можно предположить по тону и смысловому содержанию письма, более точная интерпретация такая: приостановить до того момента, пока не введут нужные запреты на уровне правительств. Довольно показательный PR-шаг. Особенно, если взглянуть на него в исторической перспективе развития глобальной Сети, которая, несомненно, для разных там Chat GPT – имеет первоочередное значение.

Цитата из моего технического описания TLS:

Весьма полезной практикой является разумное выравнивание стойкости используемых криптосистем. Например, в подавляющем большинстве случаев не имеет смысла использовать RSA-ключ длиной в 4096 бит, если ваш TLS-сервер всё ещё поддерживает SSLv3, а в качестве симметричного шифра применяет DES с 56-битным ключом.

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

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

В TLS 1.3 криптосистема RSA для зашифрования не используется, а процесс получения сеансовых ключей (за некоторыми исключениями) основывается на протоколе Диффи-Хеллмана и состоит из нескольких этапов. Тем не менее, раскрытие сеансовых симметричных ключей и тут приводит к тому, что активный атакующий может подменить трафик, выступив вместо одной из сторон после того, как соединение установлено.

Наберём в консоли (в терминале) ping 010.010.010.010 и запустим выполнение – что произойдёт? Результат теперь многим и многим, – далеко не пользователям, а даже системным администраторам, – кажется неожиданным: “пинги” отправляются на один из адресов Google – 8.8.8.8. Проверьте самостоятельно (в экзотических ОС результат может отличаться, но в привычных линуксах, например, – всё вполне корректно, а экзотические ОС ещё предстоит подобрать).

Почему так вышло? Потому что старое системное соглашение, о котором нынче забывают, гласит: если запись октета IP-адреса (здесь – четвёртой версии) начинается с символа нуля и не содержит, следом, буквы, то это запись в восьмеричной системе! (Относится, конечно, не только к ping и не только к IP-адресам.) 10 в восьмеричной системе – это восемь, так что: 8.8.8.8. Неплохо взглянуть и на другие варианты: ping 010.8.010.8, например. А попытка вызвать ping 010.080.010.010 приведёт, скорее всего, к сообщению о том, что адрес для имени обнаружить не удалось (или Name or service not known – в типичном случае).

А оговорка насчёт буквы в предыдущем параграфе, конечно, это для 0x08, например. Но такая запись мало кого вводит в заблуждение.

В ТЦИ запущен сервис просмотра данных российских логов Certificate Transparency. На сервере используется TLS-сертификат, выпущенный ЦС ТЦИ. Соответствующий корневой сертификат ECDSA можно взять на сайте ЦС (SHA-1: 4E877AC027A63D8514C0B4CBFA0F6F58F6C17696).

“Данный сервис дает возможность любому пользователю проверить, выпускались ли сертификаты для какого-либо домена российскими центрами сертификации. Сервис собирает данные сразу всех российских CT-логов. Одним из главных его преимуществ является то, что он позволяет централизованно получать сводную информацию о TLS-сертификатах и осуществлять поиск по именам и другим значениям через удобный веб-интерфейс, то есть избавляет пользователей от необходимости использования специализированного программного обеспечения для просмотра CT-логов.”

(Это, собственно, версия известного сервиса crt.sh, но с поддержкой только российских логов – в crt.sh они не учитываются автоматически.) Самое простое применение – поиск (пре)сертификатов TLS по доменному имени (см. скриншот для livejournal.com ниже).

Кстати, о трафике на веб-узлах. Я поддерживаю тестовый сервер TLS 1.3 (https://tls13.1d.pw/) с HTTPS – это специальный сервер, написанный на языке Go и предназначенный, как нетрудно догадаться, для тестирования разных свойств TLS версиии 1.3. Cервер был запущен около пяти лет назад, когда спецификация TLS 1.3 ещё была черновиком. Надо заметить, что сейчас сервер принимает и обрабатывает примерно одно соединение в секунду (немало), часть из этих соединений – это TLS, а часть из TLS-соединений – это соединения версий 1.3 (“версий” – потому что иногда встречаются и draft-версии). Впрочем, по какой-то не совсем ясной причине, большинство успешных соединений инициируют клиенты, которые представляются как боты сервисов мониторинга доступности интернет-узлов. Представляются эти боты через строку User-Agent: сервер ориентирован на HTTPS, поэтому реализует минимальную логику обработки HTTP-заголовков, так что User-Agent – виден (но только для успешного TLS-соединения, понятно).

В конце 2018 года я добавил к тестовому серверу поддержку технологии ESNI, которая тогда находилась в состоянии эксперимента. Собственно, исходная версия ESNI поддерживается на tls13.1d.pw и сейчас, вот только поддержку ESNI удалили из браузеров и с серверов провайдера Cloudflare. Причина в том, что сама технология с тех пор была полностью переработана и теперь даже называется иначе – ECH. Так что, возможно, отключу поддержку ESNI. Тем более, что и ключи в DNS устарели. Конечно, надо бы взамен дописать реализацию ECH, но таких планов у меня нет, как и планов по развитию тестового сервера.

Подписи DNSSEC в глобальном корне DNS появились в 2010 году. Это подписи криптосистемы RSA, которая сейчас считается устаревшей. Ввод DNSSEC прошёл в таком режиме, который не содержал даже механизма обновления корневых ключей – этот механизм внедрили существенно позже. Корневой ключ заменили, но криптосистема осталась той же – RSA. И вот, в 2023 году ICANN “планирует начать процесс подготовки” внедрения новых криптосистем в корневой зоне DNS: на днях опубликовали сообщение о создании рабочей группы. Можно предположить, что в корне DNS появится ECDSA, а может быть даже и что-то из разряда EdDSA (но этот вариант, конечно, вряд ли).

Процитирую заметку из 2016 года, про MITM для TLS:

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

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

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

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

Понятно, что так как исходящие соединения закрыты, то запущенная на сервере “троянская программа” не сможет простым способом передать какие-то данные внешнему узлу. Но можно передать данные через DNS. Типовой и универсальный способ – запрос A-записи для имени в доменной зоне, которая делегирована на авторитативные серверы, контролируемые “принимающей стороной”. Предположим, что нужно передать последовательность из нескольких байтов (с произвольными значениями), а “инструментальная” доменная зона – test.ru. Закодируем последовательность тем или иным способом в подмножество допустимых ASCII-символов и запросим в DNS имя, где получившаяся строка будет дописана на третьем (и ниже) уровне: JBQWY3DPFVUGC3DMN4QSCIIK.TEST.RU. Данное имя, через резолвер (или несколько резолверов) попадёт в составе запроса на авторитативный сервер зоны test.ru, где его можно обработать и извлечь данные. (При необходимости, можно разделить запись полезной нагрузки точками – это не повлияет на доставку.)

DNS-запросы, содержащие подобную “абракадабру”, далеко не всегда вызывают подозрения, потому что могут генерироваться не только какими-нибудь элементами ботнета, но и вполне штатными программами, которые таким образом пытаются, например, обнаружить подмену и перехват DNS. Однако, для повышения уровня скрытности, запросы могут кодироваться каким-нибудь другим, вполне “безобидным”, способом: table.is.unavail.fedora.test.ru. Но каждый шаг в сторону снижения уровня “подозрительности” будет снижать и пропускную способность канала передачи.

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

Переход сети ARPANET на TCP/IP состоялся 01/01/1983 – то есть, в 2023 году Интернету исполнилось 40 лет. Почему отсчёт связан именно с этой датой? Потому что Интернет, как глобальная сеть, это именно ARPANET c TCP/IP и связанные технологии, к которым, прежде всего, отсносятся механизмы IP-маршрутизации между компьютерными сетями. Интернет составляют автономные системы. Логические инструменты, позволяющие определить автономную систему (в терминах Интернета и маршрутизации), это следущие понятия:

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

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

Пограничный маршрутизатор – узел, который позволяет логически взаимодействовать с внешними сетями и, по сути, формирует основу для преобразования внутренних политик доставки пакетов во внешние; то есть, пограничный маршрутизатор как раз позволяет получить информацию (с ограничениями) о том, как связаться с внешними узлами, находящимися в других автономных системах.

Алгоритм маршрутизации и межсетевой адресации узлов – это универсальный и эффективный способ адресовать сети и узлы так, чтобы можно было строить практические маршруты доставки пакетов через межсетевые границы при помощи пограничных узлов-маршрутизаторов, абстрагируясь от свойств физических каналов и конкретных протоколов электросвязи. Это и есть IP (префиксы и адреса узлов) и необходимый, в современной сети, BGP (Border Gateway Protocol).

Второй важнейший составляющий элемент Интернета – DNS. Но здесь он оставлен за скобками.

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