В начале года, в отчете о проблемах и доступности интернета за 2018-2019 мы уже писали, что распространение TLS 1.3 неизбежно. Некоторое время назад мы сами развернули версию 1.3 протокола Transport Layer Security и, после сбора и анализа данных, наконец, готовы рассказать об особенностях этого перехода.

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

Разработка TLS 1.3 заняла долгих 10 лет. Мы в Qrator Labs, вместе со всей остальной отраслью, внимательно следили за процессом создания протокола от первоначального проекта. За это время потребовалось написать 28 последовательных версий черновика для того, чтобы в конечном счёте в 2019 году свет увидел сбалансированный и удобный в развертывании протокол. Активная поддержка TLS 1.3 рынком уже очевидна: внедрение проверенного и надежного протокола безопасности отвечает требованиям времени.

По словам Эрика Рескорлы (технического директора Firefox и единственного автора TLS 1.3) в интервью The Register:
«Это полная замена TLS 1.2, использующая те же ключи и сертификаты, поэтому клиент и сервер могут автоматически общаться по TLS 1.3, если оба его поддерживают», — сказал он. «Уже есть хорошая поддержка на уровне библиотек, а Chrome и Firefox по умолчанию включают TLS 1.3».

Параллельно в рабочей группе IETF TLS заканчивается подготовка RFC, объявляющего старые версии TLS (за исключением только TLS 1.2) устаревшими и непригодными для использования. Вероятнее всего, финальный RFC увидит свет до конца лета. Это ещё один сигнал IT-индустрии: обновление протоколов шифрования не стоит откладывать.

Список текущих реализаций TLS 1.3 доступен на Github для всех, кто ищет наиболее подходящую библиотеку: https://github.com/tlswg/tls13-spec/wiki/Implementations. Очевидно, что принятие и поддержка обновленного протокола будет — и уже идет — быстрыми шагами. Понимание того, насколько фундаментальным стало шифрование в современном мире, распространилось достаточно широко.

Что изменилось по-сравнению с TLS 1.2?


Из заметки Internet Society:
«Как TLS 1.3 делает мир лучше?

TLS 1.3 включает определённые технические преимущества — такие, как упрощенный процесс рукопожатия (handshake) для установления безопасного соединения — а также позволяет клиентам быстрее возобновлять сессии с серверами. Эти меры призваны уменьшить задержку на установку соединения и количество неудачных соединений на слабых каналах, которые часто используются в качестве оправдания для предоставления только нешифрованных HTTP-соединений.

Не менее важно и то, что устранена поддержка нескольких устаревших и небезопасных алгоритмов шифрования и хеширования, которые все еще разрешено (хотя и не рекомендуется) использовать с более ранними версиями TLS, включая SHA-1, MD5, DES, 3DES и AES-CBC, одновременно добавляя поддержку новых наборов шифров. Другие усовершенствования включают в себя больше зашифрованных элементов рукопожатия (например, теперь зашифрован обмен информацией о сертификате), чтобы уменьшить объем подсказок потенциальному перехватчику трафика, а также улучшения в forward secrecy при использовании определенных режимов обмена ключами, так что связь в любой момент времени должна оставаться безопасной, даже если алгоритмы, используемые для ее шифрования, будут скомпрометированы в будущем».

Разработка современных протоколов и DDoS


Как вы, возможно, уже читали, во время разработки протокола и даже после, в рабочей группе IETF TLS возникали серьезные противоречия. Уже теперь очевидно, что отдельным предприятиям (включая финансовые учреждения) придется изменить способ обеспечения безопасности собственной сети для того, чтобы приспособиться к ныне встроенной в протокол perfect forward secrecy.

Причины, по которым это может потребоваться, изложены в документе, написанном Стивом Фентером. В 20-страничной бумаге упоминается несколько примеров, когда предприятие может захотеть выполнить расшифровку out-of-band трафика (что PFS делать не позволяет), в целях мониторинга, соответствия нормативным требованиям или обеспечения защиты от DDoS-атак на прикладном уровне (L7).



Хотя мы определенно не готовы рассуждать о нормативных требованиях, наш собственный продукт для нейтрализации прикладных DDoS-атак (включая решение, не требующее раскрытия чувствительной и/или конфиденциальной информации) был создан в 2012 году с учётом PFS, поэтому нашим клиентам и партнёрам никаких изменений в их инфраструктуре после обновления версии TLS на стороне сервера производить не потребовалось.

Также, за прошедшее с момента внедрения время никаких проблем, связанных с транспортным шифрованием, выявлено не было. Официально: TLS 1.3 готов к использованию в продакшене.

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

Так, хорошим примером может выступать раздел 4.4 черновика IETF “QUIC Manageability” («Управление QUIC»), являющегося частью будущего набора протоколов QUIC: в нем говорится, что «современные методы обнаружения и нейтрализации [DDoS-атак] обычно включают пассивное измерение с использованием данных о сетевых потоках».

Последнее, на самом деле, очень редко встречается в реальных корпоративных средах (и лишь отчасти применимо к интернет-провайдерам), и в любом случае вряд ли является «общим случаем» в реальном мире — но постоянно фигурирует в научных публикациях, обычно не подкрепленных тестированием всего спектра потенциальных DDoS-атак, включая атаки прикладного уровня. Последние, в силу хотя бы всемирного развертывания TLS, очевидно никак не могут быть обнаружены пассивным измерением сетевых пакетов и потоков.

Аналогично, мы пока не знаем, как производители оборудования для нейтрализации DDoS будут адаптироваться к реалиям TLS 1.3. Из-за технической сложности поддержки out-of-band протокола, может уйти некоторое время на апгрейд.

Постановка правильных целей для направления научных исследований — серьёзная задача для провайдеров услуг нейтрализации DDoS. Одна из областей, в которой можно начать развитие — исследовательская группа SMART в IRTF, где исследователи могут сотрудничать с отраслью для уточнения собственных знаний в проблемной отрасли и поиска новых направлений исследований. Мы также готовы тепло поприветствовать всех исследователей, если таковые найдутся — с нами можно связаться по вопросам или предложениям, связанным DDoS-исследованиями или с исследовательской группой SMART, по адресу rnd@qrator.net

Комментарии (22)


  1. Revertis
    27.04.2019 15:20

    а также позволяет клиентам быстрее возобновлять сессии с серверами
    К сожалению, этот момент может использоваться для слежки в качестве замены кук.


    1. ximaera
      28.04.2019 14:37

      Можете пояснить, что вы имеете в виду?


      1. Revertis
        28.04.2019 14:46

        Ведь для возобновления сессии браузер присылает некую «куку», которая серверу даёт понять какой клиент вернулся.


        1. homm
          29.04.2019 19:26

          А где и сколько хранится эта кука на сервере?


          1. Revertis
            29.04.2019 20:24

            Можете прочитать вот тут, например:
            xakep.ru/2018/10/25/tls-session-resumption


        1. ximaera
          30.04.2019 20:08

          А, тикет. Да, но это в принципе проблема браузеров (относительно легко решаемая). Мы, со своей стороны, подобной слежкой в любом случае не занимаемся.


  1. danemon
    27.04.2019 17:08
    +1

    В блоге компании Qrator Labs пока понятно, что эта компания внедрила у себя TLS 1.3. Но решалась ли как-то проблема, описанная достаточно давно например здесь?

    Понятно, что протокол 1,3 предпочтительнее использовать: площадь атаки поменьше, чем в 1,2. Но фанфары трубить все еще рано. Кто хотел, тот давно почитал про версии всех этих и других протоколов. И сделал для себя некоторый выбор. Ваш выбор мы уже знаем.

    Не сочтите меня за хейтера или что-то такое.


    1. ximaera
      28.04.2019 14:33
      +1

      В RFC 8446 этому посвящена отдельная секция.

      Понятно, что абсолютно все проблемы TLS 1.3 решить не смог, но это достаточно полный snapshot исследований по состоянию на сейчас. Последующие работы, такие, как QUIC, ESNI, DoH, MASQUE, могут использовать TLS 1.3 как фундамент.


  1. saipr
    27.04.2019 17:36

    Не менее важно и то, что устранена поддержка нескольких устаревших и небезопасных алгоритмов шифрования и хеширования, которые все еще разрешено (хотя и не рекомендуется) использовать с более ранними версиями TLS, включая SHA-1, MD5, DES, 3DES и AES-CBC, одновременно добавляя поддержку новых наборов шифров.

    А поддержка российских шифрсюитов появится когда-нибудь?


    1. BugM
      27.04.2019 18:46
      +3

      А что Вы и ваши коллеги из КриптоПро сделали для этого?
      Вы самые заинтересованные лица. Вам и суетиться о включении в стандарт.


      1. saipr
        27.04.2019 19:58
        -2

        И в чем же эта заинтересованность?
        А коллеги делают. Но это только техническая реализация и не более того.


        1. BugM
          27.04.2019 20:04
          +13

          Бинарники без исходников? Это все что делается для включения в RFC?
          Вы полностью заслужили не включения в tls1.3

          Работать надо, а не изображать бурную деятельность и переживания.


        1. l0rda
          28.04.2019 00:22
          +2

          Видимо делают, но не используют :)


          ничего личного, просто забавно


        1. metalim
          28.04.2019 13:58

          И всё же: позвольте узнать, почему ваш сайт не поддерживает https? Это связано с ленью? Или же какими-то практическими принципами? Если второе, то какими?


    1. vsb
      28.04.2019 00:15
      -1

      А в стандарте жёстко прописаны допустимые шифры? Странный стандарт, не расширяемый. Думаю, можно такой стандарт спокойно нарушать, пока есть контроль за клиентом и сервером.


      1. blind_oracle
        28.04.2019 00:54
        +2

        На то он и стандарт.


        В 1.2 было 37 наборов симметричных шифров, в 1.3 осталось 5 (вариации aes и chacha) — такой вот естественный отбор.


    1. SagePtr
      28.04.2019 15:09

      А поддержка российских шифрсюитов появится когда-нибудь?
      Вы про те самые, в которых с высокой долей вероятностью имеются закладки? Очень надеюсь, что их поддержка не войдёт в стандарт никогда, по крайней мере, этих двух.


      1. ximaera
        30.04.2019 20:09

        Из приведённого поста, честно говоря, вероятность никак нельзя оценить как «высокую». Хотя задокументировать принцип формирования S-box'ов, конечно же, не мешало бы.


  1. Incidence
    27.04.2019 18:47
    +1

    В 20-страничной бумаге
    В оригинале наверняка было что-то типа «In 20-page paper», так что тут не бумага а статья :)


    1. Barafu_Albino_Cheetah
      28.04.2019 02:23

      Ну у нас тоже говорят «пришла бумага из министерства». Так что не страшно.


      1. Leopotam
        28.04.2019 11:40

        Если бы говорили «тебе пришла статья из министерства» — было бы страшнее.


  1. bodqhrohro
    28.04.2019 12:26

    Website User какой-то квадратный. Тоже робот, что ли?