TLS, HTTP/2 и HTTP/3, прокси и VPN

Зачем это нужно

• Большая часть событий видна именно в прикладном слое, а TLS определяет, что доступно наблюдателю.
• Ошибки в TLS и в обращении с сертификатами — частый источник реальных инцидентов.
• Понимание прокси и VPN нужно для анализа архитектуры и объяснения видимости трафика.

Теория

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

HTTP — протокол запросов и ответов: метод, путь, заголовки, тело. HTTP/2 добавляет мультиплексирование в рамках одного соединения, HTTP/3 работает поверх QUIC по UDP. Заголовки определяют поведение кэша, политику безопасности и передачу учётных данных. Прокси бывают прямыми, обратными и перехватывающими; каждый меняет то, что видно, и то, кто отвечает за проверку трафика.

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

Ключевые концепции

Имя сервера в рукопожатии

Индикатор SNI и расширение шифрования этого имени в TLS 1.3 (ECH): влияет на видимость прикладного уровня.

HSTS

Политика, обязывающая браузер использовать только HTTPS для домена.

Взаимная аутентификация (mTLS)

Клиент тоже предъявляет сертификат — сервер проверяет обе стороны.

Привязка к сертификату

Certificate pinning: приложение доверяет только конкретному сертификату или ключу.

QUIC и HTTP/3

Транспорт поверх UDP со встроенным шифрованием и мультиплексированием.

Терминация TLS

Точка, где шифрование снимается (балансировщик, прокси): место, где возможен контроль содержимого.

Инструменты

• openssl — работа с сертификатами, проверка соединений, разбор цепочек.
• testssl.sh и SSL Labs — оценка конфигурации TLS и устаревших алгоритмов.
• curl — тонкая работа с запросами и заголовками.
• Wireshark с ключами сессии — разбор TLS в своей лаборатории.
• mitmproxy — учебный анализ прикладного трафика в своей сети.

Практика в легальных лабораториях

• Разверните локальный веб-сервер с самоподписанным сертификатом и изучите его цепочку через openssl.
• Разберите в Wireshark рукопожатие TLS 1.3 и определите, какие поля остаются открытыми.
• Сравните поведение HTTP/1.1 и HTTP/2 на одном сервере: заголовки, соединения, приоритеты.
• Настройте обратный прокси в лаборатории и опишите, что он видит и что скрывает.

Защита, детект и защитные меры

• Отключайте устаревшие версии TLS и слабые наборы алгоритмов, ведите инвентаризацию сертификатов и сроков.
• Внедряйте HSTS, а для внутренних сервисов оценивайте взаимную аутентификацию.
• Снимайте трафик там, где он раскрыт: на серверах приложений и на конечных точках.
• Отслеживайте аномалии: сертификаты с истёкшим сроком, самоподписанные, от редких издателей.

Правовая рамка и этика

• Перехват и расшифровка чужого трафика без разрешения недопустимы; в своей сети раскрытие допустимо только для собственных устройств и с уведомлением пользователей.
• Практика с перехватывающими прокси — только на своих стендах и в учебных лабораториях.

Типичные ошибки

• Считать, что HTTPS полностью скрывает метаданные: имена, размеры и тайминги часто остаются видимыми.
• Оставлять в продакшене устаревшие протоколы «для совместимости».
• Забывать продлевать сертификаты и ломать сервис.

Чек-лист «умею»

• Понимаю, что видит наблюдатель в зашифрованном трафике.
• Умею проверить цепочку сертификатов и конфигурацию TLS.
• Читаю заголовки HTTP и объясняю их влияние на безопасность.
• Различаю прямые, обратные и перехватывающие прокси.
• Могу объяснить, где в архитектуре снимается шифрование.

Вопросы на интервью

• Что увидит аналитик в зашифрованном трафике с TLS 1.3?
• Как проверить, что сервер не поддерживает слабые алгоритмы?
• Зачем нужна взаимная аутентификация внутри компании?

Источники и первоисточники

• RFC 8446 — TLS 1.3
• RFC 9110 — семантика HTTP
• OWASP — памятка по TLS