«Интернет стал чуть безопаснее»: комитет IETF утвердил TLS 1.3

    Спустя 4 года и 28 драфтов, Инженерный совет Интернета (IETF) одобрил обновленный протокол TLS 1.3. Далее расскажем, в чем причина длительного утверждения протокола, и поговорим о его особенностях.


    / фото Solo se puede CC

    Почему так долго


    Утверждение новой версии протокола заняло столько времени, так как обновление вызвало у некоторых компаний, в частности, банков, опасения. TLS 1.3 не позволяет расшифровывать проходящий трафик в сети, так как архитектура нового протокола использует эфемерные ключи вместо статических. Банкам необходимо анализировать трафик, чтобы обеспечить прозрачность подключений: ЦОД для финансовых организаций обычно подчиняется определенным требованиям (например, требованиям стандарта PCI DSS).

    Для того чтобы получить возможность отслеживать трафик, некоторые операторы предложили встроить в протокол своеобразный «бэкдор»: внедрить статический протокол Диффи — Хеллмана. Обсуждение этого вопроса и задержало одобрение TLS. Отметим, что инициатива все же была отклонена.

    Первая причина отказа заключается в том, что использование статического протокола Диффи — Хеллмана позволит прослушивать сеть, а это нарушение RFC 2804 IETF Policy on Wiretapping.

    Вторая причина — неготовность рабочих групп IETF стандартизировать поддержку слабого шифрования в новом протоколе. Как показывает история, использование слабых алгоритмов шифрования, например, шифров RSA экспортного класса, может привести к таким атакам, как man-in-the-middle. Поэтому в IETF не согласились задействовать менее защищенные версии TLS, даже если это усложнит работу сетевых провайдеров.

    На пути TLS 1.3 также встал случай с Хромбуками. В январе 2017 года Google представили релиз Chrome 56 с поддержкой TLS 1.3, доступный для устройств на Linux, macOS, Windows, Android и iOS. Но после обновления Chrome до новой версии, Хромбуки и Windows-ПК в школах округа Монтгомери, США, не смогли подключиться к сети.

    Позже выяснилось, что причиной сбоя стал инструмент безопасности Blue Coat 6.5. Он «вешал» систему, если Chrome устанавливал соединение по TLS 1.3, так как разработчики не до конца следовали спецификациям Google. В итоге ИТ-гигант временно приостановил внедрение протокола.


    / фото Jack-Benny Persson CC

    Главные особенности TLS 1.3


    В TLS 1.3 разработчики сделали несколько существенных изменений, по сравнению с предыдущей версией протокола.

    Изменили процедуру «рукопожатия»

    При использовании TLS 1.2 процесс установления соединения проходит в несколько этапов:

    • Сперва клиент обращается к серверу и предлагает ряд систем шифрования, с которыми он может работать.
    • Сервер отвечает клиенту, сообщает, какую систему шифрования он будет использовать, и отправляет ключ шифрования.
    • Клиент получает ключ и использует его для шифрования и отправки случайной последовательности символов.
    • Далее создаются 2 новых ключа: мастер-ключ (сильнее) и сессионный ключ (слабее).
    • Далее, клиент сообщает, какую систему шифрования он планирует использовать для сессионного ключа.
    • Наконец, сервер одобряет систему шифрования и начинается обмен данными.

    TLS 1.3 в 2 раза ускоряет весь процесс за счет объединения нескольких шагов, сокращая время до начала обмена информацией. Последовательность получается следующая:

    • Клиент сообщает серверу о системах шифрования, с которыми он может работать.
    • Сервер одобряет системы и передает свой ключ.
    • Клиент предоставляет сессионные ключи.

    При этом сам механизм стал более безопасным, так как разработчики удалили все алгоритмы, которые не используют AEAD-режимы блочного шифрования. При этом в структуре типовых шифронаборов механизмы аутентификации и обмена ключами были «отделены» от алгоритма защиты записи и хеш-функции для HMAC.

    Внедрили forward secrecy

    Это нововведение не позволит злоумышленникам использовать скопированные ключи одной сессии для расшифровки других данных. Даже в случае компрометации мастер-ключа, сессионные ключи не будут взломаны.

    Добавили режим 0-RTT

    Режим, в котором сервер и клиент могут установить соединение по старым ключам, если они уже обменивались пакетами. Такой подход сократит время до начала приема-передачи данных.

    Однако в этом случае клиент (например, браузер) не устанавливает защищенный канал с сервером, а просто посылает запрос. При этом злоумышленники могут перехватить пакет и при желании подделать его. Поэтому в спецификации протокола отдельно рассмотрены атаки повторного воспроизведения (Replay Attacks), которые реализуются путём записи и последующей отправки ранее посланных корректных сообщений, и способы противодействия им.

    Здесь важно помнить, что ответственность за реализацию защиты от подобных атак несет сервер, поэтому в документе IETF сделан особый упор на механизмы защиты, которые бы противодействовали деятельности злоумышленников. С предлагаемыми подходами можно ознакомиться по ссылке.

    Описание других функций и особенностей стандарта можно найти здесь.



    P.S. Несколько материалов из Первого блога о корпоративном IaaS:


    P.P.S. Подборка статей из блога «ИТ-ГРАД» на Хабре:

    ИТ-ГРАД 265,90
    vmware iaas provider
    Поделиться публикацией
    Комментарии 10
    • 0
      обновление вызвало у некоторых компаний, в частности, банков, опасения
      некоторые операторы предложили
      инициатива все же была отклонена

      И что банки?
      • 0
        Вероятно, у банков нет выбора и им придется разрабатывать нужное решение для просмотра трафика самостоятельно.

        А другие компании уже работают с TLS 1.3 – еще до утверждения можно было активировать в браузерах; в Cisco готовят решения для защиты трафика с учетом новых возможностей протокола.
        • 0
          Вероятно, у банков нет выбора и им придется разрабатывать нужное решение для просмотра трафика самостоятельно.

          Так 1.3 якобы технически подобное не позволяет. Поэтому действительно интересно про банки.
          • +1
            Дык никто не запрещает впарить свой сертификат CA и устроить проксю для TLS трафика. Просто им придётся разработать *другое* решение, а не использовать такое-же, как было до TLS 1.3.
            • –1

              А зачем банкам просматривать трафик?

              • 0
                В целях обеспечения корпоративной безопасности(следить за сотрудниками).
                • –1
                  А, вы про внутренний трафик?!
                  Я уж подумал про трафик клиентов.
            • 0
              Если я все правильно понял (глубоко не вникал), то раньше банки могли «отдать» статические ключи которыми шифровали трафик некоей «контролирующей организации» и она могла весь трафик к этим банкам расшифровать и смотреть.
              Сейчас, т.к. нету статических ключей, нужно либо громоздить инфраструктуру по передаче эфемерных, либо ставить mitmproxy, либо еще что-то такое придумывать…
        • 0
          Спасибо большое за статью! Поясните пожалуйста, про нововведения 0-RT и forward secrecy. Один разрешает использовать старые ключи для продления сессии, другой даёт возможность защиты но в качестве рекомендации к инженерам серверной части от replay атак. Правильно ли я, понял?
          • 0
            Надеюсь, не скоро наступит время, когда придется экстренно перебираться на TLS 1.3.

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

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