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

Выпустил очередное (ежегодное) обновление технического описания TLS: tls.dxdt.ru. Это подробное изложение всех особенностей протокола, который является важнейшим инструментом защиты информации в Интернете. Ключевые моменты разобраны до отдельных байтов.

В новой версии:
1) добавлено описание режима использования шифров CCM;
2) актуализировано описание механизма защиты поля имени сервера (SNI);
3) добавлен небольшой фрагмент про постквантовую криптографию в TLS (это существенное направление, которое заметно изменит практику применения протокола).

Описание доступно здесь: tls.dxdt.ru/tls.html

Больше десяти лет назад я описывал (на правах юмора) сценарий, когда центральное управление социальной сетью используют для дезинформирования пользователей и прямого влияния на офлайн. В качестве примера взял как раз Twitter. Недавно Twitter взломали, получив доступ к управлению чужими аккаунтами – именно через внутренние инструменты, предназначенные для управления сервисом.

В заметке, посвящённой этому событию, Брюс Шнайер пишет:
“Imagine a government using this sort of attack against another government, coordinating a series of fake tweets from hundreds of politicians and other public figures the day before a major election, to affect the outcome”. (Представьте, что правительство использует атаку такого типа в отношении другого правительства, скоординировав серии поддельных “твитов” от лица сотен политиков или других публичных фигур за день до важных выборов, чтобы повлиять на их результат.)

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

Интересно, что, как пишут, аккаунт Президента США Трампа не был затронут атакой. Если это произошло потому, что, силами Секретной службы и АНБ, государственные аккаунты особой важности отдельно защищены, то получается, что определённое регулирование в Twitter уже внедрено. Конечно, подобное скрытое и как бы “неформальное” регулирование – оно, во многих случаях, гораздо удобнее.

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

Возникает традиционная проблема: где клиенту взять ключи? Ключи для такой схемы публикуются в DNS. При этом, использование DNSSEC – позволяет защитить данные от подмены, а доставка запросов и ответов DNS через TLS – защищает от прослушивания трафика.

То есть, опять же, на примере TLS, – клиент извлекает серверные криптографические параметры для установления соединения из DNS, генерирует нужные ключи и зашифровывает первое же сообщение, которое направляет серверу. Это сообщение может вообще не содержать фиксированных заголовков в открытом виде (кроме, понятно, относящихся к TCP/IP или UDP). Третья сторона видит только факт обмена узлов псевдослучайными данными. Более того, даже на уровне DNS – тоже видны только псевдослучайные данные, поскольку обмен защищён TLS, в том числе, на пути между рекурсивным резолвером и авторитативным сервером.

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

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

В-третьих, полностью исчезнут современные возможности по приоритизации разных типов трафика силами DPI: никаких сигнатур отдельных протоколов не останется, кроме самых базовых – номеров портов и IP-адресов (ну, ещё количество потоков можно как-то измерить).

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

И тем не менее, переход на такой уровень – вполне возможен в ближайшие годы.

Авторитативные серверы DNS – это серверы, которым делегирована поддержка заданной доменной зоны. Другими словами, это основные серверы, служащие первоисточником информации об адресации внутри доменной зоны. Именно к авторитативным серверам должен обращаться рекурсивный резолвер при поиске значений DNS-записей.

DNS-over-TLS – технология, защищающая трафик DNS-запросов при помощи TLS. Обычно, DNS-запросы и DNS-ответы передаются по протоколу UDP (реже – TCP) в открытом и незащищённом виде. Существует технология DNSSEC, которая позволяет снабдить содержание DNS-ответов электронной подписью, затруднив, таким образом, подмену информации. Но DNSSEC не скрывает сам трафик: то есть, третья сторона всё равно будет видеть состав запросов и ответов. Кроме того, DNSSEC аутентифицирует только передаваемые данные, привязывая их к некоторому открытому ключу, но не позволяет аутентифицировать сервер, который данные передал. В принципе, в модели угроз DNSSEC аутентификация сервера и не требуется: основная идея этой технологии состоит в том, что не имеет значения, каким маршрутом и от какого узла DNS-данные попали к клиенту – если данным соответствует валидная подпись от доверенного ключа, то они, так или иначе, достоверны. То есть, с точки зрения достоверности, канал получения DNS-информации для DNSSEC не важен. Если данные, защищённые DNSSEC, будут как-то изменены на транзитном узле, то клиент сможет обнаружить подмену. С DNS-over-TLS (или DoT) – другая история. Эта технология оборачивает обычный трафик DNS в TLS, создавая защищённый канал связи. DoT позволяет узлам, которые намерены обменяться DNS-запросом и DNS-ответом, аутентифицировать друг друга до отправки запроса. В подавляющем большинстве случаев, конечно, будет использоваться только аутентификация сервера клиентом.

В DNS, как в сервисе, большое значение имеет взаимодействие рекурсивного резолвера с так называемым stub-резолвером. Последний представляет собой самый простой вариант резолвера, который не выполняет поиска в DNS, а лишь перенаправляет запросы рекурсивному резолверу. Stub-резолвер – это типовой резолвер в подавляющем большинстве конфигураций операционных систем. Сервис же рекурсивного резолвера предоставляется либо провайдером доступа, либо отдельным провайдером DNS, как, например, в случае общедоступных резолверов Cloudflare (1.1.1.1) и Google (8.8.8.8).

Так вот, сейчас часто приходится слышать, что технология DNS-over-TLS предназначена лишь для защиты DNS-трафика на пути от stub-резолвера до рекурсивного резолвера, а на авторитативных серверах – не нужна. Это не так. Авторитативным серверам тоже рекомендована поддержка DNS-over-TLS, так как такая поддержка позволит защитить обмен информацией с рекурсивными резолверами. Дело в том, что прослушивание DNS-запросов или подмена данных – возможны и для трафика рекурсивного резолвера, адресованного не клиенту, а авторитативному серверу. Другое дело, что реализовать избирательность такой атаки становится сложнее, поскольку точно не известно, какие запросы какому клиенту соответствуют. Но, например, если используется популярный сервис DNS, то IP-адреса его узлов-резолверов известны, поэтому подмена может осуществляться избирательно. Впрочем, атакующему придётся каким-то образом встать своим транзитным узлом между авторитативным сервером и сервером DNS-резолвера. Это сложно, но возможно. Причём, разными способами. А не раз продемонстрированные на практике BGP-атаки позволяют перехватить трафик между сетями, которые, в смысле маршрутизации, находятся “далеко” от точки перехвата.

Поддержка DoT на авторитативных серверах пока что является большой редкостью и встречается существенно реже, чем даже поддержка DNSSEC. Тем не менее, один масштабный пример внедрения DoT здесь уже есть: технология поддерживается авторитативными серверами Facebook, на которые делегирована зона facebook.com.

По состоянию на декабрь 2019 года для веб-узлов Рунета более 80% TLS-сертификатов (HTTPS) выпущены всего двумя удостоверяющими центрами (УЦ): Let’s Encrypt и Cloudflare Inc. Соответствующую статистику TLS можно посмотреть на сайте проекта Statdom.ru (да, там тоже сертификат Let’s Encrypt).

Лидерство этих УЦ – довольно интересный показатель. Доля Let’s Encrypt, предоставляющего бесплатные сертификаты, уже более двух лет находится в интервале 61 — 68%, а вот Cloudflare – набрали почти 15% примерно за год. Конечно, в случае Cloudflare, это просто переход от одного названия к другому – ранее они использовали сертификаты УЦ Comodo, а потом перешли на собственное имя, – но это никак не отменяет достижений.

Такое “сосредоточение” процедур по выпуску сертификатов может вызвать различные опасения. Поэтому, думаю, полезно коснуться некоторых популярных вопросов по теме.

Означает ли это, что наступила некая “сверхцентрализация” и почти все HTTPS-узлы – захвачены? И да, и нет. Дело в том, что в выборе TLS-сертификатов и УЦ участвует несколько сторон, а определяющую роль играет браузер и операционная система. То есть, чтобы УЦ смог выпускать доверенные сертификаты, корневые ключи этого УЦ должны попасть в перечень доверенных браузера (либо операционной системы – зависит от конкретной среды, но в нашем случае это не важно). То есть, говорить о “сверхцентрализации” рано – теоретически, браузеры могут исключить, например, Let’s Encrypt из списка доверенных (прецеденты известны). Другое дело, что данный УЦ стал слишком большим, чтобы его просто так взяли и исключили: даже в случае существенных обстоятельств – такое исключение будет проводиться постепенно (если вообще будет проводиться).

Можно ли говорить, что эти УЦ теперь имеют доступ к данным почти всех HTTPS-сайтов, потому что там установлены их сертификаты? Нет, так говорить нельзя. Хотя и тут есть тонкости. Let’s Encrypt вообще не получает, при штатном способе выпуска сертификата, доступа к секретным ключам сервера (эти ключи просто не нужны УЦ для выпуска сертификата), соответственно, как-то расшифровать и перехватить данные этот УЦ не может. А вот у Cloudflare доступ к данным веб-узла с их сертификатом, конечно, есть, но совсем по другим причинам, не связанным с работой УЦ: основная услуга Cloudflare – проксирование соединений, предоставление веб-фронтенда; соответственно, они и так имеют доступ к трафику своих клиентов, вне зависимости от того, какой сертификат установлен на узле. (Интересно, что Cloudflare первыми массово внедрили технологию, позволяющую клиенту не передавать провайдеру копию секретного ключа для осуществления проксирования HTTPS-запросов. Addon /07.02.2020/: точнее, они первыми внедрили такую технологию на своём массовом сервисе, но не факт, что она получила большое распространение – это нужно смотреть отдельно.)

Более того, угроза прозрачного перехвата трафика, при помощи подмены TLS-сертификата, связана с любым УЦ, входящим в список доверенных, и никак не зависит от популярности УЦ. (Это общий дефект современной реализации PKI в вебе, с которым давно пытаются бороться отдельными методами.)

Да, в случае каких-то глобальных проблем – сайты смогут перейти на сертификаты других УЦ. Вряд ли переход будет быстрым и простым, но он возможен. А сайты, использующие Cloudflare, так или иначе полностью зависят от работоспособности данного провайдера, поэтому для них использование сертификатов “карманного” УЦ вообще не создаёт существенных дополнительных рисков. Но всё же: 80% узлов – это четыре пятых всех сайтов с HTTPS. С другой стороны, распространённых браузеров тоже всего два.

Обновления на сервере tls13.1d.pw, который предназначен для тестирования реализаций TLS версии 1.3 и сопутствующих технологий:

1) появилась поддержка ротации (обновления) симметричных ключей сессии. Речь про механизм Key Update, который в TLS применяется для того, чтобы узлы могли перейти на новые ключи внутри уже установленной сессии. Новое поколение ключей вычисляется на основе данных предыдущего поколения. Есть два варианта схемы обновления: на новые ключи либо переходит только один узел, либо оба узла. Для управления обновлением служит TLS-сообщение KeyUpdate. Сервер tls13.1d.pw поддерживает инициированное клиентом обновление (в двух вариантах – с обновлением серверных ключей и без оного), а также, с вероятностью примерно 1/3, может сам передать сообщение KeyUpdate, соответствующее замене серверных ключей (и заменить ключи);

2) теперь сервер перемешивает на своей стороне приоритеты шифронаборов при каждом соединении. Это означает, что могут быть выбраны разные шифры для разных соединений, но для одних и тех же настроек на стороне клиента. В предыдущих версиях приоритеты были зафиксированы, а наивысшее значение имел шифронабор CHACHA20_POLY1305_SHA256. Поэтому, если в качестве клиента выступал, например, браузер Chrome со стандартными настройками, то всегда согласовывался шифронабор с CHACHA20. При этом сервер поддерживает ещё AES в вариантах с 128- и 256-битным ключом. Теперь AES тоже будет иногда выбираться и для клиентов, у которых есть CHACHA20 (естественно, клиент должен заявить поддержку AES);

3) в части, реализующей элементарный веб-сервер, появилась чуть более развитая поддержка URL и кодов статуса HTTP. Теперь сервер различает адреса документов и даже умеет отдавать разные файлы при обращении по разным адресам. Это последнее новшество позволило добавить передачу файла стилей (CSS) и сделать некоторое минимальное оформление страницы результатов (но, собственно, эта часть обновлений не имеет отношения к TLS).

Что касается KeyUpdate, то здесь поддержка браузерами имеет некоторые ограничения: инициировать ротацию ключей на стороне браузера пользователь не может, однако успешная замена серверных симметричных ключей будет отражена на странице результата – там дописывается сообщение о такой замене (интересно, что если браузер на своей стороне ключ не поменял, то расшифровать данные страницы окажется невозможно и пользователь так или иначе не увидит сообщения об успешной ротации ключей). При желании, посмотреть на то, как работает KeyUpdate, можно с помощью утилиты s_client из OpenSSL (нужна современная версия): в s_client есть специальные интерактивные команды ‘k’ и ‘K’ (строчная и заглавная буквы), которые позволяют отправить KeyUpdate с флагами двух видов – замена ключей только одним узлом (k) или обоими узлами (клиентом и сервером).

Описание возможностей сервера есть в отдельной записке.

ESNI – это технология, предотвращающая утечку имени сервера при установлении TLS-соединения. Технология пока находится в фактическом статусе эксперимента, но ещё нет RFC, а только черновик (draft). Поддержка ESNI (в версии черновика) уже более года есть на веб-серверах Cloudflare и в браузере Firefox (в основной ветке). Также, около года назад, я реализовал ESNI на тестовом сервере TLS 1.3 – https://tls13.1d.pw/. (Кстати, мой тестовый сервер – один из очень немногих серверов, поддерживающих ESNI, но не принадлежащих при этом Cloudflare.)

За год RFC для ESNI не появилось, но прогресс в разработке есть. Например, ESNI, судя по всему, получит собственный тип ресурсной записи DNS – сейчас ESNI-данные публикуются в DNS-записях типа TXT. Размещение в TXT создаёт некоторые проблемы, поскольку нередко доменные зоны настроены таким образом, что отдают TXT-записи произвольного содержания на запросы для всех имён внутри этих зон (это неверная, но распространённая практика). Кроме того, у тех администраторов, которые управляют достаточно большими пулами доменов и веб-серверов, проблемы возникают из-за различных конфликтов между именами в ESNI, именами внутри TLS-сессий на стороне сервера, и именами (хостнеймами) логических узлов. Отдельный тип DNS-записи поможет бороться с этими проблемами.

Интересно, что из задачи публикации ESNI-параметров в DNS – выросло отдельное направление, в рамках которого предлагается добавить механизм, позволяющий размещать в DNS целый набор дополнительных параметров, описывающих доступ к веб-ресурсам по HTTP(S) (в том числе, указание на перечень протоколов, нестандартных номеров портов, веб-фронтендов и т.д.).

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

Скорее всего, после выхода RFC – поддержка ESNI достаточно быстро появится в распространённых веб-серверах (например, Apache), что сделает эту технологию распространённой за пределами Cloudflare. Впрочем, для этого необходима ещё и поддержка в браузере Chrome, а она пока находится под вопросом: Google не очень-то охотно внедряет подобные технологии, позволяющие осуществлять децентрализованное управление криптографическими ключами в вебе.

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 года.