Transport layer security какие браузеры поддерживают
Очень много вопросов по этой теме. Оно и понятно: информации мало, противоречивых интерпретаций много. Для нас тема защиты соединений с сайтами близка. Мы пишем на Хабре об этом уже лет восемь. Например, в своё время мы первыми поддержали DNSCrypt прямо в браузере, первыми начали предупреждать о неизвестных корневых сертификатах в системе, первыми включили шифрование трафика для незащищенных Wi-Fi-сетей.
Поэтому сегодня мы расскажем сообществу о происходящем чуть более подробно. Тем, кто очень спешит и хочет получить короткие ответы, достаточно прочитать начало поста. Поехали.
Коротко о главном
Подробнее о проблеме
Как вы можете знать, ряд российских сайтов уже столкнулись с отзывом выданных TLS-сертификатов. Напомню, что наличие действующего авторитетного сертификата жизненно важно для любого сайта, который работает с данными пользователей. Без сертификата невозможно удостовериться, что данные передаются именно тому сайту, который указан в адресной строке браузера, а не подделке злоумышленников. Как следствие, любой современный браузер не пускает пользователей на сайт, если его сертификат отозван (это нормальное, ожидаемое поведение).
Проблема в том, что российским сайтам всё сложнее получить такой сертификат. Удостоверяющие центры всё чаще отзывают ранее выданные сертификаты и отказывают в их выдаче. Да, сайты могут начать использовать самоподписанные сертификаты. Но к ним нет и не будет никакого доверия со стороны браузеров из-за отсутствия контроля в их выдаче и применении. А значит, проблема с доступом к сайтам никуда не денется.
К чему это может привести? Вот несколько вариантов:
Описание текущего решения
Есть альтернативная инициатива — создать национальные удостоверяющие центры (НУЦ) и поддержать их корневые сертификаты в браузерах. НУЦ смогут выдавать сертификаты тем (и только тем!) сайтам, которые к ним обратятся. Наличие альтернативы позволит не допустить ситуации, при которой пользователи лишатся доступа к онлайн-сервисам.
Первый такой НУЦ уже появился — на базе Госуслуг. Сейчас он работает так:
Наши планы
Текущее решение, конечно же, требует развития. Основной способ завоевания доверия к центру сертификации — это открытость. И здесь мы планируем несколько вещей.
Прежде всего, хотим организовать рассылку уведомлений в Яндекс Вебмастере тем владельцам сайтов, для которых зафиксирован выпуск сертификатов.
Наша более глобальная инициатива — поддержать стандарт Certificate Transparency (CT) и поднять публичный лог, в который НУЦ будет записывать выпущенные сертификаты. Если посещаемого пользователем сайта не будет в этом логе, то браузер выдаст ошибку ERR_CERTIFICATE_TRANSPARENCY_REQUIRED и не даст его открыть.
Мы хотим, чтобы наш Браузер проверял сертификаты не по одному, а по нескольким независимым друг от друга публичным логам, поэтому призываем других участников рынка присоединиться к инициативе и поднять дополнительные логи по стандарту CT.
Большая просьба: если вы знаете, как сделать лучше, — приходите, советуйте. Хотите покритиковать решения — критикуйте и предлагайте улучшения.
P. S. Пока оформлял этот пост, прилетела новость: центр сертификации DigiCert, обслуживающий около 50 тыс. российских сайтов, ограничил им выдачу сертификатов.
Мы - сообщество специалистов по организации государственных закупок и участию в тендерах. «Общественный портал госзакупок» - достоверный источник нормативно-правовой информации в сфере госзаказа и место, где всегда можно посоветоваться с коллегами.
С какого браузера посещать ЛК ЕИС в 2022 году
Работа на ЭТП - регистрация, аккредитация, взаимодействие. Организация и проведение закупок на аккредитованных торговых площадках по 44-ФЗ и участие в них
С какого браузера посещать ЛК ЕИС в 2022 году
KarinaKatz » 24 янв 2022, 18:45
Вечер добрый, коллеги!
Столкнулась с такой ситуацией, что на январь 2022 года нет ни одного рабочего браузера для посещения личного кабинета ЕИС.
Интернет експлорер моя винда уже не поддерживает, пользовалась до сегодняшнего дня Спутником, он теперь тоже не рабочий, разрекламированный Хромиум-ГОСТ и Яндекс браузер для закупок, тоже не работают, постоянно выдает ошибку
"На сайте eruz.zakupki.gov.ru используется неподдерживаемый протокол.
Протокол не поддерживается. Клиент и сервер используют разные версии протокола SSL или разные наборы шифров.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH"
пробовала сама настроить браузеры с помощью советов "мамкиных программистов", пришлось вообще все сносить и заново переустанавливать.
проставка галочек в свойствах браузера не помогает, все равно сайт ЕИС исправно выдает ошибку.
NhelzuF » 25 янв 2022, 00:58
KarinaKatz писал(а): Вечер добрый, коллеги!
Столкнулась с такой ситуацией, что на январь 2022 года нет ни одного рабочего браузера для посещения личного кабинета ЕИС.
Интернет експлорер моя винда уже не поддерживает, пользовалась до сегодняшнего дня Спутником, он теперь тоже не рабочий , разрекламированный Хромиум-ГОСТ и Яндекс браузер для закупок, тоже не работают, постоянно выдает ошибку
"На сайте eruz.zakupki.gov.ru используется неподдерживаемый протокол.
Протокол не поддерживается. Клиент и сервер используют разные версии протокола SSL или разные наборы шифров.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH"
пробовала сама настроить браузеры с помощью советов "мамкиных программистов", пришлось вообще все сносить и заново переустанавливать.
проставка галочек в свойствах браузера не помогает, все равно сайт ЕИС исправно выдает ошибку.
Глава » 25 янв 2022, 05:09
Вообще-то закупки и госуслуги более менее работают на експлоере (мать его. ). Может, лучше на компе винду установить, работающую на експлоере?
tumbb » 25 янв 2022, 16:02
https://zakupki.gov.ru/epz/main/public/ . qual=false
тут есть файл "Инструкция по настройке рабочего места" там на сей момент найдёте:
Яндекс - Яндекс
Windows - Установленный Интернет-браузер: Internet Explorer (версии 11.0), либо любой другой браузер, поддерживающий Transport Layer Security (TLS v. 1.0/1.2, RFC 5246), с использованием российских криптографических стандартов; ПО КриптоПро версии 4.0.
Linux - Chromium-gost
shtirlits » 26 янв 2022, 15:03
Сержик » 02 фев 2022, 20:40
Действительно, есть грабли.
Автоматически устанавливается c обновлением Win 10 переадресатор на Edge. Это специальное расширение браузера IE, которое автоматически открывает Edge, если вы запускаете IE. Естественно, как знает каждый участвующий в торгах, Edge не поддерживает TLS 1.2 на ГОСТ
Это "творчество" майкросовтовцев можно отключить
Прямая ссылка на настройки в браузере Edge:
edge://settings/defaultbrowser
Выставить параметр "Разрешить Internet Explorer открывать сайты в Microsoft Edge" в значение "Выключено",
либо настройку "Разрешить сайтам загрузку в режиме Internet Explorer" в "Включено".
Может чутка по разному выглядеть и быть переведено, но вы вчитайтесь и всё получится.
Или "Гуглить в Яндексе" по фразе "отключить IEtoEdge BHO". Так назвается это самое расширение для IE.
P.S. запускать IE, как и прежде набив в поиске около "Пуска": "Internet Explorer". Нажать правой кнопкой и закрепить в панели задач.
Texnik » 10 мар 2022, 20:24
Вопрос очень актуален!, куплены 2 компьютера с лицензионной виндовс , сразу же 11 версией , все что здесь предлагается пробовал, сайт тупо не открывается, уверен что нужна до настройка , как ie11, но таких параметров нету там кроме, как запустить c поддержкой ie- этого мало. самое обидное , что распиареный спутник! потух! Причина тому, что ему для работы нужно чтобы был ie, по другому объяснить его нерабочее состояние, не могу. Изучая форумы и прочее вывод похоже один - это установка win10, но у меня лицензия на 11 электронная в биосе, как она заработает в 10 вопрос, . наверное никак, тупик вообщем.
Eugene_2017 » 12 апр 2022, 14:50
Texnik писал(а): Вопрос очень актуален!, куплены 2 компьютера с лицензионной виндовс , сразу же 11 версией , все что здесь предлагается пробовал, сайт тупо не открывается, уверен что нужна до настройка , как ie11, но таких параметров нету там кроме, как запустить c поддержкой ie- этого мало. самое обидное , что распиареный спутник! потух! Причина тому, что ему для работы нужно чтобы был ie, по другому объяснить его нерабочее состояние, не могу. Изучая форумы и прочее вывод похоже один - это установка win10, но у меня лицензия на 11 электронная в биосе, как она заработает в 10 вопрос, . наверное никак, тупик вообщем.
ann_q » 12 апр 2022, 18:12
Не могу зарегистрировать новую организацию поставщика в личном кабинете. Вылезает ошибка
Не удалось выполнить операцию. Проверьте настройку рабочего места и повторите операцию.
Дополнительные сведения об ошибке:
Cannot read properties of undefined (reading 'CreateObjectAsync')
Что делать? Плагины все установлены, захожу через Яндекс.
Eugene_2017 » 13 апр 2022, 10:26
ann_q писал(а): Не могу зарегистрировать новую организацию поставщика в личном кабинете. Вылезает ошибка
Не удалось выполнить операцию. Проверьте настройку рабочего места и повторите операцию.
Дополнительные сведения об ошибке:
Cannot read properties of undefined (reading 'CreateObjectAsync')
Что делать? Плагины все установлены, захожу через Яндекс.
ДД
Как вариант, обновите Крипто-про ЭЦП плагин.
И. как через "тЫндекс" работаете. У меня он ни в какую не хочет с ЕИС "дружить".
Отечественные браузеры и поддержка шифрования 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 по ГОСТ можно на тестовой странице
По опыту — Яндекс.Браузер не очень корректно работает с 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
Тему подсказало обсуждение предыдущего поста, в котором прозвучал голос заботливого администратора веб-сервера: 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 соответственно.
В августе 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.
Понятно, что обновление одного из важнейших протоколов затронет множество сайтов и займёт долгое время, но в итоге интернет станет безопаснее.
Читайте также: