Transport layer security какие браузеры поддерживают
Для работы через систему доступа 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 5Live 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.
Понятно, что обновление одного из важнейших протоколов затронет множество сайтов и займёт долгое время, но в итоге интернет станет безопаснее.
Читайте также: