Постоянная генерация альтернативных версий TLS решит проблему «окостенения» старого протокола
Работа над новой версией протокола TLS 1.3 практически завершена. После четырёх лет обсуждения в марте 2018 года комитет IETF утвердил 28-ю версию черновика в качестве предложенного стандарта, так что она должна стать последней перед принятием окончательных спецификаций.
TLS 1.3 примерно вдвое ускоряет процесс установления безопасного соединения за счёт объединения нескольких шагов на этом этапе. Кроме того, в нём реализован режим совершенной прямой секретности через эфемерные ключи (EC)DH. Этот режим гарантирует защиту сессионных ключей даже в случае компрометации ключей долговременного пользования.
Реализованы и многочисленные другие улучшения, в том числе поддержка потокового шифра ChaCha20, алгоритмы цифровой подписи Ed25519 и Ed448, протоколы обмена ключами x25519 и x448 и др. Удалена поддержка устаревших хэш-функций MD5 и SHA-224, слабых и редко используемых эллиптических кривых
Но самое интересное — новая идея, которая сейчас обсуждается в IETF. Специалисты из Google предлагают периодически генерировать случайным образом новую версию протокола TLS с небольшими изменениями. Идея в том, что частое обновление станет противоядием от опасного «окостенения».
Что это за проблема?
Так называемое «окостенение» — ситуация, когда разработчики протокола вдруг осознают, что сложно внедрить какие-то улучшения из-за повсеместного распространения старой версии, которая по каким-то причинам устраивает пользователей. В реальности старая версия уже не удовлетворяет современным требованиям безопасности и новым спецификациям, но де-факто её внедрить не получается.
Есть мнение, что основным «тормозом» конкретно при внедрении TLS 1.3 стали так называемые промежуточные узлы (middlebox), а именно вендоры решений в области «безопасности». Они советуют своим клиентам прописывать специфические правила файрволов со сканированием сертификатов при рукопожатии TLS. В новой версии стандарта SSL-сертификаты шифруются, так что «посредники» уже не смогут их сканировать.
Как постоянное обновление решит проблему «окостенения» протокола?
Постоянное обновление каждые шесть недель — схема, знакомая по браузеру Chrome. В такой ситуации «исполнители» вынуждены соответствовать спецификациям, поскольку несовместимая реализация не будет работать для большой доли пользователей.
В списке рассылки IETF эту идею предложил Дэвид Бенджамин (David Benjamin) из проекта Chromium. Он пишет, что TLS 1.3 — расширяемый протокол, обратно совместимый с TLS 1.2. Его можно накатывать постепенно, обновляя текущие реализации TLS 1.2. И тут возникают проблемы. Многочисленные несовместимые серверы не смогут установить связь на этапе TLS 1.3 ClientHello, так что придётся откатиться к установлению связи по поддерживаемой версии протокола.
Дэвид Бенджамин выдвигает идею, как избежать этой проблемы в будущем. Обсуждая меры профилактики, он упоминает инварианты протокола, которые перечислены в пункте 9.3 спецификаций. Все конечные точки и промежуточные узлы обязаны соответствовать описанным инвариантам. В частности, новые клиенты и новые серверы не имеют права снижать уровень параметров до старой версии. Точно так же промежуточные узлы не имеют права делать это при передаче соединения между обновлёнными клиентом и сервером и не могут влиять на рукопожатие. Однако учитывая неравномерную скорость обновления обновлённые клиенты и серверы могут поддерживать установление связи по старому протоколу, но только корректным образом, описанным в пункте 9.3.
Но практика показывает, что недостаточно описать требуемое поведение в спецификациях. Как же заставить промежуточные узлы выполнять ключевое правило обработки ClientHello — игнорировать нераспознанные параметры? Для этого предлагается метод GREASE.
GREASE: противоядие против «окостенения»
GREASE (Generate Random Extensions And Sustain Extensibility) — метод генерации случайных расширений к TLS и постоянный выпуск новых версий протокола. Дэвид Бенджамин предлагает установить стандартный шестинедельный цикл релизов, который будет совпадать с выходом новых версий Chrome.
Выпуск такого «мусора» в большом количестве заставит серверы соблюдать ключевое правило обработки ClientHello игнорировать нераспознанные параметры. Оно же распространится на промежуточные узлы. Чтобы они не вмешивались в коммуникации между клиентом и сервером, для них ключевое правило такое: если ты не отправлял запрос ClientHello, то ты не имеешь права обрабатывать ответ. Аналогично, следует заполонить экосистему большим количеством таких ответов.
«Короче говоря, мы планируем регулярно штамповать новые версии TLS (а вероятно, и другие чувствительные параметры, такие как расширения), — говорит Бенджамин, судя по всему, выражая точку зрения компании Google. — примерно каждые шесть недель, в соответствии с графиком релизов Chrome. Затем Chrome, серверы Google и все остальные, кто желает участвовать, будет поддерживать две (или больше) версии TLS 1.3: стандартную стабильную 0×0304 и временную альтернативную версию. Каждые шесть недель мы случайным образом выбираем новую кодовую точку. Во всём остальном эти версии идентичны 1.3, за исключением, может быть, незначительных деталей для разделения ключей и осуществления разрешённых синтаксических изменений. Цель состоит в том, чтобы проложить путь для будущих версий TLS, имитируя их (draft negative one)».
У такой схемы есть определённые риски, в том числе коллизии кодовых точек. Кроме того, следует выработать меры предосторожности, ведь задача — обслуживать и поддерживать расширяемость TLS, а не мешать развитию протокола. Из мер предосторожности:
- Подробная документация всех кодовых точек (при отработке одной точки в полтора месяца их хватит более чем на 7000 лет).
- Проактивная профилактика коллизий: отказ от номеров, которые может выбрать IETF.
- BoringSSL не включит эту опцию по умолчанию. Её включат только там, где её можно отключить: на серверах и в браузере. В реальности, скорее всего, в каждый момент времени будут использоваться только несколько последних кодовых точек. Поскольку они быстро меняются, то экосистема не должна привязаться ни к какому такому временному расширению, а реализации останутся совместимыми друг с другом.
- Если по каким-то причинам метод не заработает, эксперимент можно остановить в любой момент.
Идея интересная, и если Google начнёт действовать таким образом, то действительно сможет избавить экосистему от опасного «окостенения» из-за вендоров решений в области «безопасности» и других специфических корпоративных систем. Представитель компании Cloudflare поддержал это предложение. В любом случае, сказал он, нужно сделать хоть что-нибудь, чтобы в будущем избежать проблемы, с которой мы столкнулись при попытке внедрить TLS 1.3. Другой член рабочей группы IETF назвал это «фантастической идеей» и предложил Google создать вики-страничку с описанием кодовых точек, которые она использует или планирует использовать в будущем.
