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

На сайте ТЦИ опубликована моя статья о технологиях DNS-over-HTTPS и DNS-over-TLS, о том, как эти технологии повлияют на развитие Интернета, на методы блокирования доступа и фильтрации трафика – “DNS-доступ под защитой: DoT и DoH“. Цитата:

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

В блоге Cloudflare подробная статья, рассказывающая популярно про технологию сокрытия имени сервера в TLS: Encrypted Client Hello (ECH).

ECH является полностью переработанным вариантом ESNI, однако, как пишут в статье, от ESNI на серверах Cloudflare пока отказываться не собирается, но лишь по той причине, что спецификация ECH ещё не достигла нужной “степени готовности”. Cloudflare сейчас является крупнейшим провайдером веб-доступа, поддерживающим ESNI и, собственно, единственным сервисом с массовой поддержкой этой технологии. При этом спецификация ESNI – так и не достигла статуса RFC, превратившись, на стадии очередного черновика, в ECH.

(Как работает ESNI – можно посмотреть на моём тестовом сервере https://tls13.1d.pw/, а вот поддержку ECH я ещё не собрался дописать.)

На сайте ТЦИ опубликована моя статья с результатами измерения распространённости поддержки TLS 1.3 на HTTPS-узлах Рунета. Под Рунетом подразумеваются имена второго уровня в зонах .RU, .SU, .РФ. Измерялось наличие поддержки TLS 1.3 для TCP-соединений на номере порта 443 (это номер HTTPS). TLS 1.3 уже довольно широко поддерживается, несмотря на относительную новизну протокола. Описание методики и результаты – в статье.

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

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

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

По адресу audit.statdom.ru заработал полезный сервис Технического центра Интернет (ТЦИ), позволяющий автоматически проверить многие настройки веб-узла, с точки зрения их соответствия современным рекомендациям. Вводите имя (хостнейм, в формате test.ru) – робот опрашивает соответствующие узлы и выводит подробный отчёт, содержащий параметры TLS, HTTP/HTTPS (заголовки безопасности), DNS и MX, с рекомендациями: что включить и что работает не так, как ожидается. Кроме того, вычисляется рейтинг узла в баллах. Одной из особенностей этого сервиса является подробная проверка DNS, например, есть обнаружение доступности DNS-over-TLS (DoT) на авторитативных серверах.

Обратите внимание, что отправной точкой для исследования параметров является введённое имя хоста (имя сервера), при этом робот не следует HTTP-редиректам, а выводит результат для того имени, которое задано. Это означает, что если вы хотите проверить узел www.test.ru, для которого настроен редирект test.ru -> www.test.ru, то вводить нужно имя с www.

Ссылка: audit.statdom.ru.

(Я имею непосредственное отношение к разработке данного сервиса.)

Написал про HTTP-заголовки, связанные с обеспечением безопасности доступа браузеров (и не только) к веб-узлам, – статья опубликована на сайте ТЦИ.

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

Пара статей, которые вышли некоторое время назад.

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

На ресурсе D-Russia.ru – моя статья о зависимостях веб-сайтов от “внешних” библиотек. Речь про различные jQuery и т.п., которые загружаются с централизованных сервисов, являющихся внешними относительно сайта-источника. Такие зависимости очень распространены, но про них забывают (и пользователи, и администраторы веб-сайтов).
Ссылка: “Централизованный Интернет“.

По адресу http://hold-my-beer.xyz/ (да, он несколько странный, но правильный) – я разместил веб-интерфейс экспериментального сервиса, который пытается определить, поддерживает ли ваш DNS-резолвер валидацию DNSSEC. Довольно давно я уже сделал сервис, проверяющий поддержку DNSSEC при помощи браузера. Отличие нового эксперимента в том, что здесь проверка происходит также и на серверной стороне, а в браузер передаются адреса резолверов – как они видны на авторитативных серверах. То есть, методика измерения совсем другая, более полная, так как позволяет собирать статистику. Но, повторюсь, это пока эксперимент.

Для проверки – достаточно зайти браузером по ссылке. Там есть и визуальный “флаг”, который покажет, поддерживается ли валидация DNSSEC (вверху страницы, зелёный/красный). Сразу оговорю технический момент, связанный с сервисом резолвера Google Public DNS (8.8.8.8): этот сервис заявлен как валидирующий, но в случае данного теста – браузер покажет, что поддержки DNSSEC нет. И это действительно так. Причина в том, что для теста используются имена (DNS-зоны) четвёртого уровня и ниже, и здесь сервис Google почему-то не проводит валидацию (возможно, так задумано, возможно – это ошибка: нужно будет написать в Google). При использовании, например, Cloudflare (1.1.1.1) – всё работает нормально, как ожидается.

http://hold-my-beer.xyz/

(Это временный сервис, точнее – демонстратор технологии.)

Update (25/07/2019): эксперимент закончен, сервис пока недоступен.