Transport layer security какие браузеры поддерживают

Обновлено: 07.07.2024

Для работы через систему доступа SSLGOST необходимо иметь на компьютере:

  • Сертифицированную программу-криптопровайдер
  • Браузер, поддерживающий шифрование по ГОСТ

Сертифицированные программы-криптопровайдеры (CSP)

    (подойдет и бесплатная версия — по лицензионному соглашению программы (пункт 8.с) ей можно пользоваться и после истечения демонстрационного периода без покупки и ввода ключа) (бесплатная). После установки ее необходимо зарегистрировать согласно инструкции. Позволяет также проверять и создавать запрос на электронную подпись.

Если одна из этих программ у вас уже установлена, просто перепроверьте ее версию по таблице совместимости и обновите на более новую, если это необходимо.

Требования к компьютеру для установки программ-криптопровайдеров

  • Процессор — Intel Core 2 Duo или другой схожий по производительности x86-совместимый процессор с количеством ядер 2 и более.
  • Объем оперативной памяти — не менее 512 Мбайт.
  • Свободное место на жестком диске — не менее 100 Мбайт.

Браузеры, поддерживающие шифрование по ГОСТ

К сожалению, не все браузеры поддерживают шифрование по ГОСТ. Выбирать следует из этих:

  • Internet Explorer 8 (и выше) — Edge из Windows 10 не подойдет (оба этих браузера обычно есть в Windows 10) - подойдет корпоративная версия, работает только с КриптоПРО
    • Внимание! С Яндекс Браузером не работает СЭД и СЭД Тезис

    Также пользователи сообщали о поддержке браузером Спутник (редакция "С поддержкой отечественного шифрования" - скачивается по ссылке "Другие варианты загрузки"), но нами она не тестировалась.

    Таблица совместимости

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

    Зеленым отмечены рекомендуемые пары для каждой из операционных систем. КриптоПРО выбирается только по причине того, что не требует регистрации, а Internet Explorer — потому, что есть везде.


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

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

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

    Кто виноват – вопрос отдельного исследования, нас же интересует что делать? Давайте для начала вспомним, что к устойчивым шифронаборам сегодня относятся не только рекомендуемая АНБ комбинация 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 сертификатом необходимо поддерживать два шифронабора:

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

    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.

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

    Чтоб два раза не вставать, рассмотрим кратко и ситуацию с эллиптическими кривыми. 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 соответственно.

    Отечественные браузеры и поддержка шифрования TLS по ГОСТ 34.10-2012¶

    Выбираем и настраиваем отечественный браузер с поддержкой шифрования TLS по ГОСТ 34.10-2012 (далее просто «ГОСТ»):

    Пояснения по пунктам:

    • Чтобы работало шифрование TLS по ГОСТ 34.10-2012 и электронная подпись, необходимо установить КриптоПро CSP. Рекомендуется последняя сертифицированная версия. Для работы с информационными системами Тюменской области и картами ЭП УЦ ЦИТТО рекомендуется установить пакет ИГУС (ИГУС уже содержит в себе КриптоПро, плагины, корневые сертификаты, драйверы кардридеров).
    • Отечественные браузеры, входящие в реестр отечественного ПО, сделаны на основе Chromium (как и Google Chrome).
    • Mozilla Firefox, Chromium, Google Chrome, Opera, Vivaldi, SeaMonkey не поддерживают TLS по ГОСТ.
    • Если использование именно отечественного браузера не обязательно, то можно использовать Chromium-GOST.
      [зеркало][версия для WinXP]
      Выбирайте версию, соответствующую вашей OS — 32-разрядную (386) или 64-разрядную.
    • Для поддержки шифрования TLS по ГОСТ в Яндекс.Браузере нужно зайти в настройки и включить соответствующую опцию.
    • Проверить корректность настройки рабочего места для TLS по ГОСТ можно на тестовой странице
      (может пригодиться неофициальный способ настройки для многопользовательской среды) + необходимое расширение для Firefox
      Подробнее о настройке браузеров для работы с электронной подписью и ЕСИА см. в отдельной обновляемой инструкции
    • Установка браузеров в OS Linux в общих случаях может производиться из репозитория конкретного дистрибутива Linux (без скачивания с сайта бинарного пакета или архива с исходным кодом).

    Поддержка Adobe Flash¶

    Поддержка Flash выпилена из Windows и современных браузеров, так как технология объявлена устаревшей. Однако иногда Flash может понадобиться. В ряде случаев может помочь Ruffle, но удобнее воспользоваться портативным браузером.

    1. Скачиваем портативный вариант браузера Pale Moon (проверялось на версии 29)
    2. Распаковываем Pale Moon
    3. Скачиваем NPSWF64 32.0.0.371 (файл в архиве имеет подпись Adobe)
    4. Файл из архива копируем в подпапку /Lib/Mozilla/Plugins в папке Pale Moon
    5. Запускаем браузер и проверяем работу нужных сайтов, требующих Adobe Flash



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

    Стандарту 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

    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 года.

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

    Протокол обмена ключами 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.


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

    Например, выяснилось, что 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, приватные ключи для которых легко подделываются в течение четырёх часов.


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

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

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

    Читайте также: