В настоящее время очень трудно найти хотя бы общую информацию о протоколе DTLS (а ему уже 5 лет) – даже гугл при вводе dtls предлагает искать tls.
Общие сведения (много RFC):
Протокол DTLS описан в RFC 4347.
Для DTLS отсутствует чётко зафиксированное значение порта сервера – в реализации OpenSSL, начиная с версии 0.9.8b используется порт 4433. Также, DTLS поддерживается и в других, отличных от OpenSSL реализациях протокола SSL/TLS – например, в CyaSSL.
DTLS – сетевой протокол, предназначенный для безопасной передачи данных с использованием UDP протокола. Возник в связи с необходимостью обеспечения становящихся всё более популярными медиа-протоколов, протоколов IP-телефонии и т.п.
Протокол построен (как следует из названия) по аналогии с протоколом TLS (1.1). Для решения проблем потери пакетов использует механизм ретрансляции пакетов с использованием таймера.
Для решения проблемы ограничения длины UDP пакетов активно используется фрагментация данных. В реализации протокола предусмотрена (опциональная) возможность обнаружения повторной отсылки пакетов (replay) – фильтрация пакетов происходит путём анализа временных фреймов для поступающих пакетов. Также отбрасываются пакеты, идентичные уже поступавшим. Общей защитой от replay-атак является применение номера последовательности (sequence number) и проверки кода “идентичности” сообщения (MAC – message authentication code).
Формат DTLS записи:
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // отсутствует в TLS
uint48 sequence_number; // отсутствует в TLS
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
Описание каждого поля можно найти в разделе 4.1 RFC4347.
Установление соединения происходит с использованием рукопожатия (handshake) по алгоритму, аналогичному используемому в TLS. Однако, существуют и отличия:
1) Для противодействия атакам класса отказ в обслуживании используется механизм обмена сообщениями о состоянии сеанса (stateless cookie);
2) Внесены изменения в механизм реализации рукопожатия для предоставления возможности обработки ситуации потери сообщений, изменения порядка рукопожатия и фрагментации сообщений.
3) Как было сказано ранее – также используется механизм таймеров повторной отсылки сообщений для обработки ситуации потери пакетов.
Наиболее распространёнными атаками на протокол датаграмм являются:
1) отсылка множественных сообщений, содержащих запросы на инициализацию процесса рукопожатия (нагрузка возникает за счёт ресурсоёмкости криптографических операций на последних стадиях рукопожатия – согласование алгоритмов шифрования, обмен ключами и т.п.). К этой категории относятся, например, популярные уязвимости в OpenSSL, связанные с возможностью инициализации клиентом переустановления соединения и повторного согласования вышеуказанных операций (Session Renegotiation Attack на протокол SSL/TLS, например, CVE-2009-3555, CVE-2011-1473);
2) рассылка множественных запросов с подмененным (указывается адрес атакуемого сервера) адресом источника сообщения на установление соединения. В ответ серверы, на которые были отосланы запросы, будут отвечать на атакуемый сервер ресурсоёмкими (как для самого сервера, так и для атакемого сервера) сообщениями Server Hello/Certificate Message. Данная атака представляется как сложнее реализуемая в силу малой популярности DTLS протокола.
Для противодействия DoS атакам в DTLS используется вышеуказанный (и хорошо описанный в RFC4347) механизм stateless cookie, также используемый, например, в протоколе IKE.
Так, при отсылке клиентом ClientHello запроса сервер может (но не обязан!) ответить HelloVerifyRequest сообщением. Последнее сообщение может содержать поле stateless cookie, в случае наличия которого клиент будет обязан переслать ClientHello запрос с добавленным полем cookie.
Данный алгоритм обмена cookies обеспечивает защиту от атак с использованем запросов с подменой адреса источника (описанный выше тип 2 DoS-атаки). Структуру записей в запросах ClientHello и HelloVerifyRequest можно найти в RFC.
Для обхода данного механизма предотвращения атак злоумышленник может осуществить сбор cookies с различных адресов и, затем использовать их в процессе проведения атаки.
Для предотвращения подобных экспромтов на сервере должно быть задано небольшое время истечения действия cookies. Это сделает процесс обмена более ресурсоёмким как для сервера, так и для клиента, но и более безопасным.
Хотелось бы, конечно, описать еще множество интересных вещей, таких как описание механизмов формирования cookies, MAC-сообщений, фрагментации сообщений, запросов на изменение используемых алгоритмов шифрования, структуры различных сообщений, но, полагаю, в случае острой нехватки строго технического описания и наличия свободного времени более полезным мог бы быть уже не один раз упомянутый RFC 4347.
Данная тема будет периодически обновляться – в сообщение я буду заносить всю информацию, которая будет попадаться в ходе проведения анализа защищённости различных систем, различных новостей об уязвимостях протокола и т. п.
Доп. информация:
Поддержка DTLS реализована в Cisco AnyConnect VPN/WebVPN Cisco ASA. Support for DTLS first arrived in ASA release 8.0(2) some three years ago; however for the IOS this has just recently been added in IOS® 15.1(2)T ([4]). Актуальные поддерживаемые версии можно найти на cisco.com.
Настройка DTLS сервера в Cisco ASA:
asa2(config-webvpn)# enable outisde
INFO: WebVPN and DTLS are enabled on ‘outisde’.
asa2(config-webvpn)# dtls port ?
webvpn mode commands/options:
<1-65535> The DTLS server’s listening port. UDP port 443 is the default.
asa2(config-group-webvpn)# svc dtls ?
config-group-webvpn mode commands/options:
enable Enable DTLS for SVC
none Disable DTLS for SVC
Настройка DTLS для группы (интерфейс inside):
hostname(config)# enable inside
hostname(config)# group-police sales attributes
hostname(config)# webvpn
hostname(config-group-webvpn)# svc dtls enable
Примеры уязвимостей в DTLS:
OpenSSL plain-text disclosure possibility (CVE-2011-4108)
OpenSSL DTLS DoS atack (CVE-2012-0050)
Ссылки:
1) RFC 4347
2) The Design and Implementation of Datagram TLS (очень детальное описание)
3) Уязвимости SSL/TLS: CVE-2009-3555 (1), CVE-2009-3555 (2), CVE-2011-1473
c3ret 