TLS 1.3: хит наступающего сезона

Несколько недель назад была окончательно одобрена спецификация протокола TLS 1.3. Нет, номер RFC ещё не присвоен, но время изучить для себя возможности нового протокола уже наступило.

Протокол разрабатывался в течение нескольких лет. Старт разработке был дан после публикаций Сноудена — они оказались важной вехой в новейшей истории информационной безопасности. Документ прошёл почти три десятка редакций, сообщество внесло в него огромное количество правок. В процессе разработки было принято несколько принципиально новых решений. Все изменения в дизайне протокола направлены на то, чтобы максимально защитить коммуникации пользователей.

Разработчики спецификации во главе с Эриком Рескорлой (Eric Rescorla) избавились от исторических напластований предыдущих версий протокола. Устаревшие алгоритмы, короткие ключи и даже параметры, которые можно подменить на стадии установления соединения — всё это служило зацепкой для атак на протяжение многих лет, и всё отправляется на свалку истории. Мы уже писали о том, что из протокола выпала и не была добавлена обратно возможность читать записанный трафик, добыв секретный ключ сервера. Используемые для шифрования алгоритмы тоже сделаны по последней криптографической моде — требуются так называемые AEAD-режимы алгоритмов шифрования, которые защищают, в частности, от некоторых разновидностей атак, построенных по принципу оракула. Эти атаки удаются, когда сервер даёт разные коды ошибки в зависимости от того, как именно исказил сообщение злоумышленник.

Расскажем об основных изменениях нового протокола. Рабочая группа полностью переопределила список шифронаборов — комбинаций алгоритмов, описывающих соединение с сервером. Это позволит избежать использования старых шифронаборов при общении с “новыми” серверами. Да и само определение шифронабора подверглось существенной коррекции — механизмы аутентификации теперь отделены от алгоритмов шифрования. Добавлены новые алгоритмы — так называемая кривая 25519 для аутентификации и алгоритм шифрования ChaCha. А вот алгоритм DSA, и без того встречающийся в живой природе очень редко, в новом протоколе поддерживаться не будет. Существенно переработан механизм работы с сессиями — идентификаторами соединений с конкретным клиентом. Ну и нельзя не отметить очень важный момент — количество обменов данными (round-trip), необходимых для установления соединений, теперь стало на один меньше. Это значит, что сайты начнут открываться быстрее. А внесённый в спецификацию вариант 0-RTT подразумевает, что повторные соединения клиента и сервера будут изначально зашифрованы. Правда, из-за того, что будут задействованы ключи, установленные в прошлую сессию, ряд экспертов предполагает, что тут могут обнаружиться узявимости.

Гораздо меньше данных доступно теперь наблюдателю — всё, что можно зашифровать, теперь передаётся в зашифрованном виде. Переработан механизм расширений протокола — теперь клиент и сервер могут обменяться гораздо более широким спектром данных, используя расширения. Некоторые расширения уехали в зашифрованную часть трафика. К сожалению, не удалось сделать так, чтобы идентификатор сервера, с которым устанавливается соединение (эти данные тоже передаются как расширение), передавался в недоступном наблюдателю виде, но работы в этом направлении активно ведутся. Не доведена до конца и работа со спецификацией DTLS. Это близнец протокола TLS, использующий в качестве транспорта не TCP, а UDP.

Разработчики пытались упростить протокол установления соединения, но до конца им это не удалось. Дело в том, что масса промежуточных устройств — так называемые middleboxes — отказывались пропускать упрощённый протокол. Переделать спецификацию оказалось проще, чем убедить сисадминов поменять настройки. Если изначально значительная доля соединений, для которых пробовали задействовать новый протокол, не устанавливалась, то после адаптации нет разницы с аналогичной долей для уже привычного TLS 1.2.

Совокупность внесённых в спецификацию TLS изменений настолько масштабна, что много раз поднимался вопрос о “ребрендинге” протокола — вместо 1.3 он мог получить номер 2 и даже 4. Но эту идею всё-таки отклонили.

Важный вопрос — как быстро изменениями смогут воспользоваться обычные пользователи. Бета-версия openssl с поддержкой TLS 1.3 уже сейчас написана, а выход финальной версии openssl 1.1.1 ожидается вскоре после присвоения номера RFC. Другой вопрос, что до серверов она может дойти не сразу — жизненный цикл дистрибутивов операционных систем измеряется месяцами. Крупные провайдеры заинтересованы в скорейшем выпуске новой версии в эксплуатацию — ожидается, что существенно сократится время установления соединения, а значит, пользователи начнут получать контент быстрее. Так, в Cloudflare уже давно успели анонсировать поддержку протокола, но тогда это оказалось фальстартом. В браузерах поддержка появится тоже вскоре после формального присвоения номера, хотя тестирование на интероперабельность с тем же OpenSSL производится регулярно.

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


Автор:  Дмитрий Белявский (ТЦИ)

Возврат к списку