Постоянная генерация альтернативных версий 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: стандартную стабильную 0x0304 и временную альтернативную версию. Каждые шесть недель мы случайным образом выбираем новую кодовую точку. Во всём остальном эти версии идентичны 1.3, за исключением, может быть, незначительных деталей для разделения ключей и осуществления разрешённых синтаксических изменений. Цель состоит в том, чтобы проложить путь для будущих версий TLS, имитируя их (draft negative one)».

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

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

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



    GlobalSign
    Компания

    Комментарии 11

      +2

      Не понятно, как они запретят посредникам всё-таки вмешиваться. Если я верно понял, рандомные вставки будут игнорировать и всё (или передавать как есть).

        +2

        Знаем мы эту борьбу с "окостенением" на примере налоговой и прочей отчётности, когда гешефт рубят конторы типа 1С, СКБ-Контур и прочие, что кормятся от постоянного изменения стандартов. Это же выгодно и крупным корпорациям, которые могут за всем угнаться в отличие от малого и среднего бизнеса.


        Видимо, аналогично "неокостенивающий" TLS педалируют Google и прочие АНБ, чтобы принуждать веб-юзеров использовать только "современные версии браузеров" с самыми свежими зондами и бэкдорами.


        Кроме того, для "заботы о пользователях" можно будет оперативно объявлять "устаревшими" предыдущие версии протокола и, как следствие, делать неработоспособными 95% сайтов, за исключением сайтов крупных корпораций, которые будут "вовремя переходить на новые версии протоколов".

          –2
          Кроме того, для «заботы о пользователях» можно будет оперативно объявлять «устаревшими» предыдущие версии протокола и, как следствие, делать неработоспособными 95% сайтов, за исключением сайтов крупных корпораций, которые будут «вовремя переходить на новые версии протоколов».
          Наоборот, это делается для поддержания работоспособности сайтов, чтобы обратная совместимость не ломалась в будущем.

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

          А что у нас все мешает внедрить на госсайтах и порталах доступ по TLS с российскими шифрсьютами? Тоже "окостенение"?

            0
            Скорее нежелание использовать местечковые поделки взамен общепринятых.
              –2

              То есть российские ГОСТ-ы (а это Закон), рекомендации ТК-26, сертификация в системе сертификации ФСБ России (а это обязательное требование) — все это местечковые поделки и необщепринятое! Я не против, но только об этом надо честно сказаиь.

                0
                Совершенно верно. Не будете же вы утверждать, что существуют объективные причины для выдумывания своих, сермяжно-посконных алгоритмов шифрования, кроме замыкания на ФСБ и окружающие её конторы денежных потоков от сертификации и т. п. вещей и возможности «не пущать» в случае чего?
              0
              Отсутствие поддержки этих шифрсьютов в апстриме. Если чего-то нет по умолчанию в основных браузерах, то этого нет и у большинства пользователей. Следовательно, нет интереса/экономической оправданности этот доступ и реализовывать, если его будут использовать 2.5 пользователя, поставивших себе кастомную сборку браузера.

              Чтобы разорвать этот порочный круг, нужно работать с апстримом.
                0

                А тогда зачем законы об ЭП? Зачем вообще ГОСТ-ы? Зачем ТК-26 и его методические рекомендации и требования?

              –1

              Как бы DANE решит проблему всех и всего.

                0
                Это усилит сдвиг в облака, т.к. мелкие частники, просто не будут успевать за обновлением протокола, короче, очередной вендорский произвол.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое