Хабрахабр

Постоянная генерация альтернативных версий TLS решит проблему «окостенения» старого протокола

3 практически завершена. Работа над новой версией протокола TLS 1. После четырёх лет обсуждения в марте 2018 года комитет IETF утвердил 28-ю версию черновика в качестве предложенного стандарта, так что она должна стать последней перед принятием окончательных спецификаций.

3 примерно вдвое ускоряет процесс установления безопасного соединения за счёт объединения нескольких шагов на этом этапе. TLS 1. Этот режим гарантирует защиту сессионных ключей даже в случае компрометации ключей долговременного пользования.
Реализованы и многочисленные другие улучшения, в том числе поддержка потокового шифра ChaCha20, алгоритмы цифровой подписи Ed25519 и Ed448, протоколы обмена ключами x25519 и x448 и др. Кроме того, в нём реализован режим совершенной прямой секретности через эфемерные ключи (EC)DH. Удалена поддержка устаревших хэш-функций MD5 и SHA-224, слабых и редко используемых эллиптических кривых

Специалисты из Google предлагают периодически генерировать случайным образом новую версию протокола TLS с небольшими изменениями. Но самое интересное — новая идея, которая сейчас обсуждается в IETF. Идея в том, что частое обновление станет противоядием от опасного «окостенения».

Что это за проблема?

Так называемое «окостенение» — ситуация, когда разработчики протокола вдруг осознают, что сложно внедрить какие-то улучшения из-за повсеместного распространения старой версии, которая по каким-то причинам устраивает пользователей. В реальности старая версия уже не удовлетворяет современным требованиям безопасности и новым спецификациям, но де-факто её внедрить не получается.

3 стали так называемые промежуточные узлы (middlebox), а именно вендоры решений в области «безопасности». Есть мнение, что основным «тормозом» конкретно при внедрении TLS 1. В новой версии стандарта SSL-сертификаты шифруются, так что «посредники» уже не смогут их сканировать. Они советуют своим клиентам прописывать специфические правила файрволов со сканированием сертификатов при рукопожатии TLS.

Как постоянное обновление решит проблему «окостенения» протокола?

Постоянное обновление каждые шесть недель — схема, знакомая по браузеру Chrome. В такой ситуации «исполнители» вынуждены соответствовать спецификациям, поскольку несовместимая реализация не будет работать для большой доли пользователей.

Он пишет, что TLS 1. В списке рассылки IETF эту идею предложил Дэвид Бенджамин (David Benjamin) из проекта Chromium. 2. 3 — расширяемый протокол, обратно совместимый с TLS 1. 2. Его можно накатывать постепенно, обновляя текущие реализации TLS 1. Многочисленные несовместимые серверы не смогут установить связь на этапе TLS 1. И тут возникают проблемы. 3 ClientHello, так что придётся откатиться к установлению связи по поддерживаемой версии протокола.

Обсуждая меры профилактики, он упоминает инварианты протокола, которые перечислены в пункте 9. Дэвид Бенджамин выдвигает идею, как избежать этой проблемы в будущем. Все конечные точки и промежуточные узлы обязаны соответствовать описанным инвариантам. 3 спецификаций. Точно так же промежуточные узлы не имеют права делать это при передаче соединения между обновлёнными клиентом и сервером и не могут влиять на рукопожатие. В частности, новые клиенты и новые серверы не имеют права снижать уровень параметров до старой версии. 3. Однако учитывая неравномерную скорость обновления обновлённые клиенты и серверы могут поддерживать установление связи по старому протоколу, но только корректным образом, описанным в пункте 9.

Как же заставить промежуточные узлы выполнять ключевое правило обработки ClientHello — игнорировать нераспознанные параметры? Но практика показывает, что недостаточно описать требуемое поведение в спецификациях. Для этого предлагается метод GREASE.

GREASE: противоядие против «окостенения»

GREASE (Generate Random Extensions And Sustain Extensibility) — метод генерации случайных расширений к TLS и постоянный выпуск новых версий протокола. Дэвид Бенджамин предлагает установить стандартный шестинедельный цикл релизов, который будет совпадать с выходом новых версий Chrome.

Оно же распространится на промежуточные узлы. Выпуск такого «мусора» в большом количестве заставит серверы соблюдать ключевое правило обработки ClientHello игнорировать нераспознанные параметры. Аналогично, следует заполонить экосистему большим количеством таких ответов. Чтобы они не вмешивались в коммуникации между клиентом и сервером, для них ключевое правило такое: если ты не отправлял запрос ClientHello, то ты не имеешь права обрабатывать ответ.

— примерно каждые шесть недель, в соответствии с графиком релизов Chrome. «Короче говоря, мы планируем регулярно штамповать новые версии TLS (а вероятно, и другие чувствительные параметры, такие как расширения), — говорит Бенджамин, судя по всему, выражая точку зрения компании Google. 3: стандартную стабильную 0x0304 и временную альтернативную версию. Затем Chrome, серверы Google и все остальные, кто желает участвовать, будет поддерживать две (или больше) версии TLS 1. Во всём остальном эти версии идентичны 1. Каждые шесть недель мы случайным образом выбираем новую кодовую точку. Цель состоит в том, чтобы проложить путь для будущих версий TLS, имитируя их (draft negative one)». 3, за исключением, может быть, незначительных деталей для разделения ключей и осуществления разрешённых синтаксических изменений.

Кроме того, следует выработать меры предосторожности, ведь задача — обслуживать и поддерживать расширяемость TLS, а не мешать развитию протокола. У такой схемы есть определённые риски, в том числе коллизии кодовых точек. Из мер предосторожности:

  • Подробная документация всех кодовых точек (при отработке одной точки в полтора месяца их хватит более чем на 7000 лет).
  • Проактивная профилактика коллизий: отказ от номеров, которые может выбрать IETF.
  • BoringSSL не включит эту опцию по умолчанию. Её включат только там, где её можно отключить: на серверах и в браузере. В реальности, скорее всего, в каждый момент времени будут использоваться только несколько последних кодовых точек. Поскольку они быстро меняются, то экосистема не должна привязаться ни к какому такому временному расширению, а реализации останутся совместимыми друг с другом.
  • Если по каким-то причинам метод не заработает, эксперимент можно остановить в любой момент.

Идея интересная, и если Google начнёт действовать таким образом, то действительно сможет избавить экосистему от опасного «окостенения» из-за вендоров решений в области «безопасности» и других специфических корпоративных систем. Представитель компании Cloudflare поддержал это предложение. В любом случае, сказал он, нужно сделать хоть что-нибудь, чтобы в будущем избежать проблемы, с которой мы столкнулись при попытке внедрить TLS 1.3. Другой член рабочей группы IETF назвал это «фантастической идеей» и предложил Google создать вики-страничку с описанием кодовых точек, которые она использует или планирует использовать в будущем.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»