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

Переходим к новому разделу курса по компьютерным сетям, который посвящен защищенным версиям протокола 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% разработчиков прямо утверждают, что не доверяют.

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

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

В новом видео по протоколу MCP на практике разбираемся как устроен уровень данных с помощью MCP Inspector.

В MCP Inspector можно посмотреть, какие сообщения передаются на уровне данных в окне "History". Там показано в сокращенном формате, нет полей с версией JSON-RPC, номером запроса/ответа и некоторых других служебных полей. Но вся полезная информация есть.

В видео сначала подключаемся к серверу Context7 и смотрим, какие сообщения передаются при инициализации соединения, получении списка инструментов и вызове инструментов.

Чтобы посмотреть, как получать промты с MCP сервера, подключаемся к MCP серверу Hugging Face. В MCP Inspector смотрим, какие сообщения передаются при получении списка промтов и запросе конкретного промта. 

Если вы внимательно читали RFC 9110 HTTP Semantics, то могли обратить внимание на странный код статуса HTTP 418. Это единственный код, для которого нет содержательного описания, но сказано, что он не используется (Unused). Зачем включать в стандарт код, который не используется?

Код HTTP 418 определен в первоапрельском RFC 2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). Это шуточный стандарт 1998 года, который описывает протокол управления кофе-машинами через HTTP. Сейчас, в эпоху интернета вещей и умных устройств, такой протокол даже выглядит вполне разумно 😊.

Ошибку HTTP 418 "I'm a teapot" должен возвращать чайник, если получит команды HTCPCP на приготовление кофе, т.к. чайник готовить кофе не умеет 😊.

Шутка получила поддержку в сообществе и широкое распространение. Например, у Google есть специальная страница для HTTP 418. Именно из-за популярности кода 418 пришлось его включить в стандарт семантики HTTP. Серьезные авторы RFC 9110 не осмелились написать, что означает HTTP 418, но мы все это знаем и любим😊