Андрей Созыкин 

Снова практическое занятие по защищенной версии протокола DNS, в этот раз по DNS over HTTPS.
 
Рассматриваем:
- Как использовать DNS over HTTPS в dig и kdig.
- Как настроить DNS over HTTPS в Google Chrome.
- Как запросы и ответы DNS over HTTPS выглядят в Wireshark.
 
В демонстрациях используем открытый сервер DNS over HTTPS от Яндекса.

Видео на других платформах: YouTube, VK, Дзен. 

Разбираемся с работой защищенной версии протокола DNS, которая работает поверх TLS.

Использовать DNS over TLS достаточно просто. Например, в команде dig нужно просто указать ключ +tls и адрес сервера DNS over TLS. В видео используется сервер Яндекс с адресом 77.88.8.8.

Кроме dig также можно использовать другой вариант утилиты работы с DNS из командной строки kdig.

В видео подробно рассматриваем с помощью Wireshark, как устроены запросы и ответы DNS over TLS.

Переходим к новому разделу курса по компьютерным сетям, который посвящен защищенным версиям протокола DNS. Обычный DNS передает данные по сети в открытом виде. Это означает, что их можно перехватить и узнать, на какие сайты вы ходите. Кроме того, злоумышленник может изменить ответ DNS сервера и отправить вам поддельный ответ. В результата вместо IP-адреса нужного сервера вы получите IP-адрес сервера злоумышленника. Более того, злоумышленники могут взломать один из серверов в системе DNS и через него распространять злонамеренные ответы DNS. 

К сожалению в DNS, в отличие от HTTP, нет единого подхода к защите. Вместо этого есть несколько вариантов защищенных протоколов: DNS over TLS, DNS over HTTPS и DNSSEC. 

DNS over TLS (DoT) и DNS over HTTPS (DoH) шифруют передаваемые по сети данные DNS с помощью TLS. Это позволяет защититься от просмотра передаваемых данных и изменений ответов DNS. Но шифрование не защищает от взлома DNS-сервера и распространения поддельных записей DNS.

В практиках по установке соединения TLS и по HTTPS мы использовали поле заголовка TLS Server Name Indication, сокращенно SNI. Давайте подробно рассмотрим, что это такое, зачем нужно и почему это поле важно.

При установке соединения TLS сервер должен выслать клиенту TLS-сертификат сервера в сообщении Server Hello. Но современные серверы на одном IP-адресе обслуживают несколько Web-сайтов. Например, сайт для практических занятий курса по сетям размещается на сервере GitHub Pages, где есть много других сайтов. Как серверу GitHub Pages узнать, что мы хотим подключиться именно к сайту networkscourse.ru?

В HTTP для решения этой задачи использовался заголовок Host, который вставлялся в первый запрос. Но при переходе на HTTPS мы сначала должны установить соединение TLS, и только после этого отправлять запрос HTTP с заголовком Host. А при установке соединения TLS сервер должен отправить клиенту сертификат сайта с нужным доменным именем, иначе клиент разорвет соединение.  

Именно для решения этой проблемы и было создано расширение TLS Server Name Indication(SNI). Его определили в RFC 3546 Transport Layer Security (TLS) Extensions. Поле SNI содержит доменное имя Web-сайта, к которому мы хотим подключиться. Клиент включает его в сообщение Client Hello при установке соединения. По значению SNI сервер выбирает нужный TLS-сертификат и отправляет клиенту. 

Важная особенность в том, что доменное имя сайта передается в поле SNI в открытом виде. Соединение TLS в это время еще не установлено, поэтому зашифровать SNI нет возможности. В результате ваш провайдер знает, на какие сайты вы ходите по HTTPS 🙂 (хотя сами передаваемые данные зашифрованы).

Поле SNI удобно использовать для фильтрации трафика HTTPS в Wireshark. Ранее в видео с практиками для подключения к https://networkscourse.ru мы просто перебирали четыре IP-адреса, на которых работает GitHub Pages. При использовании SNI это делать не обязательно: достаточно указать в фильтре имя, которое должно быть в поле SNI и Wireshark отберет нужные пакеты независимо от IP-адреса сервера. Пример фильтра: tls.handshake.extensions_server_name == "networkscourse.ru"

Продолжаем рассматривать защищенный протокол HTTPS, в этот раз практика с разбором в Wireshark.

Сначала убеждаемся, что данные HTTPS действительно шифруются при передаче по сети и их нельзя просмотреть просто так.

На втором этапе расшифровываем данные TLS и смотрим, как HTTP передается внутри TLS. Ничего специфичного там нет, запросы и ответы HTTP 1.1 в обычном текстовом виде.

Сейчас почти все браузеры и Web-серверы по умолчанию используют HTTP/2 или HTTP/3, поэтому для демонстрации запускаем сhrome из командной строки с флагом --disable-http2. Как работают HTTP/2 и HTTP/3 мы обязательно рассмотрим далее в курсе.

В новом видео по компьютерным сетям рассматриваем протокол HTTPS - HyperText Transfer Protocol Secure - защищенную версию протокола HTTP. 

HTTPS устроен достаточно просто - это обычный протокол HTTP, но сообщения передаются в зашифрованном виде через TLS, а не напрямую по TCP, как в обычном HTTP. Семантика HTTP осталась без изменений: те же самые запросы GET, POST и другие, ответы со статусами кодов HTTP, заголовки и все остальное, что мы рассматривали в лекциях по HTTP. 

Для серверов, которые работают по протоколу HTTPS, вводится новый широко известный порт 443 (HTTP использует порт 80). Также HTTPS использует другое название протокола в ссылках: https вместо http. Например, https://networkscourse.ru. Если используете порт 443, то в ссылке его можно не указывать. Но если сервер HTTPS запущен на другом порту, то его номер нужно обязательно прописать. 

Возможно вы обратили внимание в видео с практикой по установке соединения TLS, что для обмена ключами симметричного шифрования использовался гибридный алгоритм Диффи-Хеллмана на эллиптических кривых и ML-KEM. Как работает алгоритм Диффи-Хеллмана мы разбирали в курсе, а что за алгоритм ML-KEM? И для чего он нужен?

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) - это постквантовый алгоритм шифрования. В нем используется криптография на решетке (lattice-based cryptography), взломать такие алгоритмы квантовые компьютеры не смогут.

ML-KEM стандартизован NIST в документе FIPS 203. В нем определены три варианта ML-KEM-512, ML-KEM-768 и ML-KEM-1024, которые отличаются параметрами алгоритма ML-KEM, скоростью работы и уровнем безопасности. В видео при установке соединения TLS использовался вариант ML-KEM-768.

Зачем внедрять алгоритмы постквантового шифрования сейчас, когда квантовых компьютеров еще нет? Внедрение новых технологий в компьютерных сетях, как правило, занимает длительное время. Поэтому лучше начать делать это заранее, чтобы успеть к появлению квантовых компьютеров 😊

Для чего комбинировать алгоритмы Диффи-Хеллмана на эллиптических кривых и ML-KEM? Сейчас ML-KEM еще плохо изучен и если в нем найдут уязвимости, то алгоритма Диффи-Хеллмана будет достаточно для эффективной защиты (пока не появятся квантовые компьютеры 😊).

На Хабре есть отличная статья "Разбираем байты постквантовой ML-KEM на примере «браузерного» TLS", рекомендую изучить ее, если хотите детально разобраться, как именно ML-KEM используется при установке соединения TLS 1.3.

Практика по установке соединения - это последнее видео по TLS в обновленном курсе по компьютерным сетям. Дальше будем рассматривать HTTPS и защищенные варианты DNS.

В курсе я рассказываю только основы, без которых сложно понять общую логику работы всех протоколов компьютерных сетей. Если вы хотите разобраться в деталях работы TLS, то рекомендую огромную подробную статью Александра Венедюхина "Ключи, шифры, сообщения: как работает TLS". Александр начал писать ее в 2015 году и регулярно обновляет.

Рекомендую также блог Александра dxdt.blog, в котором есть много статей по компьютерным сетям, в том числе по защищенным сетевым протоколам.

В новом видео по компьютерным сетям на практике с помощью Wireshark рассматриваем, как проходит установка соединения TLS.

Основные темы видео:

- Какие сообщения передают друг другу клиент и сервер для установки соединения.

- Что такое SNI (Server Name Indication) в TLS и для чего оно используется.

- Как клиент и сервер договариваются об используемой версии TLS, алгоритму для обмена ключами симметричного шифрования и набору шифров TLS.

- Когда клиент и сервер начинают шифровать передаваемые данные.

- Как сервер передает клиенту сертификат для аутентификации, и сколько сертификатов передается при установке соединения.

Хайп на тему "ИИ скоро заменит всех программистов" постепенно проходит. Начали появляться взвешенные исследования о том, как ИИ реально влияет на разработку. О нескольких наиболее интересных исследованиях на эту тему я расскажу.

Начнем с исследования AI4SDLC 2025 от Т-Технологии. Они провели собственный опрос разработчиков с сентября по декабрь 2025, а также проанализировали аналогичные опубликованные исследования с 2023 по 2025 года.

Основной вывод: ИИ помогает писать код быстрее, но релизы от этого быстрее не становятся 😞. То есть эффект ограничен, узкое место с написания кода сместилось в интеграцию, тестирование, ревью и релизы. Пока живем, кожаные мешки 😊.

Почему так происходит? Ключевых факторов два. Первое и очевидное, большая часть разработчиков уже использует ИИ (по данным Т-Технологии 58% делают это часто или всегда). Но при этом только 11% доверяют сгенерированному коду. А 49% разработчиков прямо утверждают, что не доверяют.

В результате срок от коммита до развертывания в продуктив занимает недели или даже месяцы 😞. Причем этот срок не сокращается.
Какие выводы делают Т-Технологии? Устойчивый эффект от ИИ требует зрелой инженерной системы проверки. Нужен культурный сдвиг: от "пишу код" к "проектирую и проверяю". 

Какие еще интересные исследования эффектов применения ИИ для разработки ПО вы знаете? Пишите о них в комментариях.