DTLS (Datagram Transport Layer Security)

TLS предполагает, что байты приходят по порядку и без потерь, — это свойство TCP. Датчик на CoAP шлёт датаграммы UDP, где пакет может потеряться или обогнать соседа. DTLS переносит TLS на такой транспорт, добавив ровно то, чего ему не хватает.

Обновлено 4 ноября 2026 г.Редакция GAW

Содержание

Чего не хватает TLS на UDP
Cookie и повтор
DTLS и CoAP
В прошивке

DTLS (Datagram Transport Layer Security) — вариант TLS для транспорта без гарантии доставки, прежде всего UDP. Текущая версия 1.3 описана в RFC 9147 как набор отличий от TLS 1.3; версия 1.2 (RFC 6347) остаётся в ходу, версии 1.1 не существует, а DTLS 1.0 использовать не рекомендуется (RFC 9147, разд. 1). Замысел — «TLS поверх датаграмм»: шифры, ключи и сертификаты те же, а добавлено лишь то, без чего TLS на UDP не работает (разд. 3). При этом потери и перестановки датаграмм с данными приложения DTLS не исправляет — он защищает каждую датаграмму отдельно и оставляет надёжность протоколу выше, например повтору сообщений CON в CoAP.

Чего не хватает TLS на UDP

RFC 9147 (разд. 3) называет четыре причины и четыре ответа на них:

Проблема в TLS	Решение в DTLS
номер записи неявный — потеря пакета ломает расшифровку всех следующих	явный sequence_number и эпоха в каждой записи (разд. 4.2)
рукопожатие пошаговое, порядок сообщений обязателен	номера сообщений рукопожатия, очередь для пришедших раньше времени (разд. 3.2)
сообщение рукопожатия может быть до 2^24 − 1 байт, датаграмма — часто меньше 1500	фрагментация со смещением и длиной, запись целиком в одной датаграмме (разд. 3.3, 4.3)
UDP позволяет подделать адрес отправителя и использовать сервер как усилитель	cookie без состояния в HelloRetryRequest (разд. 5.1)

Эпоха начинается с нуля и растёт при каждой смене ключей; номера записей в DTLS 1.3 к тому же шифруются (разд. 12). Защита от повтора датаграмм — скользящее окно-битовая карта, как в IPsec, и она необязательна (разд. 3.4). Размер записи стоит подгонять под MTU пути, чтобы не вызывать фрагментацию IP (разд. 4.3, см. обнаружение MTU пути).

Сервер, получив ClientHello, вправе ответить HelloRetryRequest с cookie и ничего у себя не запоминать; клиент обязан прислать ClientHello заново уже с cookie, доказав, что принимает пакеты по заявленному адресу (разд. 5.1). В DTLS 1.2 для этого служило отдельное сообщение HelloVerifyRequest, а не расширение (там же). От атак с настоящих адресов cookie не спасает.

Потерю пакетов рукопожатия закрывает таймер повтора: истёк — сторона отправляет своё сообщение заново (разд. 3.1); сервер не повторяет только HelloRetryRequest, чтобы не хранить состояние. Начальное значение — 1000 мс, после каждого повтора оно удваивается до не менее 60 с (разд. 5.8.2); DTLS 1.2 по тому же таймеру повторял всё неподтверждённое сразу. Если RTT известен, берут 1,5 × RTT; для DTLS-SRTP стандарт рекомендует 400 мс, а профили для IoT вправе задавать большие таймауты.

DTLS и CoAP

CoAP защищается DTLS так же, как HTTP — TLS: схема coaps://, порт UDP 5684 по умолчанию (RFC 7252, разд. 6.2). Четыре режима безопасности — NoSec, PreSharedKey, RawPublicKey и Certificate (разд. 9). В режиме PSK обязателен набор TLS_PSK_WITH_AES_128_CCM_8 — AES-128 в режиме CCM с 8-байтовой имитовставкой (разд. 9.1.3.1); в режиме Certificate устройство несёт сертификат X.509. Клиент CoAP выступает клиентом DTLS, все сообщения CoAP идут как application data; повтор CON получает новый номер записи DTLS при том же Message ID (разд. 9.1.1). После рукопожатия накладные расходы — около 13 байт на датаграмму без учёта nonce и имитовставки (разд. 9.1); с ними для набора CCM_8 выходит около 29 байт (наш расчёт). Само рукопожатие дороже, поэтому соединение держат открытым, а не поднимают на каждый запрос. К групповой рассылке CoAP DTLS неприменим.

В прошивке

В Zephyr DTLS — это сокет SOCK_DGRAM с протоколом IPPROTO_DTLS_1_x при включённой опции CONFIG_NET_SOCKETS_ENABLE_DTLS; ключи и сертификаты регистрируют через tls_credential_add() и указывают тегом sec_tag_t в опциях сокета, криптографию обеспечивает Mbed TLS. Решение «TLS по TCP или DTLS по UDP» принимают вместе с выбором прикладного протокола: MQTT и HTTP живут на TCP и берут TLS, CoAP и другие датаграммные протоколы — DTLS. Что из этого писать самому, а что оставить стеку, — в статье о реализации протоколов.

Частые вопросы

Чем DTLS отличается от TLS?

Криптография та же, различия — в приспособлении к датаграммам (RFC 9147, разд. 3). В записи DTLS есть явный номер и эпоха, потому что потерянный пакет нельзя восстановить по порядку байтов, как в TCP. Сообщения рукопожатия нумеруются, режутся на фрагменты с длиной и смещением и повторяются по таймеру. Добавлена проверка адреса через cookie. Но потерянные датаграммы с данными приложения DTLS не повторяет — это остаётся протоколу сверху, например CoAP.

Зачем серверу DTLS cookie и HelloRetryRequest?

Против двух атак по UDP (разд. 5.1): злоумышленник заваливает сервер ClientHello, заставляя тратить память и криптографию, либо подставляет чужой адрес источника, и сервер отвечает жертве большим пакетом. Получив ClientHello, сервер может без сохранения состояния ответить HelloRetryRequest с cookie; клиент обязан повторить ClientHello с этим cookie, то есть доказать, что он действительно принимает пакеты по своему адресу. В DTLS 1.2 ту же роль играло сообщение HelloVerifyRequest.

Сколько DTLS стоит для CoAP на микроконтроллере?

По RFC 7252 (разд. 9.1) после рукопожатия DTLS добавляет около 13 байт на датаграмму плюс nonce и имитовставка — по 8 байт у обязательного набора TLS_PSK_WITH_AES_128_CCM_8, итого около 29 байт (наш расчёт). Дороже само рукопожатие, поэтому стандарт советует держать DTLS-соединение открытым как можно дольше, а не поднимать его на каждый запрос. Адрес защищённого ресурса — coaps://, порт UDP 5684.

Источники

E. Rescorla, H. Tschofenig, N. Modadugu. The Datagram Transport Layer Security (DTLS) Protocol Version 1.3. RFC 9147, April 2022 — разд. 1: TLS требует надёжный транспорт, обычно TCP; DTLS сделан максимально похожим на TLS; DTLS 1.0 — дельта от TLS 1.1, 1.2 — от TLS 1.2, версии 1.1 нет, 1.3 — дельта от TLS 1.3 и заменяет RFC 6347, DTLS 1.0 использовать не рекомендуется; разд. 3: «TLS поверх датаграмм», потери и переупорядочивание данных приложения DTLS не компенсирует; четыре причины, по которым TLS нельзя пустить по датаграммам: неявные номера записей — DTLS делает их явными, пошаговое рукопожатие — DTLS нумерует сообщения, большие сообщения рукопожатия — DTLS добавляет фрагментацию, DoS — проверка обратной маршрутизации через HelloRetryRequest; разд. 3.1: простой таймер повтора, HelloRetryRequest сервер не повторяет, чтобы не хранить состояние; разд. 3.3: сообщения рукопожатия до 2^24 − 1 байт при датаграммах часто меньше 1500 байт, поля смещения и длины фрагмента; разд. 3.4: защита от повторов — окно-битовая карта как в IPsec, необязательна; разд. 4.2: явный sequence_number, эпоха начинается с 0 и растёт при смене ключей; разд. 4.3: запись целиком в одной датаграмме, несколько записей в датаграмме допустимы, через границу датаграммы записи не переходят; разд. 5.1: две угрозы — расход ресурсов сервера и усиление с подделанным адресом; cookie без состояния в HelloRetryRequest, клиент повторяет ClientHello с cookie в расширении, в DTLS 1.2 для этого было отдельное сообщение HelloVerifyRequest; от DoS с настоящих адресов не защищает; разд. 5.8.2: начальный таймер 1000 мс с удвоением до не менее 60 с, при известном RTT — 1,5 × RTT, для DTLS-SRTP рекомендованы 400 мс, профили IoT могут задавать большие значения; разд. 9: смена Connection ID по RFC 9146; разд. 12: отличия от 1.2 — только AEAD, HelloRetryRequest вместо HelloVerifyRequest, CID, шифрование номеров записей
Z. Shelby, K. Hartke, C. Bormann. The Constrained Application Protocol (CoAP). RFC 7252, June 2014 — разд. 6.2: схема coaps — порт UDP 5684 по умолчанию, датаграммы обязательно защищены DTLS; разд. 9: режимы NoSec, PreSharedKey, RawPublicKey, Certificate; разд. 9.1: CoAP защищается DTLS по RFC 6347 так же, как HTTP — TLS; после рукопожатия DTLS добавляет около 13 байт на датаграмму без учёта nonce и имитовставки (по 8 байт у TLS_PSK_WITH_AES_128_CCM_8), к групповой рассылке неприменим; разд. 9.1.1: клиент CoAP — клиент DTLS, все сообщения CoAP идут как application data, повтор CON получает новый sequence_number при том же Message ID и не пересекает эпохи, соединение держат открытым как можно дольше; разд. 9.1.3.1: в режиме PSK обязателен набор TLS_PSK_WITH_AES_128_CCM_8
Zephyr Project. Zephyr Project Documentation, latest: Networking APIs — BSD Sockets — сокеты SOCK_DGRAM с протоколом IPPROTO_DTLS_1_x при CONFIG_NET_SOCKETS_ENABLE_DTLS, SOCK_STREAM с IPPROTO_TLS_1_x при CONFIG_NET_SOCKETS_SOCKOPT_TLS; защищённые сокеты реализованы на Mbed TLS; сертификаты и ключи регистрируются через tls_credential_add() и далее указываются тегом sec_tag_t в опциях сокета

Страница помогла?

Нашли ошибку? ·