Протокол записи TLS¶
Протокол записи TLS — это один из компонентов набора протоколов Transport Layer Security (TLS), отвечающий за фрагментацию, сжатие, аутентификацию и шифрование данных, передаваемых между клиентом и сервером в защищённом соединении. Протокол записи является нижним уровнем стека TLS, который обеспечивает транспортную службу для вышележащих протоколов, таких как Handshake, Alert и Change Cipher Spec.
¶История и развитие
Протокол записи был впервые определён в спецификации SSL 3.0, опубликованной компанией Netscape в 1996 году. Впоследствии он был стандартизирован в RFC 2246 (TLS 1.0, 1999 год), RFC 4346 (TLS 1.1, 2006 год), RFC 5246 (TLS 1.2, 2008 год) и RFC 8446 (TLS 1.3, 2018 год). Наиболее существенные изменения коснулись механизмов шифрования и аутентификации: в TLS 1.0 использовался MAC-then-encrypt, в TLS 1.2 — encrypt-then-MAC (как опциональное расширение), а в TLS 1.3 — AEAD (Authenticated Encryption with Associated Data), что устранило уязвимости, связанные с атаками типа padding oracle.
¶Структура записи
Каждая запись протокола TLS состоит из заголовка и тела. Заголовок имеет фиксированную длину 5 байт и включает следующие поля:
- Content Type (1 байт) — идентификатор типа содержимого: 20 (Change Cipher Spec), 21 (Alert), 22 (Handshake), 23 (Application Data). В TLS 1.3 также используются типы 24 (Heartbeat) и 25 (Encrypted Extensions).
- Protocol Version (2 байта) — версия протокола, например, 0x0303 для TLS 1.2 или 0x0304 для TLS 1.3. В зашифрованных записях TLS 1.3 это поле обычно замаскировано значением 0x0303.
- Length (2 байта) — длина тела записи в байтах (от 0 до 2^14=16384). Максимальный размер одной записи — 2^14+2048 байт (с учётом сжатия и накладных расходов на шифрование).
Тело записи содержит собственно данные, которые перед отправкой проходят следующие этапы обработки:
- Фрагментация — данные разбиваются на блоки размером не более 2^14 байт.
- Сжатие (опционально, в TLS 1.0–1.2) — применяется алгоритм сжатия, согласованный на этапе рукопожатия. В TLS 1.3 сжатие не используется из соображений безопасности.
- Добавление MAC (Message Authentication Code) — в TLS 1.0–1.2 перед шифрованием вычисляется код аутентификации сообщения на основе общего ключа. В TLS 1.3 эта функция возложена на AEAD-шифр.
- Шифрование — данные зашифровываются с использованием согласованного алгоритма (например, AES-GCM, ChaCha20-Poly1305).
- Добавление заголовка — формируется итоговая запись.
¶Процесс шифрования и аутентификации
¶TLS 1.0–1.2 (режим MAC-then-encrypt)
В этих версиях сначала к открытому тексту добавляется MAC, затем вся конструкция шифруется блочным шифром в режиме CBC. Этот подход подвержен атакам типа Lucky13, POODLE и BEAST. В TLS 1.2 в качестве опции было введено расширение encrypt-then-MAC, где шифрование выполняется до добавления MAC, что повышает устойчивость к атакам.
¶TLS 1.3 (режим AEAD)
В TLS 1.3 все записи, начиная с сообщения ServerHello, шифруются с использованием схемы AEAD. Это означает, что шифрование и аутентификация выполняются одновременно одним алгоритмом (например, AES-128-GCM или ChaCha20-Poly1305). Запись включает:
- nonce — уникальное значение, вычисляемое на основе порядкового номера записи и части ключевого материала.
- зашифрованный текст — собственно данные.
- тег аутентичности — 16-байтовый код, проверяющий целостность и подлинность записи.
¶Типы записей
¶Application Data
Самый распространённый тип — содержит полезную нагрузку прикладного протокола (например, HTTP/2, WebSocket). После установления защищённого соединения все данные приложения передаются в записях этого типа.
¶Handshake
Используется для обмена сообщениями протокола рукопожатия (ClientHello, ServerHello, Certificate, Finished и т.д.). В TLS 1.3 сообщения Handshake шифруются после получения ServerHello, что защищает метаданные соединения.
¶Alert
Служит для передачи сигналов об ошибках или предупреждений (например, certificate_expired, bad_record_mac). Каждое сообщение Alert состоит из двух байтов: уровня (warning/fatal) и кода ошибки.
¶Change Cipher Spec
В TLS 1.0–1.2 это сообщение указывает, что последующие записи будут шифроваться новым набором параметров. В TLS 1.3 данный тип сохраняется только для обратной совместимости и фактически не используется.
¶Обработка записей на стороне получателя
Получатель выполняет обратные операции в следующем порядке:
- Чтение заголовка — извлекаются Content Type, версия и длина.
- Проверка длины — если длина превышает 2^14+2048 байт, соединение разрывается.
- Расшифровка — применяется алгоритм AEAD (или CBC+MAC в старых версиях). Если проверка MAC/тега не проходит, запись отбрасывается и генерируется Alert с кодом bad_record_mac.
- Дефрагментация (опционально) — если данные были фрагментированы, они собираются в исходный поток.
- Демультиплексирование — по Content Type данные передаются соответствующему протоколу верхнего уровня.
¶Безопасность
Протокол записи TLS является критическим компонентом для обеспечения конфиденциальности и целостности данных. Основные угрозы включают:
- Атаки на padding — в режиме CBC злоумышленник может использовать уязвимости в обработке дополнения для восстановления открытого текста (атаки Lucky13, POODLE). В TLS 1.3 эти атаки исключены за счёт использования AEAD.
- Атаки на последовательность — повторная передача или изменение порядка записей обнаруживается благодаря порядковым номерам, включённым в nonce или MAC.
- Атаки на сжатие — например, CRIME, где сжатие данных перед шифрованием позволяет угадывать секретные значения. В TLS 1.3 сжатие полностью отключено.
¶Применение
Протокол записи TLS используется в любых приложениях, где требуется защищённая передача данных по сети: веб-браузеры (HTTPS), электронная почта (SMTPS, IMAPS), VPN (OpenVPN, WireGuard), мессенджеры (Signal, Telegram), удалённый доступ (SSH), финансовые транзакции (PCI DSS) и многие другие. В России, согласно Федеральному закону № 152-ФЗ «О персональных данных», использование TLS обязательно при передаче персональных данных по открытым каналам связи.
¶Интересные факты
- В TLS 1.3 для маскировки версии протокола в зашифрованных записях используется значение 0x0303 (TLS 1.2), что затрудняет определение версии TLS по трафику.
- Максимальный размер записи (2^14 байт) выбран из соображений задержки: большие записи увеличивают время буферизации и могут вызывать проблемы с интерактивностью приложений.
- Протокол записи TLS может работать поверх любого надёжного транспортного протокола (TCP, SCTP, DCCP), однако на практике чаще всего используется TCP.
¶Критика
Основные претензии к протоколу записи TLS связаны с его сложностью и избыточностью в старых версиях. В TLS 1.0–1.2 наличие нескольких этапов обработки (фрагментация, сжатие, MAC, шифрование) приводило к увеличению задержек и уязвимостям. Кроме того, поддержка обратной совместимости с SSL 3.0 и TLS 1.0 создаёт поверхность для атак понижения версии (downgrade attacks). В TLS 1.3 эти проблемы решены за счёт упрощения стека и обязательного использования AEAD.
¶Источники
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
- RFC 5246 — The Transport Layer Security (TLS) Protocol Version 1.2
- RFC 4346 — The Transport Layer Security (TLS) Protocol Version 1.1
- RFC 2246 — The TLS Protocol Version 1.0
- E. Rescorla, «SSL and TLS: Designing and Building Secure Systems», Addison-Wesley, 2001
- IETF TLS Working Group — https://datatracker.ietf.org/wg/tls/about/