Браузеры отказываются от поддержки TLS 1.0 и 1.1


    В августе 2018 года IETF утвердил стандарт TLS 1.3

    TLS 1.0 и TLS 1.1 скоро фактически прекратят своё существование. Уже сейчас телеметрия Firefox показывает, что эти протоколы составляют ничтожную долю HTTPS-трафика: 1,11% и 0,09%, соответственно. Подавляющее большинство сайтов сейчас используют TLS 1.2. А в 2019−2020 годы все ведущие браузеры намерены полностью отказаться от поддержки TLS 1.0 и TLS 1.1. На серверной стороне рекомендуется отключить эти протоколы уже сейчас.

    Почему отключают TLS 1.0 и 1.1


    Стандарту TLS 1.0 в январе будущего года исполняется 20 лет. Он выполнил свою роль: за эти годы протокол зашифровал миллиарды, если не триллионы соединений. Со временем стало лучше понятно, как следует проектировать протоколы шифрования. Выросли требования к надёжности шифров. К сожалению, TLS 1.0 и 1.1 не соответствуют этим требованиям.

    В TLS 1.0 и 1.1 есть некоторые аспекты, которые внушают опасения, пишет Mozilla Security Blog. Самое плохое, что они не поддерживают работу с современными криптографическими алгоритмами. Например, при рукопожатии обязательно требуют использования алгоритма хэширования SHA-1. В этих версиях TLS невозможно установить более сильный алгоритм хэширования для подписей ServerKeyExchange или CertificateVerify. Поэтому единственный выход — обновление на новую версию TLS.

    14 сентября 2018 года Internet Engineering Task Force (IETF) опубликовала черновик официального документа, в котором не рекомендует использовать TLS 1.0 и 1.1. В числе прочего там упоминается, что SHA-1 с криптостойкостью 2^77 нельзя считать безопасным по современным меркам: «2^77 операций [для атаки] — это ниже допустимой границы безопасности».


    Фрагмент документа IETF об отказе от старых версий TLS

    В документе приводится более подробная техническая информация о причинах такого решения. Там говорится об атаке BEAST (Browser Exploit Against SSL/TLS) на TLS 1.0, а именно — на блочные шифры, где в качестве вектора инициализации для сообщения n используется последний блок шифрования предыдущего сообщения (n-1).

    TLS 1.1 выводится из обращения вместе с TLS 1.0, потому что он кардинально не отличается и имеет по сути те же недостатки. В этой версии исправили лишь некоторые ограничения TLS 1.0, которых можно избежать иными способами (речь опять идёт об атаке BEAST).

    Согласно рекомендациям NIST, веб-сервисам предлагалось до июля 2018 года удалить поддержку старых версий TLS. Это сделали Amazon, CloudFlare, GitHub, KeyCDN, PayPal и многие другие веб-сервисы.

    Сроки отключения


    Разработчики всех ведущих браузеров согласились выполнить рекомендации IETF.

    Браузер Chrome первым откажется от поддержки старых версий TLS. Разработчики планируют начать процесс с версии Chrome 72, которая выйдет в январе 2019 года: с этого момента для сайтов с устаревшими протоколами будет выводиться предупреждение в консоли DevTools. Полное отключение состоится в версии Chrome 81, которая запланирована к выходу в марте 2020 года (предварительные версии — с января 2020 года).

    Microsoft обещает отключить протоколы «в первой половине 2020 года». Mozilla объявила, что отключит TLS 1.0 и 1.1 в Firefox в марте 2020 года. Apple планирует удалить поддержку из браузеров Safari в марте 2020 года.

    Пресс-релизы от разработчиков всех ведущих браузеров вышли очень скоординированно:


    Современный профиль TLS 1.2


    Согласно рекомендации IETF, минимальной криптографической базой для HTTPS-соединений должен быть TLS 1.2. По данным телеметрии Firefox, сейчас он составляет 93,12% HTTPS-трафика (94% по данным Qualys), так что де-факто рекомендации выполняются уже сегодня.


    Использование версий TLS для всех HTTPS-соединений в Firefox Beta 62, данные телеметрии за август-сентябрь 2018 года

    TLS 1.2 является необходимым условием для работы HTTP/2, который повышает производительность сайтов. Mozilla рекомендует использовать на серверной стороне современный профиль TLS 1.2, если нет каких-то специализированных потребностей. Современный профиль обеспечивает высокий уровень безопасности и включает в себя следующие параметры:

    • Наборы шифров: 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
    • Эллиптические кривые для TLS: prime256v1, secp384r1, secp521r1
    • Тип сертификата: ECDSA
    • Эллиптические кривые для сертификата: prime256v1, secp384r1, secp521r1
    • Подпись сертификата: sha256WithRSAEncryption, ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512
    • Размер ключа RSA: 2048 (если нет ECDSA)
    • Размер DH Parameter: Нет (полностью отключен)
    • Размер ECDH Parameter: 256
    • HSTS: max-age=15768000
    • Переключение сертификатов: Нет

    Специалисты отмечают, что сейчас немногие удостоверяющие центры поддерживают ECDSA-подписи, поэтому в рекомендациях разрешены RSA-подписи для ECDSA-сертификатов.

    Протокол обмена ключами DHE полностью удалён из набора шифров, потому что он медленнее ECDHE, а все современные клиенты поддерживают эллиптические кривые.

    Алгоритм подписи SHA1 тоже полностью удалён из набора: вместо него используются SHA384 для AES256 и SHA256 для AES128.

    Эта конфигурация поддерживается с версий Firefox 27, Chrome 30, IE 11 на Windows 7, Edge, Opera 17, Safari 9, Android 5.0 и Java 8. Если нужна поддержка более старых браузеров, то требования к набору шифров придётся снизить до «среднего» уровня, он же установлен как уровень по умолчанию. Только в самом крайнем случае советуют опускаться до обратно совместимого набора шифров с поддержкой Windows XP/IE6.

    К сожалению, сегодня далеко не все вендоры соблюдают рекомендации по безопасной настройке TLS 1.2.

    24 сентября 2018 года на arXiv.org было опубликовано академическое исследование этой проблемы, выполненное исследователями из Университета Конкордиа в Монреале (Канада). Авторы проанализировали поведение 17 версий 13 сетевых TLS-инструментов разного класса (бесплатных, с открытым кодом, низко- и высокоуровневых).



    Выводы неутешительные: уязвимыми оказались почти все рассматривавшиеся продукты:

    Например, выяснилось, что WebTitan, UserGate и Comodo не выполняют валидацию TLS. Comodo и Endian по умолчанию считают всё сертификаты проверенными, а Cacheguard принимает самостоятельно подписанные сертификаты TLS.

    Trend Micro, McAfee и Cacheguard используют предварительно сгенерированные пары ключей (хотя документация McAfee и утверждает обратное). Четыре устройства — от UserGate, WebTitan, Microsoft и Comodo — принимают собственные сертификаты для контента, доставляемого извне. Частные ключи хранятся на устройстве и их можно легко извлечь, используя другие уязвимости.

    Атака BEAST позволяет получить аутентификационные файлы куки пользователей TLS-средств от Microsoft, Cisco и TrendMicro, а клиенты Sophos, Cacheguard, OpenSense, Comodo и Endian принимают сертификаты RSA-512, приватные ключи для которых легко подделываются в течение четырёх часов.



    Будущее за TLS 1.3


    В августе 2018 года IETF утвердил стандарт TLS 1.3, о котором подробно рассказывали на Хабре. Основные нововведения в новой версии:

    • новый протокол рукопожатия: процесс проходит в два раза быстрее за счёт объединения нескольких шагов, механизм рукопожатия стал более безопасным, так как разработчики удалили все алгоритмы, которые не используют AEAD-режимы блочного шифрования;
    • новый процесс выработки ключа с использованием HMAC-функции Extract-and-Expand Key Derivation Function (HKDF);
    • удаление шифронаборов, использующих RSA или обмен ключами DH, режим CBC и SHA-1.

    Сейчас версию 1.3 в предварительном варианте поддерживают Chrome и Firefox. Согласно телеметрии, браузер Firefox сейчас устанавливает больше соединений по TLS 1.3, чем по TLS 1.0 и 1.1.

    Понятно, что обновление одного из важнейших протоколов затронет множество сайтов и займёт долгое время, но в итоге интернет станет безопаснее.





    GlobalSign
    Company

    Comments 24

      0
      Теперь на свежую XP SP3 уже и файрфокс не поставишь… Печально.
        0
        Ну уже с пол года как было сообщение в самом браузере, что в xp/win2k3 поддержка ff прекращается.
          +1
          Понятное дело, но мне не обновлять его надо, а запускать, причем не очень важно, насколько древний — для особо противных железок 3.6.28 вполне себе подходит, а если надо серфить, можно взять 42LTS (или сколько он там был), но вообще в этом случае правильнее поставить ОС поновее.
          +3
          А зачем вообще ставить XP??? Не троллинг, реально интересно.
            +1
            Запускать старые игры, которые писались под 98ю. Imperialism, например. Ещё как вариант — поддержка какого-ниудь легаси ПО вроде старой-престарой учетной системы. Был, помнится, такой ИНФИН, вообще досовая штуковина по факту. Хотя со временем и это всё помрет, и тогда уже не понадобится ставить ХР.

            Но игры будет жалко :)
              +1
              Старое сетевое железо например. Весь Avocent имеет афигенную совместимость с новыми версиями жабы и браузеров. И если жаба правится уничтожением безопасности на корню, то с браузерами косяки вылезают.
            +2
            Почему кто-то за меня решает, какими стандартами я не должен пользоваться?

            Добавьте новые протоколы, но оставьте поддержку старых. Если уж совсем неймётся («мы очень беспокоимся о безопасности пользователя», ага) — ну сделайте настройку:
            «Блокировать сайты с TLS1.0/TLS1.1» — on/off (default «on», так и быть).

            Но выпиливать-то зачем?! А если у меня в офисе какой-нибудь видео-регистратор с веб-мордой на TLS1.1, ну или там мини-АТС Panasonic — я больше не смогу их настраивать?

            Когда я чувствую на себе такую форсированную «заботу», у меня автоматически появляются смутные сомнения в её благожелательности…
              0
              Почему ты просто не пользоваться той версией где это есть?
                +3
                Через некоторое время эта версия отовсюду исчезнет, и привет.
                Я вот уже столкнулся с таким, не могу на убунте по VPN связаться с одним древним сервером. Там используется какой-то старый шифр, который из всех линуксовых впн клиентов выпилен. В итоге в 14 убунте оно работало, хоть и с плясками (надо было какие-то дополнительные deprecated пакеты ставить) а в 16 уже перестало вообще. И что делать, если я не хочу пользоваться древней версией ОС?
                  +2
                  Загрузите в Docker старинную Убунту и в ней старинный VPN клиент. Оттуда подключитесь. Дальше в зависимости от ваших нужд либо в тот же контейнер поставьте проксю, и ходите через неё, либо используйте его как gateway.
                +1
                Наверняка так и сделают — скрытую настройку, запрятанную глубоко, но т.к. раз есть настройка, то её можно и включить, это затянет проблему и её решение.
                Простой абстрактный пример из головы: предположим, TLS1.0 взломали полностью, с потрохами. Вы коннектитесь к сайту и ради поддержки старых протоколов и браузер и сервер поддерживают TLS1.0, человек по середине, перехватывает запросы и понижает уровень безопасности до TLS1.0, всё, приехали.

                А для древних вещей всегда же можно использовать специально выделенные виртуалки, древние версии браузеров, и прочие костыли. Плохо — да, очень. Но современный мир такой.
                  +7
                  потому что Сеть — это коммуналка. если один сосед не моется — вши потом у всех.
                    +1
                    А кто сказал, что в TLS 1.0 и 1.1 есть «вши»? Сами алгоритмы ни разу не были скомпрометированы, а баги в библиотеках, которые были обнаружены, все закрыты.

                    На OpenNet недавно наоборот заметили, что когда наконец за 10 лет в библиотеках с реализацией TLS1.0/1.1 вычистили баги и вылизали код, так сразу кому-то приспичило менять стандарты и проталкивать новые (весьма витиеватые) реализации, в которых ещё неизвестно сколько дыр будет найдено.
                      +1
                      вычистили баги и вылизали код
                      Сами алгоритмы ни разу не были скомпрометированы, а баги в библиотеках

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


                      https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/

                  +1
                  Эллиптические кривые для TLS: prime256v1, secp384r1, secp521r1
                  Тип сертификата: ECDSA
                  Эллиптические кривые для сертификата: prime256v1, secp384r1, secp521r1
                  Подпись сертификата: sha256WithRSAEncryption, ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512
                  Размер ключа RSA: 2048 (если нет ECDSA)
                  Размер DH Parameter: Нет (полностью отключен)
                  Размер ECDH Parameter: 256

                  Было бы хорошо написать мануал «как настроить apache и nginx на работу по этим рекомендациям».

                  А то и Хабр, и вообще инет набит советами «как», только там по традиции dh-параметры длиной 2048 (особые маньяки, не очень задумываясь о последствиях для клиентов, пишут в своих текстах про 4096 и выше), а вот про «размер ECDH Parameter» вообще никто не пишет.

                  Про prime256v1 тоже поискать нужно, а если и встретится, то видно, что автор сам не знает, что к чему.

                  В общем — ликбез бы не помешал, вместе с инструкцией «делай минимум и нормально так»! Тем более, можно сказать, в блоге такой компании сам Бог велел такое написать.

                  Да, Mozilla SSL Configuration Generator, похоже, про упомянутые изыски не очень в курсе, похоже, это от ненужности таких точных настроек?
                    0
                    вообще-то это в точности перезказ упомянутого Mozilla SSL Configuration Generator в позиции «Modern».
                      0
                      Мне на Modern для nginx 1.15.5 и свежей openssl выдается несколько другое:
                      вот такое
                      server {
                          listen 80 default_server;
                          listen [::]:80 default_server;
                      
                          # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
                          return 301 https://$host$request_uri;
                      }
                      
                      server {
                          listen 443 ssl http2;
                          listen [::]:443 ssl http2;
                      
                          # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
                          ssl_certificate /path/to/signed_cert_plus_intermediates;
                          ssl_certificate_key /path/to/private_key;
                          ssl_session_timeout 1d;
                          ssl_session_cache shared:SSL:50m;
                          ssl_session_tickets off;
                      
                      
                          # modern configuration. tweak to your needs.
                          ssl_protocols TLSv1.2;
                          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';
                          ssl_prefer_server_ciphers on;
                      
                          # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
                          add_header Strict-Transport-Security max-age=15768000;
                      
                          # OCSP Stapling ---
                          # fetch OCSP records from URL in ssl_certificate and cache them
                          ssl_stapling on;
                          ssl_stapling_verify on;
                      
                          ## verify chain of trust of OCSP response using Root CA and Intermediate certs
                          ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
                      
                          resolver <IP DNS resolver>;
                      
                          ....
                      }


                      Ничего по поводу
                      Эллиптические кривые для TLS: prime256v1, secp384r1, secp521r1

                      Размер DH Parameter: Нет (полностью отключен)
                      Размер ECDH Parameter: 256

                      Я что-то не вижу.
                    0
                    Меня вот больше всего беспокоит попытка уничтожить RSA и DHE.

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

                    Во-вторых, в отличии от DHE, где можно использовать самостоятельно сгенерированное основание, в ECHDE только из заранее заложенных. А про них есть слухи что они не надёжны. Плюс возникает угроза различных атак на основание (по смыслу подобным радужным таблицам).
                      +1

                      Позвольте я уточню. Вместо того, чтоб опираться на мнение специалистов в области безопасности, которые несколько лет разрабатывали новый стандарт, используя весь современный опыт, вы доверяете каким-то слухам. На мой взгляд это контрпродуктивный подход.


                      Кастомный DHE не только медленный. Не все в мире являются специалистами в области безопасности. Самостоятельно настраивая эти параметры неспециалисты могут подвергнуть себя опасности, используя небезопасные параметры. Самые современные кривые ed25519 и ed448 уже достаточно безопасны.


                      Если вы беспокоитесь о квантовых компьютерах, то как только они появятся, они всю современную криптографию превратят в тыкву. Так что тут дело не только в rsa. К тому же я думаю, что разработчики скорее всего думают об устройствах IoT, в которых важно энергопотребление при сопоставимой безопасности.

                        +1
                        Вместо того, чтоб опираться на мнение специалистов в области безопасности

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

                        несколько лет разрабатывали новый стандарт, используя весь современный опыт

                        Уже были случаи с слабыми генераторами случайных чисел и т.п. Проблема не в том что им не хватает знаний, а в том, что спец службы очень не хотят чтобы криптография была сильной.

                        Кастомный DHE не только медленный.

                        Ну и что? Зачастую безопасность ценнее. Я же не требую убрать ECDHE, пусть будет. А вот принудительный запрет обычного это уже очень не приятно. Я бы понял если бы он был не безопасен, но только из-за скорости…

                        Самостоятельно настраивая эти параметры неспециалисты могут подвергнуть себя опасности

                        Хм… а какие там параметры? Размер основания и всё. Ну там вы его генерируете с помощью OpenSSL в 99% случаев. Сам аглоритм генерации тоже простой (говорю, т.к. реализовывал его сам) и проверить результаты его работы не так уж и сложно.

                        С размером основания достаточно рекомендаций по размеру (а так даже дилетанту понятно что чем больше тем надёжнее).

                        P.S. У меня работал сайт на DHE с основанием 8192 бита. И никаких проблем с ним не было (хотя конечно скоростью он не блистал).

                        Самые современные кривые ed25519 и ed448 уже достаточно безопасны.

                        Что значит достаточно? Они или безопасны или нет. И простых алгоритмов их проверки на эту самую безопасность я пока не встречал. Кроме того это не отменяет проблемы одного основания (пароли весь солят не просто так, правда?).

                        Если вы беспокоитесь о квантовых компьютерах, то как только они появятся, они всю современную криптографию превратят в тыкву.

                        Они уже есть. Вот только кол-во кубитов наращивать получается плохо. Если я не путаю то ed25519 станет тыквой при 1536 кубитах, а RSA 8192 при 16384 кубитах. Даже если взять 4096, это всё ещё 8192 кубита. А ведь при угрозе таких компьютеров остаются ещё 16 и 32Кбита. Да они медленные, но это меры которые можно принять немедленно.

                        Собственно поэтому меня и настораживает попытка выдавливания. Не появления новых, а именно принудительного уничтожения старых.

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

                        Ну так на нём и пусть используют. Зачем везде то удалять?
                          0

                          Мне кажется, что вы ищете теорию заговоров там, где её нет.


                          Ответы на ваши вопросы уже даны в новых RFC, черновиках. В конце концов, вы можете поискать обсуждение участников комитета на форуме https://datatracker.ietf.org/wg/tls/about/, посмотреть материалы встреч. Ну или даже просто задать им вопрос по почте, уверен, они могут ответить.

                      0
                      TLS 1.2 является необходимым условием для работы HTTP/2, который повышает производительность сайтов. Mozilla рекомендует использовать на серверной стороне современный профиль TLS 1.2, если нет каких-то специализированных потребностей. Современный профиль обеспечивает высокий уровень безопасности и включает в себя следующие параметры:

                      Наборы шифров: 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
                      Эллиптические кривые для TLS: prime256v1, secp384r1, secp521r1
                      Тип сертификата: ECDSA
                      Эллиптические кривые для сертификата: prime256v1, secp384r1, secp521r1
                      Подпись сертификата: sha256WithRSAEncryption, ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512

                      А где же российские алгоритмы, шифрсьюты?

                        +1
                        а они кого-то интересуют?

                      Only users with full accounts can post comments. Log in, please.