Как подружить «современный» TLS и «устаревшие» браузеры?


    Тему подсказало обсуждение предыдущего поста, в котором прозвучал голос заботливого администратора веб-сервера: TLS 1.2 и AEAD – выбор здорового человека, но кто пожалеет пользователей «устаревших» браузеров? Давайте это обсудим – мнимую несовместимость «современного» TLS и «устаревших» браузеров.

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

    Совершим необязательный экскурс в историю… В 2005 году (т.е. 16 лет тому назад), американское Агентство национальной безопасности анонсировало корпус стандартов, руководств, рекомендаций и прочих поддерживающих документов по использованию криптографических алгоритмов – NSA Suite B Cryptography.

    В 2009 году IETF опубликовал RFC5430 Suite B Profile for Transport Layer Security, где установил, какие протоколы и шифронаборы должны использоваться для HTTPS-соединения, чтобы соответствовать требованиям АНБ. Уже тогда для соответствия этим требованиям веб-сервер и веб-браузер должны были поддерживать TLS версии 1.2 и шифронаборы TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 и TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.

    То есть, как минимум последние 11 лет разработчики знали, каким требованиям должна соответствовать их продукция, чтобы иметь возможность претендовать на американский госзаказ. Поэтому следующий факт вы, вероятно, воспримете без удивления: все реально используемые сегодня браузеры поддерживают упомянутый шифронабор в варианте с 128-битным шифроключом, а многие (но не все) – и с 256-битным.

    На этом можно было бы закончить статью, порекомендовав всем администраторам веб-серверов оставить поддержку только TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 и не забивать себе голову мифами о несовместимости TLS 1.2 с «устаревшими» браузерами, если бы не нюанс: в TLS версии младше 1.3 алгоритм цифровой подписи в шифронаборе должен совпадать с алгоритмом в TLS-сертификате, а веб-серверов с сертификатом, подписанным по алгоритму ECDSA, в доменной зоне .RU менее 6%, оставшиеся используют для подписи RSA.

    Кто виноват – вопрос отдельного исследования, нас же интересует что делать? Давайте для начала вспомним, что к устойчивым шифронаборам сегодня относятся не только рекомендуемая АНБ комбинация ECDHE+ECDSA+AES, но и другие:

    Весь зверинец
    TLS_DHE_RSA_WITH_AES_128_CCM;
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;
    TLS_DHE_RSA_WITH_AES_256_CCM;
    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;
    TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256;
    TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384;
    TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256;
    TLS_ECDHE_ECDSA_WITH_AES_128_CCM;
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;
    TLS_ECDHE_ECDSA_WITH_AES_256_CCM;
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;
    TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256;
    TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384;
    TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256;
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;
    TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256;
    TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384;
    TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256.

    Итого 19 устойчивых шифронаборов, однако не все из них подходят для использования в реальной жизни на публичном веб-сервере: алгоритм шифрования CAMELLIA, как и AES в режиме CCM, поддерживается чуть более, чем никем, с CHACHA20 и его верным спутником POLY1305 знакомы лишь относительно современные браузеры, а для использования шифронаборов на основе ECDSA, как уже было сказано, требуется соответствующий TLS-сертификат. Таким образом у нас остается лишь 4 «дополнительных» шифронабора:

    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;
    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384.

    Соблазнительно предположить, что если браузер поддерживает комбинацию ECDHE+ECDSA, то уж с ECDHE+RSA он точно справится, но это не всегда так – многие умеют только в DHE+RSA, и чтобы удовлетворить запросы всех старых браузеров, на сайте с RSA сертификатом необходимо поддерживать два шифронабора:

    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.

    Это даст нам совместимость как минимум со следующими операционными системами и браузерами:

    Android 4.4.2 + Android Browser (Chrome);
    Windows XP + Chrome 49/Firefox 49/ Opera 12.18;
    Windows 7 + Internet Explorer 11/Chrome 31/Firefox 31;
    OS X + Firefox 29/Chrome 37;
    iOS 9 + Safari 9;
    Java 8b.

    Про *nix системы не скажу – зависит от сборки, но очевидно, что проблемы как таковой не существует. Единственная проблема возникнет с Windows Phone 8.1 + IE 10, которые поддерживают только одну устойчивую комбинацию – ECDHE+ECDSA.

    А что же делать пользователям Windows XP + IE 6 или какого-нибудь Android 2.3? – спросит заботливый админ. Продолжать сидеть без доступа к современному Интернету, – отвечу я, – поскольку даже поддержка веб-сервером протокола SSL 2.0 им ничем не поможет. Дело в том, что даже если накатить на Windows XP все выпущенные для него обновления (по май 2019 года) и обновить штатный браузер до версии 8, это принесет лишь поддержку TLS 1.2, но не устойчивых шифронаборов. Кроме того, Windows XP как не знал, так и не узнает, что такое Server Name Indication (SNI), HTML 5 Live HTML и CSS 3.

    Готовы ради упертых «полутора землекопов» держать для сайта выделенный IP и не обновлять верстку? Тогда добавьте поддержку, например, TLS_RSA_WITH_AES_256_CBC_SHA256, но скорее следует предположить, что современный пользователь Windows XP уже давно пользуется альтернативным браузером, который поддерживает даже TLS 1.3. То же верно и для Android 2.3, установив на который Firefox 27, мы получим полноценную поддержку TLS 1.2 и AEAD шифронаборов, а не установив – просто не сможем пользоваться значительной частью современных сайтов даже по HTTP.

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

    Чтоб два раза не вставать, рассмотрим кратко и ситуацию с эллиптическими кривыми. NSA Suite B Cryptography признает только две из них – NIST P-384 и NIST P-256, поддержка которых на веб-сервере обеспечит доступ к сайту как современных, так и «устаревших» браузеров. Собственно, достаточно поддерживать только NIST P-384 для «старичков» и Curve25519 для современных браузеров; ну разве что еще NIST P-521 добавить, для некоторых «передовых старичков».

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

    Для сайта с TLS-сертификатом, подписанным по алгоритму ECDSA, включим поддержку шифронабора TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.

    Для сайта с TLS-сертификатом, подписанным по алгоритму RSA, включим поддержку шифронаборов TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 и TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.

    Для обоих сайтов включим поддержку эллиптической кривой NIST P-384 или NIST P-256 и зададим порядок предпочтения шифронаборов и эллиптических кривых, согласно которым вышеуказанные наборы и кривые предлагаются браузерам для согласования после более устойчивых, например после TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 и Curve25519 соответственно.

    Средняя зарплата в IT

    120 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 3 348 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

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

      0

      Полез искать, что это за CCM такой. Оказалось, переименованный CBC. Интересно, AES-CTR куда переименовали, или что с ним сделали?

      +3

      Для тех кто не любит обновлять систему — есть KB3042058, включающий поддержку
      TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
      TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
      в Win7/8/8.1/12/12R2, что может помочь
      https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/3042058

        0
        В Windows 7 уже нет так остро проблема стоит — docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-7
          0
          Если я правильно понимаю, это список с примененным апдейтом, без него этих двух CipherSuite не будет
            0
            Можно обойтись *CBC* вариантом.
            У меня как раз недавно не завелся IE7 для сервера с конфигом Mozilla intermediate. Добавление ECDHE-RSA-AES128-SHA256 решило проблему, рейтинг A+ от ssllabs по-прежнему.
              0
              Не всегда, была тут прекрасная неделя когда один вендор без объявления войны сказал — а мы тут ТЛС1.2 подкрутили и CBC не будет работать больше через 2 дня. 12(даже не Р2 сервер), только этот апдейт и спас, поскольку организовать новый сервер и перетащить клиента на него за это время у нас невозможно
                0
                В критичных случая лучше прикрутить на сайт еще и ECDSA сертификат: как ни странно покажется, но ECDHE+ECDSA поддерживается большим количеством «устаревших» клиентов, чем устойчивые вариации с использованием RSA для подписи.
                0
                Можно, но не нужно — Windows 7 SP1 + IE 11 поддеживают:
                TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
                TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
                TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
                TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

                SSL Labs и прочие «валидаторы SSL» свой рейтинг строят на требованиях NIST SP 800-52, хорошо еще если второй редакции (2019 г. издания). Которая а) еще неизвестно как долго разрабатывалась, б) ориентируются на зоопарк американского госсектора, в) предназначена не только для публичных сайтов, а вообще для всего, что коммуницирует по TLS.
                Конкретно SSL Labs не учитывает, например, поддержку EMS, которая требуется согласно NIST SP.800-52 и ставит А+ о-о-очень сомнительным на мой вкус серверам.
                  0
                  А вот у меня не поддержал. И патч указанный не ставится.
                    0
                    1. ECDHE_ECDSA наборы тоже не поддерживает?
                    2. SP1 стоит? Думаю, это pre-requirement для KB3042058, судя по дате выпуска.
                      0
                      1. нет
                      2. да
                        0
                        1. Возможно, заблокированы в GP.
                        2. Смотрите тогда лог установки, что установщику не понравилось.
                    0
                    SSL Labs и прочие «валидаторы SSL» свой рейтинг строят на требованиях NIST SP 800-52, хорошо еще если второй редакции (2019 г. издания). Которая а) еще неизвестно как долго разрабатывалась, б) ориентируются на зоопарк американского госсектора, в) предназначена не только для публичных сайтов, а вообще для всего, что коммуницирует по TLS.
                    Конкретно SSL Labs не учитывает, например, поддержку EMS, которая требуется согласно NIST SP.800-52 и ставит А+ о-о-очень сомнительным на мой вкус серверам.

                    Подскажите, пожалуйста, какой валидатор тогда адекватен современным реалиям?
                    SSL Labs — я так понял, речь про Qualys?

                      0
                      Понимаете, «современные реалии» — это же вкусовщина в любом случае, и для каждого они будут свои. У кого-то непубличный сервер и все клиенты под контролем, он может только TLS 1.3 оставить и ввести двустороннюю аутенификацию по сертификатам, а у кого-то на публичный сервер ходит клиент, который ничего выше SSL не понимает, а дропнуть его нельзя (хоть это и ужасно, но это жизнь).
                      Каждому стоит определиться именно со своими потребностями и возможностями и плясать от них, протестировав свой сервер в разных валидаторах. И не заморачиваться рейтингом — A+ может быть недостаточно для реально серьезной защиты банковского сайта, а для кого-то и B нормальный рейтинг с учетом его реальных потребностей и реальной защищенности от предполагаемого уровня угроз. Кроме того, валидаторы иногда расходятся в показаниях, и надо смотреть конфиги своего сервера: действительно ли это трудно обнаруживаемая при тестах дыра, или у кого-то глюки?
                      Да, SSL Labs — это Qualys, неплохой валидатор, но не единственный.
                          0
                          Ну не знаю, не знаю… согласно internet.nl/site/www.ifap.ru/1127259 у нас не отдается HSTS ;)
                            0

                            Создатели этого теста супер-параноики (моему сайту снижена оценка до 97% только за использование early_data (0-RTT) ).


                            Они считают что https://IP уже должен HSTS отдавать — а у Вас не отдаёт.


                            :)

                              0
                              Думаете, в этом дело? Т.е. они так неявно требуют нестандартной директивы preload в заголовке?
                    0
                    Судя по KB, да.
                  +1
                  Добавлю, что для голой Win7 sp1 перед установкой KB3042058 необходимо установить в начале KB4474419-v3, затем KB4490628 и только после этого поставится KB3042058.
                  0
                  По поводу браузера для Windows XP — есть Otter Browser.
                    0
                    Есть много чего, что использует не schannel, а свои, более продвинутые криптобиблиотеки.
                    0
                    Даже если браузер не поддерживает протокол, не проблема сделать прокси, который будет подключаться к серверу с любым современным протоколом, а браузеру отдавать хоть голый http.
                      0
                      Только не для рядового пользователя, которому проще «помочь» на стороне сервера.
                        0
                        А вот какой на данный момент локальный рабочий прокси под Windows есть?
                        Это на самом деле актуально для устройств на андроид относительно старых.
                          0
                          Сходу конкретных программ не назову, но вообще локальных проксей полно, для разных задач. Скажем, Squid часто используется. Да и nginx можно как проксю использовать. Всякие рекламорезки нередко как прокси реализованы. Я себе для одного сайта вообще набросал на Перле скриптик, который получает https и по http передаёт эти данные через Proxomitron в браузер (некоторую рекламу так проще оказалось резать). Сам Proxomitron, кстати, это тоже прокси, но с https он не дружит.
                          0

                          Ну вот старенький киндл, ещё с кнопочками и whispernet на борту. Раньше можно было ходить в википедию. Теперь ходить он по-прежнему может, но вот открывать — уже нет. А с левым прокси проблема прямо противоположная — может и сможет открыть, но сходить не сможет.
                          Пат!

                            0
                            Тут всё зависит от функций и возможностей Киндла. В большинстве случаев можно всё-таки как-то извернуться (другой вопрос, будет ли потраченное время стоить результата). Скажем, если используется подключение через домашний роутер, или если на самом Киндле можно настроить произвольный DNS-сервер, то можно будет подменять DNS-ответ, чтобы запросы на Википедию перенаправлялись на другую машину, где поднят веб-сервер, перебрасывающий запросы на реальный сайт. А если речь о браузере, в котором можно ввести произвольный адрес, то можно поднять сервис, который будет не обычной проксёй, а «обёрткой» (не знаю, как правильно называется такой тип). Скажем, сервис живёт на 192.168.1.15, мы вводим урл 192.168.1.15/en.wikipedia.org/wiki/Proxy, сервис вычленяет из урла адрес en.wikipedia.org/wiki/Proxy, скачивает страницу по этому адресу и отдаёт её браузеру. В общем, примерно как веб-архив, только он-то из своего хранилища берёт, а тут к исходному сайту подключение выполняется. Но этот подход не со всеми сайтами будет работать. Ведь там придётся парсить страницу и подменять все абсолютные ссылки, иначе они будут указывать не туда. А на некоторых сайтах эти ссылки генерируются скриптами, и до них так просто не доберёшься…
                              +1

                              Через домашний роутер я и сам могу ).
                              Речь про whispernet, который даёт всемирный бесплатный доступ через 3G, но только к киндл-стору и википедии. И имеет на борту "экспериментальный браузер" на webkit. Сейчас по факту доступ есть, но открыть он ничего не может. А к любым сайтам-"помогайкам" наоборот, доступа нет.

                          +3

                          Спасибо, очень актуальная статья ) не хватает только конкретных конфигов для nginx.

                          0

                          Так и быть, делюсь своим набором, и актуально и A+ будет


                          ssl_protocols TLSv1.2;
                          ssl_prefer_server_ciphers on;
                          ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;


                          add_header Strict-Transport-Security max-age=15768000;

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

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