Защищённые соединения: криптография и TLS

В предыдущих темах сеть рассматривалась как система доставки: IP находит путь между хостами, TCP превращает ненадёжную доставку дейтаграмм в упорядоченный поток байтов, DNS сопоставляет именам адреса, HTTP передаёт поверх TCP запросы и ответы. Ни один из этих протоколов не задавался вопросом, кто ещё видит передаваемые байты и не изменил ли их кто-нибудь по дороге. Пакет проходит через коммутаторы офиса, точку доступа Wi-Fi, маршрутизаторы нескольких провайдеров и точек обмена трафиком, и каждый из этих узлов технически способен прочитать и переписать его содержимое. Как было показано в теме 15, даже ответ DNS может быть подделан, и тогда клиент установит соединение совсем не с тем сервером, к которому обращался.

Настоящая тема посвящена тому, как поверх такой сети строится защищённый канал: соединение, содержимое которого не может прочитать посторонний, не может незаметно изменить посредник и которое гарантированно ведёт к нужному собеседнику. Стандартное решение для Интернета — протокол защиты транспортного уровня (англ. Transport Layer Security, TLS). Сегодня он защищает подавляющую часть веб-трафика (HTTPS — это HTTP поверх TLS), почту, DNS поверх TLS, и встроен в транспортный протокол QUIC, рассмотренный в теме 16.

TLS собран из криптографических примитивов — шифров, хеш-функций, подписей, обмена ключами, — и понять протокол, не понимая назначения каждого из них, невозможно. Поэтому изложение построено так. Сначала формулируются угрозы и требуемые свойства канала. Затем рассматриваются примитивы на уровне, достаточном для понимания их роли и ограничений; обмен ключами Диффи — Хеллмана разбирается на числовом примере. Третий раздел посвящён инфраструктуре открытых ключей: сертификатам X.509, цепочкам доверия, отзыву, Certificate Transparency и автоматическому выпуску сертификатов. Четвёртый раздел разбирает TLS 1.3 по сообщениям и по байтам, пятый — практику: взаимную аутентификацию, типичные ошибки конфигурации, атаки на понижение версии и HSTS. Математические основания криптографии в теме не излагаются: алгоритмы рассматриваются как «чёрные ящики» с известными свойствами.

Угрозы в сети и свойства защищённого канала

Пассивный перехват, подмена и посредник

Модель угроз сетевой безопасности исходит из пессимистичного допущения: противник контролирует сеть — читает, удаляет, задерживает, переупорядочивает, повторяет и вставляет пакеты (модель Долева — Яо, 1983). Это не значит, что каждый канал прослушивается; это значит, что безопасность протокола не должна зависеть от честности промежуточных узлов.

Пассивный противник (англ. eavesdropper) только наблюдает: подключается к открытой сети Wi-Fi, зеркалирует порт коммутатора, записывает трафик на магистрали, чтобы прочитать пароли, cookie сессии, письма. Пассивный перехват не оставляет следов, а записанный сегодня трафик может быть расшифрован через годы, если станет известен ключ; к этому предстоит вернуться при обсуждении прямой секретности.

Активный противник изменяет трафик: подменяет содержимое (вставляет код в загружаемую страницу), повторяет перехваченные сообщения (дважды отправленное «перевести 1000 рублей»), обрывает соединения. Наиболее сильная форма активной атаки — атака «человек посередине» (англ. man-in-the-middle, MITM): противник встраивается между клиентом и сервером, для клиента выдаёт себя за сервер, для сервера — за клиента и пересылает данные между двумя соединениями, читая и изменяя их по своему усмотрению. Встроиться в путь можно разными способами, знакомыми по предыдущим темам: подменой ARP в локальной сети (тема 18), поддельной точкой доступа, подложным ответом DHCP со «своим» DNS-сервером, подделкой ответа DNS (тема 15), перехватом префикса в BGP (тема 10). Поэтому защиту нельзя строить на предположении, что «трафик и так придёт куда надо».

Конфиденциальность, целостность, аутентификация

Защищённый канал должен обеспечивать три свойства.

• Конфиденциальность (англ. confidentiality): содержимое канала доступно только его сторонам. Обеспечивается шифрованием.
• Целостность (англ. integrity): любое изменение, вставка, удаление или переупорядочение данных обнаруживается получателем. Обеспечивается кодами аутентификации сообщений и нумерацией записей.
• Аутентификация (англ. authentication): сторона уверена, с кем установлено соединение. Обеспечивается цифровыми подписями и сертификатами.

Эти свойства не сводятся друг к другу. Шифрование без проверки целостности не мешает изменять шифротекст: у потокового шифра инверсия бита шифротекста инвертирует тот же бит открытого текста, и противник, знающий формат сообщения, изменит сумму перевода, не зная ключа. Шифрование и целостность без аутентификации бесполезны против посредника: клиент установит защищённый канал — с противником. Аутентификация сервера — самая сложная часть TLS, требующая внешней инфраструктуры сертификатов.

Чего TLS не обеспечивает, следует назвать явно. TLS не скрывает адреса IP и порты, размеры и моменты передачи данных, по которым часто можно определить посещаемый сайт; имя сервера по умолчанию передаётся открыто (расширение SNI). TLS не защищает данные на конечных узлах после расшифровки. Наконец, TLS защищает канал, а не сообщение: данные, полученные по TLS, ничем не доказывают третьему лицу своё происхождение.

Место TLS в стеке протоколов

TLS работает поверх надёжного упорядоченного транспорта — как правило, TCP — и предоставляет приложению такой же поток байтов, но защищённый. Приложение вызывает вместо send и recv функции библиотеки TLS, поэтому TLS относят то к «уровню 4,5», то к прикладному. Защищённым вариантам протоколов выделены отдельные порты: HTTPS — 443, SMTP с отправкой через TLS — 465, IMAPS — 993, DNS поверх TLS — 853. Другой способ — команда STARTTLS внутри уже открытого соединения (SMTP, IMAP), уязвимая к удалению активным посредником.

Для дейтаграммного транспорта существует вариант DTLS, а в QUIC (тема 16) рукопожатие TLS 1.3 встроено в сам транспортный протокол: QUIC использует сообщения рукопожатия TLS, но шифрует пакеты собственным механизмом. Таким образом, изложенное ниже о рукопожатии TLS 1.3 полностью относится и к HTTP/3.

Предшественник TLS — протокол SSL (англ. Secure Sockets Layer) компании Netscape, версии 2.0 (1995) и 3.0 (1996). В IETF протокол стандартизован как TLS 1.0 (1999), 1.1 (2006), 1.2 (2008) ¹² и 1.3 (2018) ¹; допустимы сегодня только TLS 1.2 и 1.3 ⁶. Название SSL сохранилось в обиходе («SSL-сертификат») и в именах программ (OpenSSL).

Криптографические примитивы

Симметричные шифры и аутентифицированное шифрование

Симметричный шифр использует один и тот же секретный ключ для зашифрования и расшифрования. Современные симметричные шифры быстры (гигабайты в секунду на ядро процессора) и при длине ключа 128 бит и более не поддаются перебору. Основной блочный шифр — AES (англ. Advanced Encryption Standard), шифрующий блоки по 128 бит ключом длиной 128, 192 или 256 бит. Для сообщений произвольной длины блочный шифр применяется в одном из режимов работы. Второй широко используемый шифр — потоковый ChaCha20: он порождает из ключа и одноразового числа псевдослучайную гамму, которая складывается с открытым текстом операцией «исключающее или». ChaCha20 быстро работает и без аппаратной поддержки AES, поэтому популярен на мобильных устройствах.

Шифрование само по себе не защищает целостность. Исторически к шифру добавляли отдельный код аутентификации, и способ их сочетания оказался источником уязвимостей: на схеме «сначала MAC, потом шифрование» в режиме CBC из TLS 1.2 построены атаки на дополнение (англ. padding oracle) — POODLE, Lucky Thirteen. Современный подход — аутентифицированное шифрование с присоединёнными данными (англ. Authenticated Encryption with Associated Data, AEAD), единый алгоритм с интерфейсом ¹⁴:

Зашифровать(ключ K, одноразовое число N, открытый текст P, присоединённые данные A) -> шифротекст C || тег T
Расшифровать(K, N, C || T, A) -> P   или   ОШИБКА, если C, T или A изменены

Присоединённые данные A не шифруются, но защищаются тегом: в TLS это заголовок записи. Тег — короткая (обычно 16 байт) контрольная величина, которую невозможно подделать без ключа. Если при расшифровании тег не сходится, алгоритм не возвращает никакого открытого текста — это исключает целый класс атак, в которых противник изучает реакцию получателя на испорченные данные. TLS 1.3 разрешает только AEAD-алгоритмы: AES-GCM (режим счётчика с аутентификатором GHASH), ChaCha20-Poly1305 и AES-CCM ¹.

Требование к одноразовому числу (англ. nonce) принципиально: пара «ключ — одноразовое число» не должна повторяться никогда. Для AES-GCM повтор приводит к катастрофе: противник получает сумму двух открытых текстов по модулю 2 и возможность подделывать теги. Поэтому в TLS одноразовое число не передаётся по сети, а вычисляется из номера записи, который у каждой стороны свой и монотонно растёт (подробнее — в разделе о TLS 1.3).

Хеш-функции и HMAC

Криптографическая хеш-функция отображает сообщение произвольной длины в короткий «отпечаток» фиксированной длины: SHA-256 — в 256 бит, SHA-384 — в 384 бита. От неё требуются три свойства: по отпечатку невозможно найти сообщение (стойкость к нахождению прообраза), по сообщению невозможно найти другое с тем же отпечатком (стойкость к нахождению второго прообраза), невозможно найти вообще какую-либо пару сообщений с одинаковым отпечатком (стойкость к коллизиям). Последнее свойство самое трудное: из-за «парадокса дней рождения» коллизию в выходе длиной n бит можно найти примерно за 2 в степени n/2 попыток, поэтому 256-битный хеш даёт 128-битную стойкость к коллизиям. Хеш-функции MD5 и SHA-1 считаются сломанными: для MD5 коллизии вычисляются за секунды, для SHA-1 первая практическая коллизия опубликована в 2017 году. В TLS 1.3 обе функции запрещены для подписи рукопожатия (сообщение CertificateVerify); SHA-1 допускается лишь как унаследованный алгоритм подписи сертификатов ¹.

printf 'Severny Uzel' | sha256sum
printf 'Severny uzel' | sha256sum

b1e0ce97ceffb01b34ee9210323990028b62c37eacb8281ee5e145209d38b2c2  -
e60e47670ab6549bf04fa3c1e9bc1e0c3dccd041721030e1808e3ae665337905  -

Изменение одной буквы меняет примерно половину битов отпечатка непредсказуемым образом (лавинный эффект).

Хеш-функция не имеет ключа, и противник, изменивший сообщение, просто пересчитает отпечаток. Для проверки целостности нужен код аутентификации сообщения (англ. Message Authentication Code, MAC) — функция от ключа и сообщения. Стандартная конструкция MAC на основе хеш-функции — HMAC ¹¹:

HMAC(K, m) = H( (K XOR opad) || H( (K XOR ipad) || m ) )

где ipad и opad — константы (байты 0x36 и 0x5C, повторённые до длины блока хеш-функции). Двойное хеширование нужно для защиты от атаки удлинения сообщения, которой подвержена наивная конструкция H(K || m). Помимо проверки целостности HMAC служит строительным блоком функций выработки ключей. В TLS 1.3 все ключи выводятся функцией HKDF (англ. HMAC-based Key Derivation Function) ⁸, которая состоит из двух шагов: HKDF-Extract(соль, исходный материал) сжимает неравномерно распределённый секрет (например, результат обмена Диффи — Хеллмана) в равномерный псевдослучайный ключ, а HKDF-Expand(ключ, контекст, длина) порождает из него сколько угодно независимых ключей для разных целей, различаемых строкой контекста.

Асимметричная криптография: шифрование, подписи, обмен ключами

Симметричная криптография требует заранее общего секрета, что невыполнимо, когда клиент впервые обращается к незнакомому серверу. Решение предложили в 1976 году Диффи и Хеллман ⁷: криптография с открытым ключом, в которой у каждой стороны есть пара ключей — закрытый (англ. private key), хранимый в секрете, и открытый (англ. public key), который можно публиковать. Асимметричные операции на порядки медленнее симметричных, поэтому служат только для установления общего секрета и аутентификации.

Асимметричные алгоритмы решают три задачи.

• Шифрование с открытым ключом: зашифровать может каждый, расшифровать — только владелец закрытого ключа. Классический алгоритм — RSA (Ривест, Шамир, Адлеман, 1977), стойкость которого основана на трудности разложения большого числа на множители. Учебный пример: n = 61 · 53 = 3233, открытая экспонента e = 17, закрытая d = 2753; число 65 шифруется как 65 в степени 17 по модулю 3233 = 2790, а 2790 в степени 2753 по модулю 3233 снова даёт 65. Реальные ключи RSA имеют модуль длиной 2048–4096 бит.
• Цифровая подпись: подписать может только владелец закрытого ключа, проверить — каждый, у кого есть открытый. Подпись вычисляется от хеша сообщения. Используются RSA (схемы PKCS#1 v1.5 и PSS), ECDSA на эллиптических кривых P-256 и P-384, а также EdDSA (Ed25519).
• Обмен ключами (англ. key exchange, key agreement): две стороны, обменявшись открытыми значениями по открытому каналу, вычисляют общий секрет, неизвестный наблюдателю. Это протокол Диффи — Хеллмана (DH) и его вариант на эллиптических кривых (ECDH).

Криптография на эллиптических кривых (англ. Elliptic Curve Cryptography, ECC) даёт ту же стойкость при гораздо меньших ключах: 256-битный ключ на кривой соответствует примерно 128-битной стойкости, для которой RSA нужен модуль около 3072 бит. В TLS 1.3 основные группы для обмена ключами — X25519 (кривая Curve25519) ¹⁰ и secp256r1 (P-256); открытый ключ X25519 занимает всего 32 байта.

Обмен Диффи — Хеллмана: числовой пример

Идея обмена Диффи — Хеллмана ⁷ основана на функции, которую легко вычислить, но трудно обратить: возведении в степень по модулю простого числа. Стороны заранее договариваются об открытых параметрах — простом числе p и генераторе g (числе, степени которого по модулю p пробегают все ненулевые остатки). Затем:

1. Алиса выбирает случайный секрет a и отправляет Бобу A = g в степени a по модулю p.
2. Боб выбирает случайный секрет b и отправляет Алисе B = g в степени b по модулю p.
3. Алиса вычисляет s = B в степени a по модулю p, Боб вычисляет s = A в степени b по модулю p.

Оба получают одно и то же число, поскольку B в степени a = (g в степени b) в степени a = g в степени ab = (g в степени a) в степени b = A в степени b (все вычисления по модулю p). Наблюдатель видит p, g, A и B, но, чтобы получить s, ему нужно найти a по A — решить задачу дискретного логарифмирования, для которой при больших p не известно эффективного алгоритма.

Разберём обмен на малых числах: p = 23, g = 5, секрет Алисы a = 6, секрет Боба b = 15. Возведение в большую степень выполняется методом последовательного возведения в квадрат: вычисляются g, g в квадрате, g в четвёртой, g в восьмой степени по модулю p, и нужная степень собирается из них по двоичной записи показателя.

Алиса: a = 6 = 4 + 2, поэтому A = 4 · 2 = 8. Боб: b = 15 = 8 + 4 + 2 + 1, поэтому B = 16 · 4 · 2 · 5 = 640 = 27 · 23 + 19, то есть B = 19. По сети передаются числа 8 и 19. Далее Алиса вычисляет 19 в 6-й степени по модулю 23. Удобно заметить, что 19 ≡ −4, поэтому результат равен 4 в 6-й степени = 4096 = 178 · 23 + 2, то есть s = 2. Боб вычисляет 8 в 15-й степени по модулю 23: 8 во 2-й = 64 ≡ 18, 8 в 4-й ≡ 18 · 18 = 324 ≡ 2, 8 в 8-й ≡ 4, откуда 8 в 15-й ≡ 4 · 2 · 18 · 8 = 1152 = 50 · 23 + 2, то есть тоже s = 2. Общий секрет совпал, хотя ни a, ни b, ни s по сети не передавались. Схема обмена показана на рисунке ниже.

В этом примере противник легко найдёт a перебором: достаточно вычислить не более 22 степеней числа 5. При реальных параметрах это невозможно: группа ffdhe2048 построена на 2048-битном простом числе, и лучшие известные алгоритмы оставляют ей стойкость порядка 100 бит. В ECDH роль возведения в степень играет умножение точки кривой на число, и X25519 при 32-байтовых ключах стойкостью превосходит ffdhe2048.

Обмен Диффи — Хеллмана сам по себе не аутентифицирует стороны. Активный посредник Мэллори, получив A от Алисы, отправляет Бобу собственное значение M, а Алисе в ответ — тоже M. Алиса вычисляет общий секрет с Мэллори, Боб — тоже с Мэллори, и посредник расшифровывает и перешифровывает весь трафик (нижняя часть рисунка). Защититься можно только аутентификацией открытых значений: в TLS сервер подписывает стенограмму рукопожатия, включающую его значение обмена, закрытым ключом, открытый ключ которого удостоверен сертификатом.

Прямая секретность

Общий секрет можно установить двумя способами. При «обмене ключами RSA» TLS 1.2 клиент шифрует случайный секрет открытым ключом сервера из сертификата. При эфемерном обмене стороны выполняют обмен Диффи — Хеллмана со свежими одноразовыми секретами a и b, а закрытый ключ сервера служит только для подписи; такой вариант обозначается буквой E: DHE, ECDHE.

Разница проявляется, когда закрытый ключ сервера через годы скомпрометирован — украден или извлечён через уязвимость вроде Heartbleed (2014). При обмене ключами RSA противник, записавший трафик, расшифрует весь архив переписки. При эфемерном обмене ключ сервера ничего не даёт: секреты a и b стёрты по окончании рукопожатия. Это свойство называется прямой секретностью (англ. forward secrecy, perfect forward secrecy, PFS). TLS 1.3 исключил обмен ключами RSA и статический DH, поэтому каждое полное рукопожатие TLS 1.3 обладает прямой секретностью ¹.

Инфраструктура открытых ключей

Сертификат X.509 и разбор реального сертификата

Подпись сервера в рукопожатии доказывает только то, что собеседник владеет некоторым закрытым ключом. Клиенту нужно знать большее: что этот ключ принадлежит именно letsencrypt.org, а не посреднику. Связь между именем и открытым ключом удостоверяет сертификат — документ, содержащий имя субъекта, его открытый ключ и срок действия, подписанный третьей стороной, которой доверяет клиент, — удостоверяющим центром (УЦ, англ. Certificate Authority, CA). Совокупность УЦ, сертификатов, правил их выпуска, проверки и отзыва называют инфраструктурой открытых ключей (англ. Public Key Infrastructure, PKI). В Интернете используется формат сертификатов X.509 версии 3, профиль которого определён в RFC 5280 ².

Сертификат состоит из трёх частей: тела tbsCertificate (англ. to be signed), идентификатора алгоритма подписи и самой подписи УЦ, вычисленной над закодированным телом. Тело кодируется по правилам DER (англ. Distinguished Encoding Rules) нотации ASN.1, а для хранения в текстовых файлах переводится в Base64 между строками -----BEGIN CERTIFICATE----- и -----END CERTIFICATE----- (формат PEM). Получим и разберём сертификат реального сайта:

openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org </dev/null 2>/dev/null \
  | openssl x509 -noout -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            05:43:93:3b:e3:86:b3:a2:b3:ad:d5:34:f2:10:3b:c8:b6:5f
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = YE2
        Validity
            Not Before: Sep  4 14:34:32 2026 GMT
            Not After : Dec  3 14:34:31 2026 GMT
        Subject: CN = letsencrypt.org
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:e9:e5:40:7b:43:1e:46:b9:8e:45:e4:aa:cb:40: ...
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                16:68:8D:1E:2A:32:48:8C:B5:F1:10:0A:16:08:37:08:3B:9D:30:23
            X509v3 Authority Key Identifier:
                B9:59:F2:8E:CF:22:F0:86:D3:37:48:FF:76:14:18:BA:82:D8:55:87
            Authority Information Access:
                CA Issuers - URI:http://ye2.i.lencr.org/
            X509v3 Subject Alternative Name:
                DNS:cp.letsencrypt.org, ..., DNS:letsencrypt.com, DNS:letsencrypt.org,
                DNS:www.lencr.org, DNS:www.letsencrypt.com, DNS:www.letsencrypt.org
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://ye2.c.lencr.org/96.crl
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Log ID    : D8:09:55:3B:94:4F:7A:FF:C8:16:19:6F:94:4F:85:AB:...
                    Timestamp : Sep  4 15:33:02.377 2026 GMT
                ...
    Signature Algorithm: ecdsa-with-SHA384
    Signature Value:
        30:65:02:31:00:ee:1d:b0:7c:35:88:98:15:57:b8:88:73:23: ...

Пройдём по полям (вывод получен в октябре 2026 года; при повторении команды значения будут другими, поскольку сертификат регулярно заменяется).

• Version: 3 — версия формата, допускающая расширения; Serial Number — уникальный в пределах УЦ случайный номер длиной до 20 байт ².
• Signature Algorithm — алгоритм подписи УЦ (ECDSA с SHA-384); он же повторён перед Signature Value после тела.
• Issuer и Subject — отличительные имена (англ. Distinguished Name) издателя и субъекта: страна C, организация O, общее имя CN. Издатель — промежуточный УЦ Let's Encrypt YE2.
• Validity — интервал действия. Этот сертификат действует 90 дней. Короткие сроки уменьшают ущерб от компрометации ключа; требования CA/Browser Forum, объединения УЦ и производителей браузеров, предусматривают поэтапное сокращение максимального срока публичных сертификатов до 47 дней к 2029 году.
• Subject Public Key Info — открытый ключ субъекта: точка на кривой P-256, записанная в несжатом виде (байт 04, затем координаты x и y по 32 байта).
• Key Usage: Digital Signature и Extended Key Usage: TLS Web Server Authentication — ограничения назначения ключа: он может использоваться только для подписи в роли TLS-сервера. Пометка critical означает, что программа, не понимающая расширение, обязана отвергнуть сертификат ².
• Basic Constraints: CA:FALSE — сертификат конечного субъекта; подписывать им другие сертификаты нельзя.
• Subject Key Identifier и Authority Key Identifier — идентификаторы ключа субъекта и ключа издателя. По совпадению AKI этого сертификата с SKI сертификата YE2 клиент находит издателя при построении цепочки.
• Authority Information Access — адрес для загрузки сертификата издателя.
• Subject Alternative Name (SAN) — список имён, для которых действителен сертификат: здесь десять имён DNS. Именно с SAN клиент сверяет имя из URL; поле CN субъекта браузеры для этого давно не используют. Допускаются шаблоны вида *.example.com, покрывающие ровно один уровень имени.
• Certificate Policies: 2.23.140.1.2.1 — идентификатор политики CA/Browser Forum для сертификатов с проверкой только владения доменом (англ. Domain Validation, DV): УЦ удостоверился, что заявитель управляет доменом, но не проверял организацию.
• CRL Distribution Points — адрес списка отзыва (подробнее ниже). Адреса службы OCSP в сертификате нет: Let's Encrypt прекратил поддержку OCSP в 2025 году.
• CT Precertificate SCTs — подписанные метки времени журналов Certificate Transparency, доказывающие, что сертификат опубликован (подробнее ниже).

Цепочка доверия и корневые хранилища

Подпись на сертификате сайта проверяется открытым ключом издателя, доверие к которому следует из сертификата издателя, подписанного следующим УЦ, и так далее до корневого сертификата (англ. root certificate), который подписан своим же ключом (самоподписанный) и которому клиент доверяет безусловно, потому что тот заранее находится в его корневом хранилище (англ. trust store). Последовательность сертификатов от сертификата сервера до корня называют цепочкой сертификации, а процедуру её проверки — проверкой пути сертификации ². Структура цепочки показана на рисунке.

Корневые ключи хранят в отключённых от сети аппаратных модулях и используют лишь для подписи сертификатов промежуточных (выпускающих) УЦ; повседневная работа ведётся ключами промежуточных УЦ, и при компрометации отзывается промежуточный сертификат, а не корень, зашитый в миллиарды устройств. Сервер обязан отправить клиенту свой сертификат и все промежуточные; корень отправлять бессмысленно — клиент всё равно должен найти его у себя. Распространённая ошибка конфигурации — сервер отдаёт только собственный сертификат: браузер, который ранее встречал нужный промежуточный сертификат или загружает его по Authority Information Access, открывает сайт, а curl или приложение на Python сообщает «unable to get local issuer certificate».

Цепочка letsencrypt.org из примера выглядит так:

openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org </dev/null 2>/dev/null \
  | grep -E '^ *[0-9] s:|^ *i:|Verif'

 0 s:CN = letsencrypt.org
   i:C = US, O = Let's Encrypt, CN = YE2
 1 s:C = US, O = Let's Encrypt, CN = YE2
   i:C = US, O = ISRG, CN = Root YE
 2 s:C = US, O = ISRG, CN = Root YE
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X2
Verification: OK

Сервер прислал три сертификата. Третий — сертификат нового корня Root YE, подписанный более старым корнем ISRG Root X2 (перекрёстная подпись, англ. cross-signing): клиенты, в хранилище которых нового корня ещё нет, построят цепочку до ISRG Root X2. Так УЦ вводит новые корни, не дожидаясь обновления всех устройств.

При проверке пути для каждого звена клиент проверяет подпись ключом следующего звена, совпадение поля Issuer с Subject издателя, срок действия, наличие у издателя CA:TRUE и права keyCertSign, ограничение длины пути pathlen, отсутствие отзыва; для сертификата сервера дополнительно — совпадение имени с SAN и назначение serverAuth. Ошибка на любом шаге означает отказ в соединении.

Корневые хранилища ведут производители операционных систем и браузеров: Mozilla (хранилище используют Firefox и большинство дистрибутивов Linux — пакет ca-certificates, файл /etc/ssl/certs/ca-certificates.crt), Apple, Microsoft, Google. В каждом около полутора сотен корней, и любой из этих УЦ технически может выпустить сертификат для любого домена. Это главная слабость модели: безопасность всех сайтов определяется самым слабым УЦ. Угроза реальна: в 2011 году взломанный нидерландский УЦ DigiNotar выпустил поддельный сертификат для *.google.com, использованный для перехвата трафика. Ответом на эту слабость стали Certificate Transparency и записи CAA в DNS, ограничивающие круг УЦ, которые вправе выпускать сертификаты для домена.

Отзыв сертификатов: CRL, OCSP и stapling

Если закрытый ключ сервера скомпрометирован, сертификат нужно объявить недействительным до истечения срока — отозвать. RFC 5280 определяет списки отзыва сертификатов (англ. Certificate Revocation List, CRL): подписанный УЦ список серийных номеров отозванных сертификатов, публикуемый по адресу из расширения CRL Distribution Points и обновляемый с указанной периодичностью ². Недостаток CRL — размер: у крупного УЦ список может содержать сотни тысяч записей.

Протокол OCSP (англ. Online Certificate Status Protocol) ⁹ позволяет запросить у УЦ подписанный ответ о статусе одного сертификата: «действителен», «отозван» или «неизвестен». Но OCSP замедляет открытие сайта, раскрывает УЦ, какие сайты посещает пользователь, и ненадёжен: при недоступности сервера OCSP браузеры продолжают соединение («мягкий отказ», англ. soft-fail), и посредник может просто заблокировать запрос.

Частичное решение — сшивание OCSP (англ. OCSP stapling): сервер сам периодически получает свежий подписанный ответ OCSP и прикладывает его к сертификату в рукопожатии (расширение status_request ¹³; в TLS 1.3 ответ передаётся внутри сообщения Certificate). Ответ подписан УЦ, поэтому сервер не может его подделать, а клиенту не нужно никуда обращаться. На практике отзыв в публичной PKI работает плохо, и отрасль движется в сторону коротких сроков действия: сертификат на несколько недель сам перестаёт действовать раньше, чем отзыв успел бы дойти до всех клиентов. Браузеры распространяют сжатые сведения об отозванных сертификатах собственными механизмами (CRLSets в Chrome, CRLite в Firefox), а Let's Encrypt, как отмечалось, полностью отказался от OCSP в пользу CRL.

Certificate Transparency, Let's Encrypt и ACME

Certificate Transparency (CT) ³ решает проблему «тайного» выпуска сертификатов. Каждый публичный сертификат записывается в несколько общедоступных журналов, устроенных как дерево Меркла — хеш-дерево, допускающее только добавление: изменение прошлой записи обнаруживается по несовпадению хешей. Журнал, приняв предварительную версию сертификата, выдаёт подписанную метку времени SCT (англ. Signed Certificate Timestamp) — обещание включить запись в дерево. УЦ вставляет SCT в итоговый сертификат (расширение CT Precertificate SCTs в разобранном выше примере), и браузеры Chrome и Safari отвергают публичные сертификаты без достаточного числа SCT от разных журналов. CT не мешает выпустить поддельный сертификат, но делает его выпуск заметным: владелец домена может отслеживать журналы, например через сервис crt.sh, и узнать о любом сертификате на своё имя.

curl -s 'https://crt.sh/?q=letsencrypt.org&output=json' | python3 -m json.tool | head -20

Долгое время сертификат стоил денег и требовал ручных действий раз в год. Некоммерческий УЦ Let's Encrypt, начавший выпуск в 2015 году, сделал сертификаты DV бесплатными и автоматическими, что и позволило перевести большинство сайтов на HTTPS. Протокол автоматического взаимодействия с УЦ стандартизован как ACME (англ. Automatic Certificate Management Environment) ⁴. Клиент ACME (например, certbot) регистрирует учётную запись, создаёт заказ на сертификат для списка имён и для каждого имени проходит проверку владения — одно из испытаний (англ. challenge):

• http-01 — разместить файл со значением, полученным от УЦ и связанным с ключом учётной записи, по адресу http://<домен>/.well-known/acme-challenge/<токен>; УЦ загружает его по HTTP на порт 80;
• dns-01 — опубликовать запись TXT _acme-challenge.<домен>; единственный способ получить шаблонный сертификат *.example.com;
• tls-alpn-01 — ответить на соединение TLS с особым протоколом ALPN специальным сертификатом на порту 443.

После успешной проверки клиент отправляет запрос на сертификат с открытым ключом сервера и получает цепочку сертификатов. Проверка http-01 идёт по незащищённому HTTP и доверяет маршрутизации и DNS: противник, перехвативший трафик к домену (например, перехватом префикса BGP), может получить сертификат. Поэтому УЦ проверяют домен из нескольких точек в разных автономных системах.

Протокол TLS 1.3

Протокол записей

TLS состоит из двух уровней. Нижний — протокол записей (англ. record protocol) — разбивает поток данных на записи, шифрует и аутентифицирует их. Над ним работают протокол рукопожатия (англ. handshake), согласующий параметры и ключи, протокол предупреждений (англ. alert), сообщающий об ошибках и о штатном закрытии, и собственно прикладные данные. Каждая запись начинается 5-байтовым заголовком ¹:

До окончания обмена ключами записи передаются открыто. После него каждая запись шифруется AEAD-алгоритмом, и снаружи все зашифрованные записи выглядят одинаково: тип application_data (23), версия 0x0303. Настоящий тип содержимого помещается внутрь шифротекста — в последний байт открытого текста, за которым могут следовать нулевые байты дополнения (структура TLSInnerPlaintext). Благодаря этому наблюдатель не отличает сообщения рукопожатия от данных и предупреждений, а дополнение позволяет скрывать длину. Заголовок записи служит присоединёнными данными AEAD и, следовательно, защищён от подмены.

Одноразовое число для AEAD не передаётся: каждая сторона хранит 64-битный счётчик записей, начинающийся с нуля для каждого нового ключа, и вычисляет одноразовое число как «исключающее или» счётчика (дополненного нулями слева до 12 байт) со статическим вектором инициализации iv, выведенным вместе с ключом. Отсюда защита от повтора, удаления и переупорядочения записей: если противник удалит или переставит запись, счётчики сторон разойдутся, тег не сойдётся, и соединение будет разорвано. Защиту от усечения потока обеспечивает предупреждение close_notify, которое сторона обязана отправить перед закрытием соединения: обрыв TCP без него свидетельствует о возможной атаке.

Рукопожатие TLS 1.3 по сообщениям

Полное рукопожатие TLS 1.3 занимает один круговой обход (1-RTT): клиент может отправлять прикладные данные сразу после получения первого ответа сервера. Это достигается тем, что клиент угадывает группу обмена ключами и сразу отправляет своё открытое значение Диффи — Хеллмана. Последовательность сообщений показана на рисунке; фигурными скобками в RFC 8446 помечены сообщения, зашифрованные ключами рукопожатия.

Рассмотрим сообщения по порядку ¹.

1. ClientHello (открыто). Содержит 32 случайных байта random, поле legacy_session_id, список наборов шифров cipher_suites в порядке предпочтения клиента и расширения. Ключевые расширения: supported_versions — список поддерживаемых версий, именно здесь клиент сообщает о TLS 1.3 (поле версии в самом сообщении по соображениям совместимости зафиксировано как 0x0303); supported_groups — группы обмена ключами (x25519, secp256r1, ffdhe2048…); key_share — открытые значения Диффи — Хеллмана для одной или нескольких групп; signature_algorithms — алгоритмы подписи, которые клиент умеет проверять; server_name — имя сервера (SNI); application_layer_protocol_negotiation (ALPN) — прикладные протоколы, например h2 и http/1.1; psk_key_exchange_modes и pre_shared_key — для возобновления сеанса.
2. ServerHello (открыто). Сервер выбирает версию (расширение supported_versions со значением 0x0304), набор шифров и группу и отправляет своё значение key_share. Начиная с этого момента обе стороны могут выполнить обмен Диффи — Хеллмана и вывести ключи рукопожатия. Если ни одна из присланных клиентом групп серверу не подходит, вместо ServerHello отправляется HelloRetryRequest с указанием нужной группы, и рукопожатие удлиняется на один обход.
3. EncryptedExtensions (зашифровано). Остальные расширения, не нужные для выработки ключей: выбранный протокол ALPN, подтверждение SNI. В TLS 1.2 они передавались открыто.
4. CertificateRequest (зашифровано, необязательно) — запрос сертификата клиента при взаимной аутентификации.
5. Certificate (зашифровано). Цепочка сертификатов сервера; к каждому сертификату могут быть приложены расширения, например сшитый ответ OCSP. Шифрование этого сообщения — новшество TLS 1.3: пассивный наблюдатель больше не видит сертификат сервера.
6. CertificateVerify (зашифровано). Подпись закрытым ключом сервера над хешем стенограммы — всех сообщений рукопожатия с ClientHello по Certificate включительно. Подписываемые данные начинаются с 64 байт пробела и строки TLS 1.3, server CertificateVerify, чтобы подпись нельзя было использовать в другом контексте. Именно это сообщение доказывает, что открытое значение key_share прислал владелец сертификата, а не посредник.
7. Finished (зашифровано). HMAC над стенограммой с ключом, выведенным из секрета рукопожатия. Подтверждает, что обе стороны видели одни и те же сообщения и получили одинаковые ключи: любое вмешательство в ClientHello, например удаление сильных шифров из списка, обнаружится здесь.
8. Клиент проверяет цепочку сертификатов и имя, подпись CertificateVerify и Finished сервера, после чего отправляет собственный Finished (при взаимной аутентификации ему предшествуют Certificate и CertificateVerify клиента). Сразу за ним может следовать первый прикладной запрос.

После рукопожатия сервер обычно отправляет одно или несколько сообщений NewSessionTicket — билетов для возобновления сеанса (англ. session resumption). При следующем подключении клиент предъявит билет в расширении pre_shared_key, и стороны выведут ключи из общего ранее установленного секрета (PSK), не передавая сертификат; режим psk_dhe_ke при этом дополнительно выполняет обмен Диффи — Хеллмана и сохраняет прямую секретность.

Реальный захват отличается от схемы одной деталью. Промежуточные устройства (межсетевые экраны, системы обнаружения вторжений) обрывали соединения, непохожие на TLS 1.2, поэтому TLS 1.3 обычно работает в режиме совместимости (англ. middlebox compatibility mode): клиент заполняет legacy_session_id случайным значением, сервер повторяет его, и обе стороны отправляют ничего не значащую запись ChangeCipherSpec ¹. Для старого оборудования такое рукопожатие выглядит как возобновление сеанса TLS 1.2.

Разберём начало реального ServerHello из захвата, выполненного в лабораторной работе (сервер на Python, клиент curl):

16 03 03 00 7a                 заголовок записи: handshake, 0x0303, длина 122
02 00 00 76                    тип 2 = ServerHello, длина 118
03 03                          legacy_version = 0x0303
bc d4 43 77 ... 48 59 db 59    random (32 байта)
20 ce 04 d9 ... 54 37          legacy_session_id: 32 байта, копия из ClientHello
13 02                          cipher_suite = TLS_AES_256_GCM_SHA384
00                             legacy_compression_method = 0
00 2e                          длина расширений = 46
00 2b 00 02 03 04              supported_versions: 0x0304 = TLS 1.3
00 33 00 24 00 1d 00 20 8e ad ...   key_share: группа 0x001d = x25519, ключ 32 байта

Всё, что следует за ServerHello, в захвате видно только как записи типа 23 с непрозрачным содержимым.

Наборы шифров и расписание ключей

В TLS 1.2 набор шифров (англ. cipher suite) задавал всё сразу: способ обмена ключами, алгоритм подписи, шифр и хеш, например TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ¹². Число комбинаций росло мультипликативно и достигло нескольких сотен, многие из них были слабыми. В TLS 1.3 набор шифров определяет только AEAD-алгоритм и хеш-функцию для HKDF; обмен ключами и подпись согласуются независимо расширениями supported_groups и signature_algorithms. Наборов всего пять ¹:

Все ключи соединения выводятся из нескольких исходных секретов по расписанию ключей (англ. key schedule), основанному на HKDF ¹⁸. Расписание показано на рисунке. На первом этапе из предварительно согласованного ключа PSK (при полном рукопожатии — из нулей) вычисляется ранний секрет Early Secret. На втором к нему подмешивается результат обмена (EC)DHE и получается секрет рукопожатия Handshake Secret, из которого выводятся секреты трафика рукопожатия клиента и сервера — ими шифруются сообщения от EncryptedExtensions до Finished. На третьем этапе получается главный секрет Master Secret, из которого выводятся секреты прикладного трафика, секрет для экспорта ключей и секрет для возобновления сеанса.

Каждый секрет трафика привязан к стенограмме: функция Derive-Secret(секрет, метка, сообщения) использует в качестве контекста хеш всех сообщений рукопожатия до соответствующего момента. Из секрета трафика функцией HKDF-Expand-Label с метками key и iv получаются ключ и вектор инициализации AEAD для записей одного направления. Ключи разных направлений и разных этапов независимы: компрометация одного ничего не говорит о других. Секреты прикладного трафика можно обновлять по ходу долгого соединения сообщением KeyUpdate.

Эта конструкция объясняет механизм, используемый в лабораторной работе для расшифровки трафика. Если задать переменную окружения SSLKEYLOGFILE, библиотеки OpenSSL, NSS и другие записывают в указанный файл секреты трафика каждого соединения в формате, предложенном разработчиками NSS:

CLIENT_HANDSHAKE_TRAFFIC_SECRET <client_random> <секрет>
SERVER_HANDSHAKE_TRAFFIC_SECRET <client_random> <секрет>
CLIENT_TRAFFIC_SECRET_0 <client_random> <секрет>
SERVER_TRAFFIC_SECRET_0 <client_random> <секрет>
EXPORTER_SECRET <client_random> <секрет>

Соединение опознаётся по полю random из ClientHello, видимому в захвате. Имея секреты, Wireshark выводит из них ключи и расшифровывает записи. Журнал секретов — отладочное средство: он позволяет расшифровать трафик без закрытого ключа сервера, поэтому в рабочей среде его не включают.

Нулевой обход, SNI и ECH

При возобновлении сеанса клиент может отправить прикладные данные сразу в первом полёте, вместе с ClientHello, зашифровав их ключом, выведенным из PSK, — режим 0-RTT, или ранние данные (англ. early data). Выигрыш — целый круговой обход: для пользователя на мобильной сети это сотни миллисекунд. Цена — две слабости, явно оговорённые в RFC 8446 ¹. Во-первых, ранние данные не обладают прямой секретностью относительно PSK: ключ выводится до обмена Диффи — Хеллмана. Во-вторых, и это главное, ранние данные можно повторить: противник, записавший ClientHello с ранними данными, отправит его серверу ещё раз, и сервер, не имеющий общего состояния между репликами, обработает запрос повторно. Поэтому 0-RTT допустим только для идемпотентных запросов, например GET без побочных эффектов (понятие идемпотентности — тема 16), а сервер должен уметь отказаться от ранних данных; для HTTP предусмотрен код ответа 425 Too Early.

Расширение server_name (SNI, англ. Server Name Indication) ¹³ позволяет клиенту сообщить имя сервера в ClientHello, чтобы сервер, на одном адресе IP которого размещено много сайтов, выбрал нужный сертификат. Без SNI виртуальный хостинг HTTPS был бы невозможен без отдельного адреса на каждый сайт. Но ClientHello передаётся открыто, и SNI раскрывает посещаемый сайт любому наблюдателю; по нему же работают системы фильтрации трафика. В TLS 1.3 зашифрован сертификат сервера, но SNI остаётся открытым.

Решение — шифрование ClientHello (англ. Encrypted Client Hello, ECH), разработанное в IETF. Клиент заранее получает открытый ключ ECH сервера, как правило из записи DNS типа HTTPS, и отправляет внешний ClientHello с нейтральным именем фронтального сервера (например, провайдера CDN), внутри которого зашифрован настоящий ClientHello с истинным SNI. ECH имеет смысл, когда за фронтальным сервером много сайтов, и требует защищённого DNS, иначе имя видно в запросе DNS.

Сравнение с TLS 1.2

TLS 1.2 ¹² по-прежнему широко распространён. Его полное рукопожатие занимает два круговых обхода: ClientHello, затем ServerHello, Certificate, ServerKeyExchange, ServerHelloDone, затем ClientKeyExchange, ChangeCipherSpec, Finished клиента и, наконец, ChangeCipherSpec и Finished сервера.

Многие из удалённых возможностей стали основой известных атак: CBC — POODLE и Lucky Thirteen, RC4 — статистические атаки на шифр, сжатие — CRIME, обмен ключами RSA — атаки Блейхенбахера и их современная версия ROBOT, произвольные группы DHE — Logjam. TLS 1.3 построен по принципу «меньше вариантов — меньше ошибок».

TLS на практике: аутентификация клиента, ошибки и атаки

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

В обычном HTTPS сертификат предъявляет только сервер, а клиент аутентифицируется позднее, уже внутри канала, — паролем, cookie или токеном. При взаимной аутентификации (англ. mutual TLS, mTLS) сервер отправляет CertificateRequest, и клиент в ответ предъявляет собственную цепочку сертификатов и подписывает стенограмму сообщением CertificateVerify ¹. Сервер проверяет цепочку клиента до корня, которому он доверяет, — как правило, до корня собственного, внутреннего УЦ организации, а не публичного. Сертификаты клиентов содержат в Extended Key Usage назначение clientAuth.

mTLS применяется там, где клиенты — программы, а не люди: между микросервисами (сервисные сетки выпускают сертификат каждому сервису автоматически), в API платёжных систем, при подключении устройств интернета вещей, в сетях с моделью «нулевого доверия» (тема 18). Главная трудность — управление жизненным циклом множества клиентских сертификатов.

Типичные ошибки проверки и конфигурации

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

Последняя строка особенно опасна. Проверку, мешающую в тестовой среде, отключают, и этот код попадает в рабочую систему: канал остаётся зашифрованным, но посредник предъявляет любой собственный сертификат. Правильное решение для тестовой среды — собственный УЦ, корень которого явно указан клиенту (curl --cacert), как это делается в лабораторной работе.

К ошибкам конфигурации относятся также поддержка устаревших версий и слабых наборов шифров. Рекомендации IETF по безопасному использованию TLS (RFC 9325, заменивший RFC 7525) требуют: не согласовывать SSL 2.0, SSL 3.0, TLS 1.0 и 1.1; поддерживать TLS 1.2 и предпочитать TLS 1.3; в TLS 1.2 использовать только наборы с ECDHE или DHE и AEAD; не использовать RC4, NULL-шифры, экспортные наборы и шифры со стойкостью менее 128 бит; применять ключи RSA и группы DH не менее 2048 бит ⁶. Проверить сервер можно командой openssl s_client с ограничением версии или специализированными сканерами.

# поддерживает ли сервер устаревший TLS 1.1? Ожидаемый ответ — отказ рукопожатия
openssl s_client -connect www.example.com:443 -tls1_1 </dev/null
# какие версия, набор шифров и группа согласованы по умолчанию
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
  | grep -E 'Protocol|Cipher is|Server Temp Key'

Атаки на понижение версии

Активный посредник может попытаться заставить стороны выбрать самый слабый общий вариант протокола — атака на понижение (англ. downgrade attack). Так работали атаки FREAK и Logjam (2015): посредник оставлял в ClientHello только «экспортные» наборы с 512-битными ключами, сохранившиеся в реализациях с 1990-х годов, и вскрывал слабый ключ за минуты. Другой путь — повторное подключение: браузеры при обрыве рукопожатия повторяли его с более старой версией, и посредник, обрывая соединения, добивался перехода на SSL 3.0, уязвимый к POODLE.

TLS 1.3 защищается от понижения двумя способами ¹. Во-первых, стенограмма всего рукопожатия, включая исходный ClientHello, подписывается сервером в CertificateVerify и подтверждается в Finished, поэтому любое изменение предложений клиента обнаруживается. Во-вторых, сервер, поддерживающий TLS 1.3, но вынужденный согласовать TLS 1.2 или ниже, записывает в последние 8 байт своего random особое значение: байты 44 4F 57 4E 47 52 44 01 (ASCII-строка DOWNGRD и байт 01) при согласовании TLS 1.2 и 44 4F 57 4E 47 52 44 00 при более старой версии. Поле random входит в подписываемые данные даже в старых версиях протокола, поэтому посредник не может его изменить, а клиент с поддержкой TLS 1.3, увидев этот маркер, разрывает соединение.

HSTS: защита от перехода на HTTP

Даже идеально настроенный HTTPS не помогает, если пользователь до него не дошёл. Пользователь набирает bank.example, браузер обращается по HTTP на порт 80 и получает перенаправление на https://bank.example/. Посредник перехватывает этот первый незащищённый запрос, сам соединяется с банком по HTTPS, а пользователю отдаёт страницы по HTTP; ошибок сертификата нет, потому что нет TLS. Эта атака называется SSL stripping.

Защита — механизм HTTP Strict Transport Security (HSTS) ⁵. Сервер, отвечая по HTTPS, добавляет заголовок

Strict-Transport-Security: max-age=31536000; includeSubDomains

Получив его, браузер в течение max-age секунд (здесь — один год) обращается к этому домену, а при includeSubDomains — и ко всем поддоменам, только по HTTPS: запросы на http:// переписываются в https:// до отправки, а ошибки сертификата становятся неустранимыми — пользователь не может нажать «всё равно продолжить». Заголовок, полученный по HTTP, игнорируется. Слабое место HSTS — первый визит до получения заголовка; его закрывает список предварительной загрузки (англ. HSTS preload list), вшитый в код браузеров.

Итоги темы

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

Протокол собран из небольшого набора примитивов. Данные защищает AEAD-алгоритм с одноразовым числом из номера записи. Общий секрет устанавливается эфемерным обменом Диффи — Хеллмана, стойкость которого основана на трудности дискретного логарифмирования, а эфемерность даёт прямую секретность. Подпись сервера над стенограммой связывает обмен с владельцем сертификата, а все ключи выводятся функцией HKDF из общих секретов и хеша стенограммы.

Слабое звено системы — не математика, а доверие к открытым ключам. Сертификат X.509 связывает имя с ключом подписью удостоверяющего центра, клиент проверяет цепочку до корня из своего хранилища, а инфраструктура отзыва, Certificate Transparency, короткие сроки действия и автоматический выпуск по протоколу ACME компенсируют неизбежные ошибки УЦ и владельцев ключей. Большинство практических проблем — неверное имя, просроченный сертификат, неполная цепочка, отключённая проверка, устаревшие версии — являются ошибками конфигурации, а не слабостями протокола.

TLS 1.3 упростил протокол: одно рукопожатие за один обход, обязательная прямая секретность, только AEAD, зашифрованный сертификат, защита от понижения версии. Открытыми остаются метаданные: адреса, размеры и время, а без ECH — имя сервера. TLS защищает отдельные соединения приложений; в следующей теме рассматриваются межсетевые экраны и защита сети как целого, а в теме 19 — туннели и виртуальные частные сети, которые защищают весь трафик между узлами или сетями на сетевом уровне.

Литература

1. Rescorla E. The Transport Layer Security (TLS) Protocol Version 1.3. — RFC 8446, IETF, 2018. https://www.rfc-editor.org/rfc/rfc8446
2. Cooper D., Santesson S., Farrell S., Boeyen S., Housley R., Polk W. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. — RFC 5280, IETF, 2008. https://www.rfc-editor.org/rfc/rfc5280
3. Laurie B., Langley A., Kasper E. Certificate Transparency. — RFC 6962, IETF, 2013. https://www.rfc-editor.org/rfc/rfc6962
4. Barnes R., Hoffman-Andrews J., McCarney D., Kasten J. Automatic Certificate Management Environment (ACME). — RFC 8555, IETF, 2019. https://www.rfc-editor.org/rfc/rfc8555
5. Hodges J., Jackson C., Barth A. HTTP Strict Transport Security (HSTS). — RFC 6797, IETF, 2012. https://www.rfc-editor.org/rfc/rfc6797
6. Sheffer Y., Saint-Andre P., Fossati T. Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). — RFC 9325, IETF, 2022 (заменяет RFC 7525). https://www.rfc-editor.org/rfc/rfc9325
7. Diffie W., Hellman M. E. New Directions in Cryptography. — IEEE Transactions on Information Theory, 1976, Vol. 22, No. 6, С. 644–654, DOI: 10.1109/TIT.1976.1055638.
8. Krawczyk H., Eronen P. HMAC-based Extract-and-Expand Key Derivation Function (HKDF). — RFC 5869, IETF, 2010. https://www.rfc-editor.org/rfc/rfc5869
9. Santesson S., Myers M., Ankney R., Malpani A., Galperin S., Adams C. X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP. — RFC 6960, IETF, 2013. https://www.rfc-editor.org/rfc/rfc6960
10. Langley A., Hamburg M., Turner S. Elliptic Curves for Security. — RFC 7748, IETF, 2016. https://www.rfc-editor.org/rfc/rfc7748
11. Krawczyk H., Bellare M., Canetti R. HMAC: Keyed-Hashing for Message Authentication. — RFC 2104, IETF, 1997. https://www.rfc-editor.org/rfc/rfc2104
12. Dierks T., Rescorla E. The Transport Layer Security (TLS) Protocol Version 1.2. — RFC 5246, IETF, 2008. https://www.rfc-editor.org/rfc/rfc5246
13. Eastlake D. Transport Layer Security (TLS) Extensions: Extension Definitions. — RFC 6066, IETF, 2011. https://www.rfc-editor.org/rfc/rfc6066
14. McGrew D. An Interface and Algorithms for Authenticated Encryption. — RFC 5116, IETF, 2008. https://www.rfc-editor.org/rfc/rfc5116

Дополнительные материалы

Вопросы для самопроверки

1. Чем пассивный противник отличается от активного? Какие из свойств — конфиденциальность, целостность, аутентификация — нарушает каждый из них?
2. Почему шифрование без кода аутентификации не защищает целостность? Приведите пример изменения шифротекста потокового шифра.
3. Что такое AEAD и какие данные в TLS 1.3 являются присоединёнными (аутентифицированными, но не зашифрованными)?
4. Почему повтор одноразового числа при одном ключе в AES-GCM катастрофичен и как TLS исключает такой повтор?
5. Чем HMAC отличается от простого хеша сообщения, к которому приписан ключ? Для чего HMAC используется в TLS 1.3, помимо проверки целостности?
6. Выполните обмен Диффи — Хеллмана при p = 23, g = 5, a = 3, b = 7. Какие числа передаются по сети и какой получается общий секрет?
7. Что такое прямая секретность? Почему обмен ключами RSA в TLS 1.2 её не обеспечивает, а ECDHE — обеспечивает?
8. Какие проверки выполняет клиент для каждого сертификата цепочки и какие — только для сертификата сервера?
9. Почему отзыв сертификатов в публичной PKI работает плохо и какими мерами отрасль компенсирует этот недостаток?
10. Как Certificate Transparency помогает обнаружить поддельный сертификат, если не мешает его выпуску?
11. Перечислите сообщения полного рукопожатия TLS 1.3 и укажите, какие из них передаются открыто.
12. Какую роль играют сообщения CertificateVerify и Finished? Какую атаку предотвращает каждое из них?
13. Почему ранние данные (0-RTT) можно повторить и какие запросы допустимо отправлять в этом режиме?
14. Что раскрывает наблюдателю расширение SNI и как ECH решает эту проблему?
15. Какую атаку предотвращает HSTS и почему для защиты первого визита нужен список предварительной загрузки?

Глоссарий темы

Шпаргалка по инструментам

Подключение и проверка сервера:

openssl s_client -connect host:443 -servername host </dev/null          # рукопожатие, цепочка, параметры
openssl s_client -connect host:443 -showcerts </dev/null                 # все сертификаты цепочки в PEM
openssl s_client -connect host:443 -tls1_2 </dev/null                    # ограничить версию
openssl s_client -connect host:443 -groups X25519 </dev/null             # предложить только одну группу
openssl s_client -connect IP:443 -servername имя -CAfile root.crt -verify_hostname имя </dev/null
openssl s_client -connect host:443 -keylogfile keys.log </dev/null       # журнал секретов из s_client

Сертификаты и ключи:

openssl x509 -in cert.pem -noout -text                                   # полный разбор
openssl x509 -in cert.pem -noout -subject -issuer -dates -ext subjectAltName
openssl x509 -in cert.pem -noout -fingerprint -sha256                    # отпечаток сертификата
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out key.pem
openssl req -new -key key.pem -subj "/CN=www.nsu.example" -out req.csr   # запрос на сертификат
openssl req -in req.csr -noout -text                                     # разбор запроса
openssl x509 -req -in req.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 90 -extfile server.ext -out cert.pem
openssl verify -CAfile root.crt -untrusted int.crt cert.pem              # проверка цепочки

Клиенты и серверы:

curl -v https://host/                                    # ход рукопожатия и проверка сертификата
curl --cacert root.crt --resolve имя:443:IP https://имя/ # свой корень, имя без DNS
curl --cert client.crt --key client.key https://host/    # клиентский сертификат (mTLS)
SSLKEYLOGFILE=keys.log curl https://host/                # журнал секретов для Wireshark
openssl s_server -accept 8443 -cert chain.crt -key key.pem -www   # тестовый TLS-сервер

Wireshark и tshark:

Что почитать и посмотреть

• RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3. Первоисточник: раздел 2 даёт обзор протокола, раздел 4 — формат всех сообщений рукопожатия, раздел 7 — расписание ключей, приложение E — анализ свойств безопасности.
• The Illustrated TLS 1.3 Connection. Побайтовый разбор реального соединения TLS 1.3 с пояснением каждого поля и вычислением всех ключей; полезно читать параллельно с выводом tls13_decrypt.py из лабораторной работы.
• RFC 5280 — Internet X.509 PKI Certificate and CRL Profile. Раздел 4 описывает поля и расширения сертификата, раздел 6 — алгоритм проверки пути сертификации.
• RFC 9325 — Recommendations for Secure Use of TLS and DTLS. Краткий свод требований IETF к версиям, наборам шифров и длинам ключей; основа для аудита конфигурации.
• Mozilla SSL Configuration Generator. Готовые конфигурации TLS для nginx, Apache, HAProxy и других серверов в профилях «современный», «промежуточный», «старый» с пояснением компромиссов.
• Let's Encrypt — How It Works. Наглядное описание протокола ACME и проверок владения доменом; там же документация по цепочкам сертификатов Let's Encrypt.
• Certificate Transparency. Описание устройства журналов CT, мониторов и аудиторов; поиск сертификатов по имени — на crt.sh.
• Блог Cloudflare: A Detailed Look at RFC 8446 (a.k.a. TLS 1.3). Обзор изменений TLS 1.3 по сравнению с 1.2 и мотивации каждого изменения от одной из компаний, первыми внедривших протокол.
• Wireshark Wiki: TLS. Как расшифровывать TLS в Wireshark, форматы журналов секретов, ограничения.
• Ferguson N., Schneier B., Kohno T. Cryptography Engineering. — Wiley, 2010. Учебник о практическом применении криптографических примитивов: почему важны одноразовые числа, как сочетать шифрование и MAC, где ошибаются реализации.

Углубление (по желанию)

Постквантовый обмен ключами

Задачи разложения на множители и дискретного логарифмирования, на которых основаны RSA, DH и ECDH, эффективно решаются алгоритмом Шора на достаточно большом квантовом компьютере. Таких компьютеров пока нет, но трафик, записанный сегодня, может быть расшифрован, когда они появятся (угроза «собери сейчас — расшифруй потом»). Поэтому прежде всего защищают обмен ключами, а не подписи: подпись нужна только в момент рукопожатия, а секрет обмена определяет конфиденциальность записи навсегда. В 2024 году NIST стандартизовал механизм инкапсуляции ключей ML-KEM (бывший Kyber, стандарт FIPS 203), и браузеры и крупные CDN начали применять гибридную группу X25519MLKEM768: клиент отправляет в key_share одновременно значение X25519 и ключ ML-KEM, а общий секрет выводится из обоих, так что соединение остаётся стойким, даже если один из алгоритмов окажется сломан. Платой является размер: ClientHello вырастает более чем на килобайт и перестаёт помещаться в один пакет, что выявило ошибки в ряде промежуточных устройств. Проверить, поддерживает ли сервер гибридную группу, можно в Wireshark по полю key_share в ServerHello или в выводе openssl s_client (в новых версиях OpenSSL — строка с согласованной группой TLS 1.3).

Инспекция TLS в корпоративных сетях

Многие организации расшифровывают трафик сотрудников на межсетевых экранах для поиска вредоносных программ и утечек. Технически это и есть атака «человек посередине»: прокси завершает TLS-соединение клиента, предъявляя сертификат, выпущенный на лету собственным УЦ организации, и открывает отдельное соединение к настоящему серверу. Работает это только потому, что корень корпоративного УЦ установлен на рабочие станции как доверенный. Исследования показали, что такие устройства часто ослабляют защиту: поддерживают устаревшие версии и шифры на стороне сервера, не проверяют сертификаты серверов должным образом, скрывают от пользователя признаки атаки. Кроме того, инспекция несовместима с mTLS и с приложениями, «закрепляющими» ожидаемый ключ сервера (англ. certificate pinning). Лабораторная работа 17 показывает механизм на простом примере: стоит добавить в доверенные посторонний корень «Totally Trusted Root CA», и сертификат rogue.crt будет принят.

Почему Heartbleed был так опасен

Уязвимость Heartbleed (CVE-2014-0160) в OpenSSL была ошибкой не протокола, а реализации: обработчик расширения heartbeat не проверял, что заявленная длина эхо-данных не превышает фактической, и возвращал собеседнику до 64 КиБ памяти процесса. В этой памяти оказывались cookie и пароли пользователей, а иногда — закрытый ключ сервера. Последствия различались в зависимости от обмена ключами: для сайтов, использовавших обмен ключами RSA, украденный ключ позволял расшифровать весь ранее записанный трафик, а для сайтов с ECDHE — только выдавать себя за сервер до отзыва сертификата. Этот случай стал одним из главных доводов за обязательную прямую секретность и за массовый отзыв и перевыпуск сертификатов, который заодно показал слабость механизмов отзыва.

Лабораторная работа 17. TLS на практике

• Раздел курса: тема 17 «Защищённые соединения: криптография и TLS»

Введение

В лабораторной работе 16 запросы и ответы HTTP читались в захвате трафика как обычный текст. В настоящей работе тот же HTTP передаётся внутри TLS, и захват превращается в последовательность непрозрачных записей. Предстоит разобраться, что в этих записях остаётся видимым, кто и как удостоверяет подлинность сервера и при каких условиях зашифрованный трафик всё-таки можно прочитать.

Работа повторяет путь темы 17. Сначала изучаются сертификаты и параметры соединения реальных сайтов. Затем для учебной компании «Северный узел» создаётся собственный удостоверяющий центр (УЦ) с корневым и промежуточным сертификатами, выпускается сертификат веб-сервера с альтернативными именами (SAN) и поднимается HTTPS-сервер в отдельном сетевом пространстве имён. На этом стенде воспроизводятся типичные ошибки проверки — неверное имя, истёкший срок, недоверенный корень, неполная цепочка, — захватывается рукопожатие TLS 1.3 и расшифровывается по журналу секретов SSLKEYLOGFILE. Отдельная часть посвящена обмену ключами Диффи — Хеллмана на малых и на реальных числах.

Части 1–6 составляют базовую часть работы. Часть 7 (взаимная аутентификация mTLS) — продвинутая, выполняется по желанию.

Цель работы

Освоить проверку и настройку защищённых соединений TLS: выпуск сертификатов собственным УЦ, диагностику ошибок проверки сертификата и анализ рукопожатия TLS 1.3 по захвату трафика.

После выполнения работы можно будет:

• получить командой openssl s_client цепочку сертификатов, версию протокола, набор шифров и группу обмена ключами реального сервера и объяснить каждое значение;
• создать корневой и промежуточный УЦ и выпустить сертификат сервера с расширением subjectAltName, прочитать поля сертификата X.509;
• настроить клиента на доверие собственному корню (curl --cacert) и предсказать результат проверки до подключения;
• по сообщению об ошибке определить причину отказа проверки (имя, срок, недоверенный корень, неполная цепочка) и устранить её;
• выделить в захвате сообщения рукопожатия TLS 1.3 и TLS 1.2 и указать, какие из них передаются открыто;
• расшифровать трафик TLS 1.3 по журналу секретов и объяснить, почему для этого не нужен закрытый ключ сервера;
• вычислить обмен Диффи — Хеллмана на малых числах и показать на примере атаку посредника на неаутентифицированный обмен.

Теоретический минимум

Угрозы и свойства канала — тема 17, раздел «Угрозы в сети и свойства защищённого канала»; примитивы и числовой пример Диффи — Хеллмана — раздел «Криптографические примитивы»; сертификаты, цепочки, отзыв и CT — раздел «Инфраструктура открытых ключей»; рукопожатие, записи и расписание ключей — раздел «Протокол TLS 1.3»; ошибки конфигурации, mTLS и HSTS — раздел «TLS на практике».

Учебная топология состоит из двух сетевых пространств имён, соединённых парой veth:

Имени www.nsu.example в DNS нет. Чтобы клиент отправил в SNI и проверил по сертификату именно это имя, а соединение установил с адресом 10.17.0.20, используется ключ curl --resolve www.nsu.example:8443:10.17.0.20; для openssl s_client адрес задаётся в -connect, а имя — в -servername и -verify_hostname.

Основные команды работы:

Фильтры Wireshark: tls — все записи TLS; tls.handshake.type == 1 — ClientHello; tls.handshake.extensions_server_name — поле SNI; tls.record.content_type == 23 — записи прикладных данных; http — расшифрованный HTTP (после подключения журнала секретов).

Перечень оснащения

• ОС Ubuntu 24.04 (физическая или виртуальная машина, WSL2) с правами sudo.
• Пакеты: sudo apt install openssl curl tcpdump tshark wireshark python3 python3-cryptography iproute2. Модуль python3-cryptography нужен только сценарию tls13_decrypt.py.
• Архив окружения lr-env: скрипты up.sh и down.sh (топология), make-pki.sh (полная учебная PKI одной командой), каталог ext/ с расширениями X.509 для каждого типа сертификата, tls_server.py, tls_records.py, tls13_decrypt.py, dh_demo.py, README.md.
• Доступ в Интернет для части 1.

Порядок выполнения работы

Распакуйте архив и перейдите в каталог lr-env; все команды работы выполняются из него. Топология поднимается командой sudo ./up.sh и разбирается командой sudo ./down.sh (её можно запускать повторно). Команды в пространствах имён удобно запускать через функции оболочки:

cl()  { sudo ip netns exec cl  "$@"; }
srv() { sudo ip netns exec srv "$@"; }

Сервер удобно держать в отдельном окне терминала: запуск srv python3 tls_server.py … занимает терминал до нажатия Ctrl+C, а в его выводе видны ошибки рукопожатия со стороны сервера. В журнал по каждой части включаются выводы команд, ответы на вопросы и, где сказано, предсказание, сделанное до эксперимента. Закрытые ключи в журнал не включаются.

Часть 1. Сертификаты и параметры TLS реальных сайтов

Задание

1. Подключитесь к серверу и выведите параметры соединения:

   openssl s_client -connect www.rfc-editor.org:443 -servername www.rfc-editor.org </dev/null
   

   Перенаправление </dev/null закрывает соединение сразу после рукопожатия. Найдите в выводе блок Certificate chain: сколько сертификатов прислал сервер, кто субъект (s:) и издатель (i:) каждого. Найдите строки Protocol, Cipher is, Server Temp Key, Peer signature type, Verify return code.

2. Сохраните сертификат сервера и разберите его:

   openssl s_client -connect www.rfc-editor.org:443 -servername www.rfc-editor.org </dev/null 2>/dev/null \
     | openssl x509 -out rfced.crt
   openssl x509 -in rfced.crt -noout -subject -issuer -dates -ext subjectAltName,keyUsage,extendedKeyUsage
   openssl x509 -in rfced.crt -noout -text | less
   

   Заполните таблицу: серийный номер, алгоритм подписи, алгоритм и длина открытого ключа, срок действия в днях, имена в SAN, наличие CA:FALSE, адреса CRL и OCSP (если есть), число меток SCT.

3. Повторите пункт 1 ещё для двух сайтов по выбору (например, крупного российского сервиса и сайта университета). Сравните корневые УЦ, длину цепочки, тип ключа (RSA или ECDSA), согласованную группу (X25519, P-256 или гибридная постквантовая группа, если её поддерживают сервер и ваша версия OpenSSL).

4. Ограничьте версию протокола и наблюдайте результат. Сначала предскажите, что произойдёт, затем выполните:

   openssl s_client -connect www.rfc-editor.org:443 -tls1_2 </dev/null 2>/dev/null | grep -E 'Protocol|Cipher is'
   openssl s_client -connect www.rfc-editor.org:443 -tls1_1 </dev/null 2>&1 | tail -3
   

   Объясните, чем отличается название набора шифров в TLS 1.2 от TLS 1.3. Обратите внимание: в Ubuntu 24.04 сама библиотека OpenSSL по умолчанию не разрешает TLS 1.1, поэтому отказ может произойти ещё на стороне клиента; определите по сообщению, на чьей стороне.

5. Проверьте, публикует ли сайт заголовок HSTS:

   curl -sI https://www.rfc-editor.org/ | grep -i strict-transport-security
   

   Объясните значения max-age, includeSubDomains, preload.

Что должно получиться

Вывод цепочек трёх сайтов, заполненная таблица полей сертификата, результаты пункта 4 с объяснением, значение заголовка HSTS. Ответ на вопрос: почему сервер не присылает свой корневой сертификат (или присылает его как перекрёстно подписанный)?

Часть 2. Собственный удостоверяющий центр

Задание

Создайте вручную трёхуровневую PKI «Северного узла». Каталог pki создаётся первой командой; ключи — ECDSA на кривой P-256.

1. Корневой УЦ: закрытый ключ и самоподписанный сертификат на 10 лет.

   mkdir -p pki
   openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out pki/root.key
   openssl req -x509 -new -key pki/root.key -sha256 -days 3650 \
     -subj "/C=RU/O=Severny Uzel/CN=Severny Uzel Root CA" \
     -addext "basicConstraints=critical,CA:TRUE" \
     -addext "keyUsage=critical,keyCertSign,cRLSign" \
     -out pki/root.crt
   

2. Промежуточный (выпускающий) УЦ: ключ, запрос на сертификат (англ. Certificate Signing Request, CSR) и сертификат, подписанный корнем. Прочитайте файл ext/intermediate.ext и объясните, что означает pathlen:0.

   openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out pki/int.key
   openssl req -new -key pki/int.key \
     -subj "/C=RU/O=Severny Uzel/CN=Severny Uzel Issuing CA 1" -out pki/int.csr
   openssl x509 -req -in pki/int.csr -CA pki/root.crt -CAkey pki/root.key \
     -CAcreateserial -days 1825 -sha256 -extfile ext/intermediate.ext -out pki/int.crt
   

3. Сертификат сервера www.nsu.example на 90 дней. Прочитайте ext/server.ext: какие имена и адреса перечислены в subjectAltName?

   openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out pki/server.key
   openssl req -new -key pki/server.key -subj "/CN=www.nsu.example" -out pki/server.csr
   openssl x509 -req -in pki/server.csr -CA pki/int.crt -CAkey pki/int.key \
     -CAcreateserial -days 90 -sha256 -extfile ext/server.ext -out pki/server.crt
   cat pki/server.crt pki/int.crt > pki/server-chain.crt
   chmod 600 pki/*.key
   

4. Проверьте цепочку без сети и разберите сертификаты:

   openssl verify -CAfile pki/root.crt -untrusted pki/int.crt pki/server.crt
   openssl verify -CAfile pki/root.crt pki/server.crt
   openssl x509 -in pki/server.crt -noout -text
   

   Почему вторая команда завершается ошибкой? Сверьте Authority Key Identifier сертификата сервера с Subject Key Identifier промежуточного УЦ, а Issuer — с Subject.

5. Убедитесь, что корневой сертификат подписан своим ключом, а сертификат сервера — нет: сравните поля Subject и Issuer у каждого. Определите размер файла server.key и server.crt и объясните, почему файл server.csr не содержит закрытого ключа, хотя подписан им.

Что должно получиться

Список созданных файлов, вывод openssl verify (обе команды), фрагменты openssl x509 -text для трёх сертификатов с выделенными полями Issuer, Subject, Validity, Basic Constraints, Key Usage, Subject Alternative Name, ключевыми идентификаторами. Схема цепочки (от руки или в редакторе) с указанием, каким ключом подписан каждый сертификат.

Часть 3. HTTPS-сервер и проверка сертификата клиентом

Задание

1. Поднимите топологию и запустите сервер в пространстве имён srv (в отдельном окне):

   sudo ./up.sh
   srv python3 tls_server.py --cert pki/server-chain.crt --key pki/server.key
   

   Сервер слушает порт 8443 и на любой запрос GET отвечает параметрами установленного соединения.

2. Предскажите результат каждой из команд, затем выполните их и сравните:

   cl curl -sS https://10.17.0.20:8443/
   cl curl -sS --resolve www.nsu.example:8443:10.17.0.20 https://www.nsu.example:8443/
   cl curl -sS --cacert pki/root.crt --resolve www.nsu.example:8443:10.17.0.20 https://www.nsu.example:8443/
   cl curl -sS --cacert pki/root.crt https://10.17.0.20:8443/
   cl curl -sS -k https://10.17.0.20:8443/
   

   Ожидаемый вывод успешного запроса:

   TLS version : TLSv1.3
   Cipher suite: TLS_AES_256_GCM_SHA384 (256 bit)
   SNI         : www.nsu.example
   Client cert : none
   

   Объясните: почему без --cacert проверка не проходит, хотя сертификат «правильный»; почему подключение по адресу 10.17.0.20 с --cacert проходит (найдите ответ в SAN); почему при подключении по адресу поле SNI равно None; что именно теряется при -k.

3. Выполните запрос с подробным выводом и найдите в нём строки о версии TLS, результате согласования ALPN, субъекте и издателе сертификата и результате проверки:

   cl curl -v --cacert pki/root.crt --resolve www.nsu.example:8443:10.17.0.20 \
     https://www.nsu.example:8443/ 2>&1 | grep -E '^\* '
   

4. Подключитесь к тому же серверу командой openssl s_client с проверкой имени:

   cl openssl s_client -connect 10.17.0.20:8443 -servername www.nsu.example \
     -CAfile pki/root.crt -verify_hostname www.nsu.example </dev/null
   

   Сколько сертификатов прислал сервер? Что изменится, если указать -CAfile pki/int.crt вместо корня? Проверьте и объясните (подсказка: по умолчанию OpenSSL требует, чтобы цепочка заканчивалась самоподписанным доверенным сертификатом; опция -partial_chain снимает это требование).

Что должно получиться

Таблица «команда — предсказание — фактический результат — объяснение» для пункта 2, фрагмент вывода curl -v, ответы на вопросы пункта 4.

Часть 4. Ошибки проверки: сломать и починить

Задание

1. Выполните скрипт, который заново создаёт всю учебную PKI (повторяя шаги части 2) и дополнительно выпускает «неправильные» сертификаты: wrongname.crt (действителен только для old.nsu.example), expired.crt (срок истёк в 2025 году), rogue.crt (сертификат www.nsu.example от постороннего корня Totally Trusted Root CA):

   ./make-pki.sh
   

   Скрипт удаляет каталог pki и создаёт его заново, поэтому все ключи меняются. Прочитайте скрипт и найдите, как выпущен сертификат с датами в прошлом.

2. Для каждого случая из таблицы сначала запишите предсказание (будет ли установлено соединение и какое сообщение выдаст curl), затем запустите сервер с указанным сертификатом и подключитесь клиентом:

   Случай	Запуск сервера (в srv)
   неверное имя	python3 tls_server.py --cert pki/wrongname-chain.crt --key pki/server.key
   истёкший срок	python3 tls_server.py --cert pki/expired-chain.crt --key pki/server.key
   посторонний корень	python3 tls_server.py --cert pki/rogue.crt --key pki/server.key
   неполная цепочка	python3 tls_server.py --cert pki/server.crt --key pki/server.key

   Клиент во всех случаях один и тот же:

   cl curl -sS --cacert pki/root.crt --resolve www.nsu.example:8443:10.17.0.20 https://www.nsu.example:8443/
   

   Для сравнения повторите каждое подключение командой openssl s_client … -verify_hostname www.nsu.example и запишите код ошибки (Verify return code). Пример ожидаемых сообщений:

   curl: (60) SSL: no alternative certificate subject name matches target host name 'www.nsu.example'
   curl: (60) SSL certificate problem: certificate has expired
   curl: (60) SSL certificate problem: unable to get local issuer certificate
   

3. Посмотрите в окне сервера, что он сообщает при неудачном рукопожатии (например, TLSV1_ALERT_UNKNOWN_CA). Объясните: какая сторона обнаружила ошибку, какое предупреждение TLS (alert) она отправила и почему в случае неверного имени сервер может вообще не увидеть ошибки.

4. Обратите внимание, что в случаях «посторонний корень» и «неполная цепочка» curl выдаёт одно и то же сообщение. Как различить эти случаи? Используйте вывод цепочки openssl s_client -showcerts и поле Issuer.

5. Почините каждую ошибку правильным способом (не через -k): для имени — выпустите сертификат с нужным SAN или обратитесь по имени из SAN; для срока — выпустите новый сертификат; для цепочки — передайте серверу файл с полной цепочкой. Для постороннего корня ответьте письменно: когда правильно добавить корень в доверенные, а когда это означает согласие на перехват трафика (вспомните корпоративные прокси с инспекцией TLS).

6. Найдите ошибку. Коллега выпустил сертификат сервера командой из части 2, но забыл ключ -extfile ext/server.ext. Выпустите такой сертификат сами под именем pki/noext.crt, соберите цепочку pki/noext-chain.crt и разберите сертификат командой openssl x509 -text: какая версия формата у него получилась, каких расширений нет? Запустите с ним сервер и проверьте подключение curl к www.nsu.example и к nsu.example (второе имя есть в SAN правильного сертификата). Объясните результат: curl, OpenSSL и модуль ssl Python при отсутствии SAN по историческим причинам сверяют имя с полем CN, тогда как браузеры такой сертификат отвергают. Какие ещё проблемы создаёт сертификат без расширений basicConstraints, keyUsage и extendedKeyUsage?

Что должно получиться

Таблица «случай — предсказание — сообщение curl — код openssl — сообщение сервера — способ исправления», ответы на вопросы пунктов 3–6.

Часть 5. Захват рукопожатия и расшифровка TLS 1.3

Задание

1. Запустите сервер с полной цепочкой. В другом окне начните захват на интерфейсе клиента, в третьем выполните запрос, сохранив секреты сеанса в журнал:

   # окно 1
   srv python3 tls_server.py --cert pki/server-chain.crt --key pki/server.key
   # окно 2
   cl tcpdump -i cl0 -U -w /tmp/tls13.pcap tcp port 8443
   # окно 3
   cl env SSLKEYLOGFILE=/tmp/keys.log curl -sS --cacert pki/root.crt \
     --resolve www.nsu.example:8443:10.17.0.20 https://www.nsu.example:8443/
   

   Остановите tcpdump (Ctrl+C) и сделайте файлы доступными для чтения: sudo chown $USER /tmp/tls13.pcap /tmp/keys.log.

2. Без журнала секретов выведите записи TLS:

   python3 tls_records.py /tmp/tls13.pcap 8443
   

   Начало вывода должно выглядеть примерно так:

   10.17.0.10:54688 -> 10.17.0.20:8443 (клиент -> сервер), 727 байт TLS
     запись  1: Handshake        версия TLS 1.0, длина   512  ClientHello
                шифров предложено: 31; SNI=www.nsu.example; versions=TLS 1.3,TLS 1.2; key_share=x25519(32 байт); ALPN=h2,http/1.1
     запись  2: ChangeCipherSpec версия TLS 1.2, длина     1
     запись  3: ApplicationData  версия TLS 1.2, длина    69
   ...
   

   Ответьте по выводу: какие сведения о соединении доступны пассивному наблюдателю (имя сервера, версия, группа, набор шифров, сертификат, объём данных)? Зачем в TLS 1.3 записи ChangeCipherSpec? Почему в заголовке записи стоит версия TLS 1.2 или 1.0? Тот же анализ выполните в Wireshark (фильтр tls), если он установлен.

3. Изучите журнал секретов /tmp/keys.log: какие метки в нём есть, по какому полю сопоставляется соединение? Найдите это поле (random в ClientHello) в захвате.

4. Расшифруйте трафик учебным сценарием:

   python3 tls13_decrypt.py /tmp/tls13.pcap /tmp/keys.log 8443
   

   Найдите в выводе сообщения EncryptedExtensions, Certificate, CertificateVerify, Finished, NewSessionTicket, HTTP-запрос и ответ, предупреждение close_notify. Сопоставьте с рисунком рукопожатия в теории. Прочитайте функцию hkdf_expand_label в сценарии и объясните, как из секрета трафика получаются ключ и вектор инициализации и как вычисляется одноразовое число для каждой записи.

5. Расшифруйте тот же захват в Wireshark: «Правка → Параметры → Protocols → TLS → (Pre)-Master-Secret log filename» — укажите /tmp/keys.log; затем примените фильтр http. Либо, если установлен tshark:

   tshark -r /tmp/tls13.pcap -o tls.keylog_file:/tmp/keys.log -Y http
   

6. Повторите захват для TLS 1.2: перезапустите сервер с ключом --max-tls 1.2 и выполните пункты 1–2. Какие сообщения рукопожатия теперь видны открыто? Найдите сертификат сервера в захвате. Что записано в журнал секретов для TLS 1.2 (метка CLIENT_RANDOM)? Почему tls13_decrypt.py отказывается расшифровывать этот захват, а Wireshark справляется?

Что должно получиться

Вывод tls_records.py для TLS 1.3 и 1.2 с пометками «видно открыто» и «зашифровано», фрагмент журнала секретов (секреты можно сократить), фрагмент расшифровки с HTTP-запросом и ответом, снимок экрана Wireshark (если доступен), ответы на вопросы. Письменный вывод: кому и при каких условиях доступны данные из журнала секретов и почему его нельзя включать на рабочих системах.

Часть 6. Обмен ключами Диффи — Хеллмана

Задание

1. Вычислите вручную (на бумаге) обмен при p = 23, g = 5, a = 6, b = 15: значения A, B и общий секрет s. Проверьте результат:

   python3 dh_demo.py 6 15
   

2. Выберите собственные секреты a и b от 2 до 21, вычислите s вручную и сверьте с выводом сценария. По таблице степеней (часть 2 вывода) объясните, почему g = 5 подходит в качестве генератора, а g = 2 при p = 23 — нет: проверьте, сколько различных значений принимают степени числа 2 по модулю 23 (вычислите в интерпретаторе python3: sorted({pow(2, x, 23) for x in range(1, 23)})).

3. Изучите в выводе сценария действия перехватчицы Евы (перебор) и посредника Мэллори (подмена A и B). Ответьте: почему Ева в реальном TLS не может повторить свой перебор; почему атака Мэллори не удаётся в TLS 1.3 — какое сообщение рукопожатия её обнаруживает и почему?

4. Оцените время обмена в группе ffdhe2048 по выводу части 5 сценария и сравните его с временем ECDH X25519, измеренным командой:

   openssl speed ecdhx25519 ffdh2048 2>/dev/null | tail -4
   

   Если ваша версия OpenSSL не знает алгоритм ffdh2048, сравните с openssl speed rsa2048.

Что должно получиться

Ручной расчёт для двух наборов секретов, вывод сценария, ответы на вопросы пунктов 2–3, таблица скоростей пункта 4.

Часть 7 (продвинутая). Взаимная аутентификация mTLS

Задание

1. Прочитайте ext/client.ext и найдите в make-pki.sh выпуск сертификата alice.crt. Чем он отличается от сертификата сервера? Почему клиент должен предъявить цепочку alice-chain.crt, а не только свой сертификат?

2. Запустите сервер, требующий сертификат клиента:

   srv python3 tls_server.py --cert pki/server-chain.crt --key pki/server.key --client-ca pki/root.crt
   

   Предскажите и проверьте результат подключения без сертификата и с ним:

   cl curl -sS --cacert pki/root.crt --resolve www.nsu.example:8443:10.17.0.20 https://www.nsu.example:8443/
   cl curl -sS --cacert pki/root.crt --cert pki/alice-chain.crt --key pki/alice.key \
     --resolve www.nsu.example:8443:10.17.0.20 https://www.nsu.example:8443/
   

   В первом случае curl сообщает об ошибке tlsv13 alert certificate required уже при чтении ответа, а не при рукопожатии. Объясните это по схеме рукопожатия TLS 1.3: в какой момент клиент считает рукопожатие завершённым и когда сервер проверяет сертификат клиента?

3. Попробуйте предъявить серверу в качестве клиентского сертификат сервера (--cert pki/server-chain.crt --key pki/server.key). Предскажите результат с учётом расширения extendedKeyUsage и проверьте его.

4. Выпустите сертификат второго сотрудника bob своим промежуточным УЦ (по образцу шага 4 скрипта make-pki.sh) и убедитесь, что сервер его принимает. Затем выпустите сертификат mallory от постороннего корня (pki/rogue-root.crt) и убедитесь, что сервер его отвергает. Как сервер сообщает об отказе?

5. Захватите рукопожатие mTLS с журналом секретов и найдите в расшифровке tls13_decrypt.py сообщения CertificateRequest сервера и Certificate, CertificateVerify клиента.

Что должно получиться

Выводы curl для всех вариантов, сообщения сервера, фрагмент расшифровки с сообщениями mTLS, ответы на вопросы.

После завершения работы разберите топологию командой sudo ./down.sh и удалите каталог pki с закрытыми ключами.

Журнал работы

Ведите для себя журнал: для каждой части записывайте предсказание, сделанное до эксперимента, команду, фактический вывод и объяснение расхождений. Таблицы, графики и файлы захватов, перечисленные в разделах «Что должно получиться», удобно хранить там же. В конце полезно сформулировать несколько предложений собственных выводов по работе.

Контрольные вопросы

1. Почему шифрование без аутентификации сервера не защищает от атаки «человек посередине»? Приведите пример из части 6.
2. Какие поля сертификата проверяет клиент при установлении соединения и какое из них отвечает за привязку к имени сайта?
3. Зачем нужен промежуточный УЦ, если можно подписывать сертификаты серверов прямо корневым ключом?
4. Почему curl выдаёт одинаковое сообщение для постороннего корня и для неполной цепочки, и как отличить эти ситуации?
5. Какие сведения о соединении TLS 1.3 доступны пассивному наблюдателю, а какие — нет? Что изменилось по сравнению с TLS 1.2?
6. Почему для расшифровки захвата TLS 1.3 достаточно журнала секретов и недостаточно закрытого ключа сервера? Как это связано с прямой секретностью?
7. Как вычисляется одноразовое число AEAD для записи TLS 1.3 и почему противник не может удалить или переставить записи незаметно?
8. Сервер в части 5 при ограничении --max-tls 1.2 не записывает в random маркер DOWNGRD (проверьте по захвату последние 8 байт поля random в ServerHello). Почему? В какой ситуации этот маркер появился бы и что сделал бы клиент?
9. Чем опасен режим 0-RTT и для каких HTTP-запросов его можно использовать?
10. Почему браузеры отвергают сертификат без расширения subjectAltName, даже если CN совпадает с именем сервера, хотя curl, OpenSSL и Python в части 4 его приняли? Почему на проверку имени по CN нельзя полагаться?
11. Чем mTLS отличается от аутентификации клиента паролем внутри TLS-соединения? Назовите сценарии, где mTLS предпочтительнее.
12. Как HSTS защищает от атаки SSL stripping и какое уязвимое место у него остаётся?