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

Добавил к техническому описанию TLS совсем краткое приложение, рассказывающее про DNS-over-HTTPS и DNS-over-TLS как примеры использования TLS для защиты других протоколов. Так как это приложение, и оно небольшое, основную версию документа решил не менять.

Вообще, в этом году обновлений для описания TLS получилось не так много. В июле я внёс исправления и уточнения в основной текст, добавил описание ESNI и приложение, рассказывающее на элементарном уровне о некоторых математических аспектах криптографии на эллиптических кривых (на мой взгляд, это довольно полезное приложение). Посмотрим, как будет развиваться тема в следующем году.

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

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

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

Представьте, что есть нейросеть, которая обучена узнавать наличие дикобразов на фотографии. В простейшем случае, вы применяете нейросеть к конкретному изображению, а на выходе получаете один бит: “есть дикобраз” – 1; “нет дикобраза” – 0. Пусть входное изображение имеет допустимые размеры в 1 млн пикселей (1000×1000 – это не важно). Посчитать выходной бит нейросети для любого фотоснимка очень просто, компьютер справляется за малую долю секунды. Но развернуть биты обратно, разбив все допустимые входные изображения на два класса (“есть дикобраз”/”нет дикобраза”), очень сложно, так как нейросеть состоит из тысяч коэффициентов, выстроенных в несколько слоёв (или представленных как система уравнений, это не принципиально) – граф состояний нейросети огромен. А перебрать все возможные сочетания пикселей, скармливая нейросети тестовые изображения – и того сложнее. Соответственно, может существовать сочетание пикселей, при наличии которого любой дикобраз, хорошо видимый на картинке, узнан не будет, с гарантией. Просто, на этапе обучения “нейросети” такие картинки специально подсовывались в выборку и отмечались как “здесь точно нет дикобраза”. Это и есть алгоритмическая закладка. Конечно, в несколько утрированном виде, но общая логика – именно такая.

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

Microsoft сообщает, что планирует внедрить поддержку DNS-over-HTTPS и DNS-over-TLS в ОС Windows. На ресурсе D-Russia.ru – мой комментарий по этой теме.

Много сообщений о том, что Интернету 29 октября 2019 года исполнилось 50 лет. В качестве точки отсчёта приводят факт обмена сообщениями между двумя компьютерами, которые находились на большом удалении (600 км) – этот обмен, согласно записям, произвели 29 октября 1969 года (Charley Kline, UCLA и SRI). Это событие, впрочем, моментом возникновения Интернета – не является.

Дело в том, что Интернет – это стек протоколов TCP/IP. Именно внедрение этих протоколов и сделало уже существовавший набор каналов связи между узлами-компьютерами – Интернетом. TCP/IP внедрили в 1983 году. От этого момента, действительно, следует отсчитывать годы истории Интернета. Раньше – это были другие сети (в частности, одна из версий ARPANET).

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

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

Очень много сообщений про DNS-over-HTTPS в Firefox, про то, что внедрение этого протокола, якобы, “позволяет обходить любые блокировки и DPI”. Между тем, DNS-over-HTTPS (DoH) в Firefox – это способ сокрытия DNS-запросов и DNS-ответов от третьей стороны, причём скрываются только запросы от браузера до рекурсивного резолвера (подразумевается, что до резолвера Cloudflare). Заметьте, что использование DoH не скрывает рекурсивные запросы, источником которых является браузер Firefox. Например, если некоторую уникальную DNS-метку встроить в веб-страницу, то на авторитативном сервере будет видно, откуда пришёл рекурсивный запрос, соответствующий конкретной сессии конкретного браузера. По IP-адресу источника запроса (рекурсивного резолвера), по некоторым другим признакам, можно определить, используется ли клиентом штатный DNS от провайдера доступа, или это та или иная реализация DoH. В качестве источника DNS-меток (такой источник принято называть “праймером”) с большим охватом может работать любой популярный веб-сервис или веб-сайт: например, какой-нибудь веб-счётчик (что-то подобное “Яндекс.Метрике”), страница популярной социальной сети и т.д.

Однако на пути от браузера до рекурсивного резолвера, действительно, запросы и ответы DNS не будут видны третьей стороне, просматривающей трафик, так как они в HTTPS защищены шифрованием. Но к “обходу блокировок” это относится весьма косвенно.

Предположим, что блокировка доступа к веб-ресурсу осуществляется провайдером на уровне DNS. Смысл подобного метода блокирования в том, чтобы браузер (или другие программы-клиенты) не мог определить подлинный IP-адрес, с которым требуется установить соединение. Как такая блокировка работает?

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

В продвинутом варианте, уже система DPI обнаруживает все DNS-запросы и DNS-ответы, вне зависимости от того, к каким DNS-серверам они отправлены и от каких получены. Фильтрующий узел вмешивается в трафик в том случае, если силами DPI обнаружены запросы, относящиеся к заблокированным именам. Вмешательство в трафик может выражаться как в подмене ответов, так и в блокировании запросов; конечно, можно заблокировать и ответы. В этом случае DoH помогает, так как DPI перестаёт видеть DNS-трафик. Однако тот же фильтрующий узел и DPI можно настроить так, что они будут блокировать трафик DoH. Блокировать придётся весь трафик, а DPI потребуется очень серьёзно доработать. При этом в Firefox по умолчанию будут встроены средства, позволяющие предотвратить автоматическое включение использования DoH. Эти средства предназначены для корпоративных сетевых сред, где фильтрация DNS нередко является обязательным требованием “политик безопасности”. Такое поведение браузера пользователь может преодолеть, если включит использование DoH вручную.

(Отмечу, в скобках, что все описанные выше методы с подменой информации DNS противоречат DNSSEC и, соответственно, будут обнаружены, если клиент поддерживает DNSSEC.)

Защита от просмотра DNS-трафика никак не влияет на блокировку доступа непосредственно по IP-адресу узла: если соединение с конкретным адресом установить не удаётся, то не важно, как этот адрес был получен – через “открытый DNS” провайдера или через “защищённый DNS-over-HTTPS”. Да, нетрудно предложить вариант, в котором IP-адреса постоянно изменяются, а “верный адрес” передаётся только при использовании сервиса DoH. Так можно устроить, если авторитативные серверы DNS соответствующей доменной зоны как-то связаны с провайдером сервиса DoH. Однако при этом активная система блокирования может узнавать “верные адреса”, просто используя свой экземпляр браузера Firefox. Конечно, всегда остаётся экстенсивный вариант развития данной схемы, при котором, с одной стороны, сотни тысяч IP-адресов случайно распределяются по DNS-ответам, а с другой стороны – какие-то, – возможно те же, – сотни тысяч и миллионы адресов попадают под превентивную блокировку. При этом DoH здесь помогает только тем сервисам, у которых очень много IP-адресов.

Нередко можно услышать, что данный метод, применительно к проблеме блокирования доступа, хорош тем, что его трафик, по внешним признакам, не отличается от “обычного HTTPS” (то есть, от HTTPS для веб-сайта). Мало кто готов блокировать весь HTTPS-трафик. Конечно, приложив достаточно вычислительных мощностей, попытаться отличить трафик DoH от работы с веб-сайтами – можно: есть IP-адреса, есть характеристики отправляемых и принимаемых пакетов, продвинутая система блокирования умеет делать проверку сервисов (connection probe) и так далее. Другое дело, что ресурсов для блокирования потребуется действительно много и будут ложные срабатывания. Более того, в качестве следующего шага по защите возможно заворачивание DNS-трафика в “самый настоящий” HTTPS-сеанс работы с обычным веб-сайтом: DNS-запросы могут передаваться браузером в качестве нагрузки, в специальных HTTP-заголовках; и в таких же HTTP-заголовках сервер пришлёт ответы.

В целом, сверхидея DNS-over-HTTPS хорошо укладывается в самую современную концепцию в области информационной безопасности. В этой концепции “доверенными” являются только приложения – клиентское и серверное. То есть, даже операционная система не относится к доверенным. Криптография позволяет двум приложениям надёжно идентифицировать (и аутентифицировать) друг друга: браузер Firefox, используя принесённые с собой TLS-сертификаты, идентифицирует и аутентифицирует серверное приложение, которое исполняется на узлах Cloudflare и реализует сервис рекурсивного опроса доменных имён. Для схемы не важно, каким образом, по каким транзитным сетям, приложения устанавливают между собой соединение. Да, тут есть масса оговорок – про аппаратуру, которая исполняет команды; про ядро ОС, имеющее полный доступ к памяти приложений; и так далее. Но, тем не менее, логическая концепция именно такая. Развитие этой идеи в ближайшем будущем приведёт к тому, что появятся “различные интернеты”, работающие внутри того или иного приложения. Но это другая история.

Вернёмся к DoH в браузере Firefox. Данный инструмент, сам по себе, не является универсальным средством, “позволяющим обходить все блокировки”, но он защищает от утечки информации о DNS-запросах/DNS-ответах на “последней миле”: то есть, на пути от резолвера до браузера. При этом браузер замыкает на стороне пользователя некоторый особый контур, в который теперь входит и защищённая доставка контента (TLS на веб-сайтах), и собственный сервис доменных имён. “Интернет – это то, что показывается в браузере”.

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

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

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

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

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

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

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

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

Некоторое время назад в СМИ обсуждалось введение в Казахстане “обязательного TLS-сертификата”, который требовалось установить на клиентские устройства, что позволяло выполнять прозрачный перехват TLS-трафика. Эта история уже не новая: такая же схема обсуждалась в Казнете несколько лет назад.

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

Выпустил (некоторое время назад) очередное обновление технического описания протокола TLS.

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

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

На сайте Statdom.ru (это проект Технического Центра Интернет) опубликована статистика по проникновению технологии ESNI в российских национальных доменных зонах. Напомню, что ESNI позволяет скрыть имя сервера, с которым соединяется клиент, при установлении TLS-соединения. Сейчас ESNI поддерживается браузером Firefox. На стороне сервера с поддержкой пока не очень хорошо, но Cloudflare её уже реализовали, поэтому заметное количество TLS-узлов ESNI уже поддерживают, а в Рунете уже свыше 140 тыс. доменов с ESNI.

Немного об одном интересном техническом аспекте. ESNI подразумевает размещение ключей в DNS, поэтому для сбора статистики требуется анализировать ресурсные записи. Соответствующий черновик RFC (draft-02) предписывает хранение данных ESNI в TXT-записи (Base64) для имени специального вида: _esni.name.tld (то есть, к имени узла, с которым устанавливается соединение, добавляется префикс _esni – подробнее описано в отдельной записке). Таким образом, для получения статистических данных выполняется сбор TXT-записей. При этом во многих случаях авторитативные серверы DNS так настроены, что отвечают на запрос TXT-записи для любого имени внутри зоны. Но, естественно, в ответ приходит не ESNI. Спецификация предусматривает для ESNI контрольную сумму, проверка значения этой суммы как раз и позволяет отличить настоящие ESNI от “каких-то” TXT-записей. Именно поэтому в отчёте на Statdom.ru присутствует колонка, в которой дано количество зон с некорректными TXT-записями для ESNI-имени.

Описанная только что проблема с размещением ESNI в DNS при помощи TXT-записей – известна. Поэтому более свежие версии черновика RFC предусматривают использование нового типа DNS-записи, специально выделенного для ESNI. Соответственно, после того, как такой тип выделят (и, скорее всего, появится RFC), ключи ESNI будут распространяться под именем без префикса _esni.

Особенно интересно, что в составе ESNI-записи смогут передаваться и адреса (IPv4, IPv6) узлов, с которыми клиенту следует соединяться, используя ключи ESNI. То есть, ESNI, фактически, замещает A- и AAAA-записи. (Конечно, всё это только после того, как появится новый тип и его поддержка DNS-серверами.)

На сайте ТЦИ также опубликована моя статья, популярно рассказывающая про технологию ESNI.