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

Полный список существующих расширений TLS можно найти на сайте IANA, там же доступны ссылки на соответствующие RFC, где подробно описано, чем грозит манкирование тем или иным расширением. Например, если вы не установили расширение Heartbeat на уязвимом веб-сервере, он будет светить в Сеть уязвимостью Heartbleed (CVE-2014-0160), а пренебрежение расширением Supported Groups попросту не позволит использовать на веб-сервере эллиптические кривые.

Однако существуют и такие расширения, без которых вроде бы все работает, и явных ошибок не видно, пока не прогонишь свой сервер через какой-нибудь сканер безопасности, чем многие администраторы явно пренебрегают (да и не все сканеры одинаково полезны), о них и будет сказ.

Почему не все сканеры одинаково полезны
Например, популярный сканер Qualys SSL Labs SSL Server Test не тестирует веб-сервера на поддержку расширения Extended Master Secret и приходится обращаться к ImmuniWeb SSL Security Test. Кроме того, сканеры иногда расходятся во мнениях, особенно в отношении поддержки и настроек расширения Renegotiation Indication. Поэтому имеет смысл проверять свой веб-сервер всеми сканерами, не полагаясь на «диагноз» только одного из них.

Renegotiation Indication позволяет предотвратить атаку на защищенное соединение классов «человек посередине» (MitM) и «отказ в обслуживании» (DoS), основанную на модификации сообщений клиента третьей стороной после искусственно вызванного ей пересогласования параметров защищенного соединения (renegotiation). Расширение позволяет клиенту и серверу проверять «связанность» сообщений Client/Server Hello с предшествующим им Finished и обнаруживать модификацию сообщений третьей стороной.

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

Поддержка расширения требуется для TLS версии 1.0-1.2, тогда как в TLS 1.3 предусмотрен «встроенный» механизм защиты от соответствующих угроз.

Extended Master Secret позволяет предотвратить атаку на защищенное соединение класса «человек посередине» (MitM), основанную на вычислении значения «основного секрета» (master secret). Расширение меняет алгоритм генерации «основного секрета», добавляя в него «элемент случайности».

Поддержка расширения требуется для TLS версий 1.0-1.2. Встречается утверждение, что угроза реальна только, если на сервере используются шифронаборы на основе алгоритма согласования ключей DHE или RSA (последний из которых сегодня и вовсе не должен применяться для согласования ключей по соображениям безопасности), однако ECDHE также уязвим, хотя и в меньшей степени.

Encrypt then MAC позволяет предотвратить атаку на защищенное соединение класса «человек посередине» (MitM), основанную на восстановлении третьей стороной ключей шифрования из перехваченного зашифрованного сообщения.

Поддержка расширения требуется для TLS версии 1.2 (более ранние версии ее не поддерживают) и меняет поведение протокола по умолчанию (MAC then Encrypt) так, что контрольная сумма блока данных (Message Authentication Code) шифруется отдельно от данных и другим ключом. Расширение не требуется, если сервером поддерживаются только AEAD шифронаборы (а сегодня только их и следует поддерживать, во всяком случае на публичных веб-серверах).

И наконец, поговорим о Fallback Signaling Cipher Suite Value, который формально не расширение TLS, а костыль типа шифронабор TLS_FALLBACK_SCSV, как какой-нибудь TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256, позволяющий предотвратить атаку на защищенное соединение класса «человек посередине» (MitM), основанную на принудительном понижении версии используемого протокола защиты транспортного уровня.

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

Поддержка псевдошифронабора требуется только в том случае, если поддерживается несколько версий TLS ниже версии 1.3, например 1.1 и 1.2. В настоящее время Fallback SCSV имеет статус deprecated, однако это вызвано лишь присвоением того же статуса протоколу TLS версий 1.0 и 1.1, и если они продолжают поддерживаться на сервере (чего делать давно не следует), то необходимо поддерживать и Fallback SCSV.

Подробнее о том, как обеспечить более защищенное HTTPS-соединение со своим веб-сервером, можно прочесть в «Руководстве по достижению соответствия Индексу надежности HTTPS», а как мы исследуем на предмет безопасности сайты государственных органов и что при этом обнаруживаем – на странице проекта «Монитор госсайтов». Очередной доклад по результатам исследования сайтов региональных госорганов ждите уже в этом месяце.

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


  1. Daniil_Palii
    07.09.2021 15:26

    Зачем использовать TLS 1.2 с расширениями вместо TLS 1.3? Что может помешать?


    1. ifap Автор
      07.09.2021 15:29

      Несовместимость со старыми клиентами.


      1. AlexVWill
        07.09.2021 16:39

        Спасибо. Если бы еще про DNS over TLS vs. DNS over HTTPS рассказали - было бы совсем здорово.


        1. ifap Автор
          07.09.2021 16:52

          Сегодня не вижу в этом смысла: пока ECH не вышел из состояния draft, все еще десять раз может измениться, и написанное сегодня станет неверным завтра.


  1. alexEtse
    07.09.2021 16:03

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

    Или может уже где-то подведено?

    Ну, на случай, если после прочтения статьи возникло практическое желание провести аудит своих систем (а уж потом более вдумчиво вырабатывать стратегию "как это исправлять, если надо исправлять")?


    1. ifap Автор
      07.09.2021 16:04

      Да, в руководстве ifap.ru/gosmon/hrim.pdf