Как настроить тлс в яндекс браузере

Обновлено: 05.01.2025

С такой ошибкой к нам обратился клиент. Подключение идет с ПК Windows 7, на борту КриптоПро и Яндекс.Браузер. Последний — в списке рекомендуемых . Но что-то мешает.

Описание ошибки

Как правило, в таких случаях следует проверить стандартный, не всеми любимый Internet Explorer. Открыли, но также быстро закрыли — версия устарела (требуется 11.0.9600.xxxxx или выше). Вариант отпадает.

Конечно же, сделали попытку обновления IE, но получили еще больше предупреждений — мол, не хватает нескольких обязательных обновлений WIndows. Получается процесс затяжного и неустойчивого характера — отложили идею, поставив на полку до лучших времен.

Проверили ключ, сертификат и формирование подписи на тестовой странице — ошибок нет.

Chromium-GOST

Для тех, кто любит быстрые решения. Нас выручил специализированный Chromium-GOST , в который встроены алгоритмы шифрования ГОСТ.

На нем все запустилось, и мы сразу попали в личный кабинет ЮЛ.

Прочие рекомендации

1. Условия доступа

Еще раз ознакомьтесь с требованиями на странице выполнения условий доступа. Во время проверки сервис дает подсказки, на каком этапе есть ошибки. Позовите на помощь знакомого ИТ-специалиста.

2. Яндекс.Браузер

• обновите версию браузера до актуальной (Меню « Дополнительно — О браузере » или скачайте инсталлятор с официального сайта );

• в настройках активируйте опцию «Подключаться к сайтам, использующим шифрование по ГОСТ» (меню « Настройки — Системные — Сеть »);

Подключаться к сайтам, использующим шифрование по ГОСТ. Требуется КриптоПро CSP. Подключаться к сайтам, использующим шифрование по ГОСТ. Требуется КриптоПро CSP.

• на вкладке «Настройки TLS» для КриптоПро CSP снимите галку « Не использовать устаревшие cipher suite-ы ».

3. Версии протоколов

Для теста включите в настройках браузера поддержку старых версий протоколов SSL/TLS.

Например, для IE — TLS 1.0, TLS 1.1 и TLS 1.2, а также SSL 2.0 и 3.0.
Пуск — Выполнить — inetcpl.cpl — вкладка «Дополнительно»

4. Очистка кэша SSL

Если вы работаете с несколькими учетными записями (сертификатами), при каждой смене пользователя необходимо очистить SSL ( Настройки — Свойства браузера — вкладка «Содержание» — Очистить SSL ).

Пуск — Выполнить — inetcpl.cpl — вкладка «Содержание»

5. Прямая ссылка на ЛК

6. Запуск браузера без расширений/другие браузеры

Отключите в настройках браузера дополнительные расширения, чтобы исключить их влияние на работу с порталом ФНС.

Протестируйте работу в другом браузере из списка поддерживаемых:

• Яндекс.Браузер версии 19.3 или выше;
• Спутник версии 4.1.2583.0 (Официальная сборка) или выше, gostssl (32 бит);
• Internet Explorer версии 11.0.9600.xxxxx или выше;
• Chromium-GOST.

7. Настройка антивируса/брандмауэра

Задача — отключение опции SSL-сканирования («SSL scan»). Либо настройте исключения для площадок ФНС.

8. Проверка времени и даты

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

9. Другие средства защиты

Одновременная и корректная работа с разными криптопровайдерами (VipNet CSP, Континент-АП, Агава и др.) на одном ПК не гарантируется. Если установлены прочие СКЗИ — удалите их или перейдите на другое рабочее место.

✅ В настройке подключения есть свои тонкости и набор средств. Поэтому, каждый случай надо рассматривать отдельно. Универсального решения нет, проверьте рекомендации — что-то должно помочь. Успехов вам!

⚡ Подписывайтесь на канал или задавайте вопрос на сайте — постараемся помочь всеми техническими силами. Безопасной и производительной работы в Windows и 1С.

Яндекс.Браузер использует протоколы TLS, которые обеспечивают защищенную передачу данных в интернете. Передаваемые по безопасному соединению данные шифруются и расшифровываются с использованием утилиты КриптоПро CSP.

Ограничение. В настоящее время данная функциональность доступна только в Windows.

Установка «КриптоПро CSP»

По требованиям российского законодательства признается только использование TLS-соединений, установленных по российским криптографическим алгоритмам ГОСТ 28147-89, ГОСТ Р 34.10-94, ГОСТ Р 34.11-94 и ГОСТ Р 34.10-2012. Поэтому, если вам требуется использование сайтов, использующих шифрование по ГОСТ алгоритмам, необходимо установить программу «КриптоПро CSP» .

В операционных системах Windows используется программа КриптоПро CSP — набор криптографических утилит для генерации электронной подписи, работы с сертификатами.

Для установки КриптоПро CSP воспользуйтесь материалами с официального сайта:

После установки КриптоПро CSP браузер проверяет наличие и работоспособность этой программы.

Сайты, запрашивающие шифрование ГОСТ TLS

Если сайт запрашивает шифрование ГОСТ TLS, браузер проверяет, установлена ли программа КриптоПро CSP. Если программа установлена, ей передается управление.

Если сайта нет в списке, то запрашивается дополнительное подтверждение. Если вы доверяете сайту и соединение должно быть произведено с использованием шифрования ГОСТ TLS, нажмите кнопку Продолжить .

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

Включение и отключение поддержки КриптоПро CSP браузером

По умолчанию в браузере включена поддержка КриптоПро CSP. Рекомендуем убедиться в этом:

Убедитесь, что в блоке Сеть включена опция Подключаться к сайтам, использующим шифрование по ГОСТ. Требуется КриптоПро CSP .

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

Настройки и инструкции

Включить протокол безопасности в Yandex Browser

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

Тип подключения может быть следующим:

Защита включена. Сайты, на которые система «разрешит» переходить, безопасны для ввода личных данных, совершения платежей.

Удалить данные о SSL

Все сертификаты Yandex Browser автоматически сохраняются на локальном диске компьютера – со временем их накопится достаточно, что может привести к замедленной работе поисковой системы или снижению объёма свободной оперативной памяти.

Способ 1: удалить SSL через браузер

Через сам браузер можно удалить все данные о SSL, которые сохранились в памяти. Данный способ позволит ускорить работу Яндекс и предотвратит возникновение ошибок при проверке сертификатов безопасности на других страницах.

Как очистить SSL в Яндекс браузере:

Для восстановления грамотной работы может потребоваться перезапуск браузера.

Способ 2: удалить выборочные данные о SSL

Yandex Browser также предоставляет возможность вручную удалить данные об определённых протоколах безопасности. Сделать это можно следующим образом:

Перезагрузите браузер, чтобы изменения вступили в силу.

Способ 3: удалить данные о SSL вручную

Отключение проверки протоколов безопасности

Отключить в браузере проверку сертификатов возможно, но делать это рекомендуется только в случае, если вы доверяете источнику свою платёжную информацию, личные данные. Рассмотрим два варианта, как обойти проверку протокола безопасности страницы в Yandex Browser.

Способ 1: правильно установить время на компьютере

Как правильно установить время на компьютере:

Способ 2: вручную подтвердить переход на непроверенный сайт

Если дата и время на вашем устройстве настроены верно и вы доверяете странице, на которую планируете перейти:

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

Настроить сертификат по ГОСТ

Загрузить КриптоПро по ссылке.

Как включить настройку SSL в Яндекс браузере:

Отключить работу сертификата можно аналогичным образом.

Я занимаюсь в Яндексе продуктовой безопасностью и, кажется, сейчас самое время подробнее, чем уже было на YaC, рассказать на Хабре о том, как мы внедряем TLS.

Терминация

1. Использовать один из множества сторонних сервисов — Amazon ELB, Cloudflare, Akamai и других. Основным недостатком данного метода будет необходимость защиты каналов между сторонним сервисом и вашими серверами. Скорее всего, это все равно потребует развертывания поддержки TLS в том или ином виде. Большим недостатком также будет полная зависимость от провайдера услуг в плане поддержки необходимой функциональности, скорости исправления уязвимостей Отдельной проблемой может стать необходимость раскрытия сертификатов. Несмотря на это, данный способ будет хорошим решением для стартапов или компаний, использующих PaaS.
2. Для компаний, использующих собственное «железо» и свои дата-центры, возможной опцией будет Hardware load balancer с функциями TLS-терминации. Единственное достоинство здесь — производительность. Выбирая такое решение, вы попадаете в полную зависимость от вашего вендора, а так как зачастую внутри продуктов используются одни и те же аппаратные компоненты, то еще и от производителей чипов. Как следствие сроки добавления любых фич далеки от идеала. Потенциальные таможенные сложности со ввозом подобных продуктов оставим за пределами данного материала.
3. Программные решения — «золотая середина». Существующие opensource решения — Nginx, Haproxy, Bud и т.п. — дают вам почти полный контроль над ситуацией, добавлением фич, оптимизациями. Минусом является производительность — она ниже, чем у аппаратных решений.

Унификация

Исторически в разное время наши сервисы использовали различное ПО web-серверов, поэтому, чтобы все унифицировать, мы решили отказаться от большинства решений в пользу Nginx, а там где отказаться нельзя — «спрятать» их за Nginx. Исключением в данном случае стал поиск, который использует собственную разработку под названием — внезапно — Balancer.

Балансер умеет делать множество вещей, которые не умеют другие, даже коммерческие решения. Однажды, думаю, ребята расскажут об этом подробнее. Имея талантливую команду разработчиков, мы можем себе позволить поддерживать один собственный web server в дополнение к Nginx.

Что касается непосредственно криптографии, то мы используем библиотеку OpenSSL. На сегодняшний день это самая стабильная и производительная реализация TLS с адекватной лицензией. Важно использовать OpenSSL версии 1+, так как в ней оптимизирована работа с памятью, есть поддержка всех необходимых современных шифров и протоколов. Все наши дальнейшие рекомендации будут ориентированы на пользователей веб-сервера Nginx.

Сертификаты

Для проверки действительности сертификата браузер пытается проверить валидность цифровой подписи для конечного сертификата, а затем для каждого из промежуточным удостоверяющих центров. Сертификат последнего в цепочке из удостоверяющих центров должен быть подписан так называемым Корневым Удостоверяющим Центром (Root CA).

Сертификаты корневых удостоверяющих центров хранятся в операционной системе, либо браузере пользователя (например, в Firefox). При настройке веб-сервера важно отправлять клиенту не только сертификат сервера, но и все промежуточные. Корневой сертификат при этом отправлять не нужно — он уже есть в OС.

Большие компании могут позволить себе иметь собственные Intermediate CA. Например, до 2012 года все сертификаты Яндекса подписывались YandexExternalCA. Использование собственного Intermediate CA дает как дополнительные возможности по оптимизации и пиннингу сертификатов, так и накладывает дополнительную ответственность, так как позволяет выписать сертификат практически для любого конечного доменного имени, а в случае компрометации может привести к серьезным последствиям, вплоть до отзыва сертификата промежуточного CA.

Поддержка собственного CA может быть слишком дорогим и сложным процессом, поэтому некоторые компании используют их в режиме MPKI — Managed PKI. Большинству потребителей же будет достаточно покупки сертификатов с использованием одного из коммерческих поставщиков.

1. Алгоритм цифровой подписи и используемая хеш-функция;
2. Тип сертификата.

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

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

К сожалению, Windows XP < SP3 и некоторые браузеры, доля которых среди клиентов больших сайтов отлична от нуля, не поддерживают ECC-сертификатов.

1. MD5 — сегодня считается небезопасным и не используется;
2. SHA-1 — использовался для подписывания большинства сертификатов до 2014 года, сейчас признан небезопасным;
3. SHA-256 — алгоритм, который уже сегодня пришел на замену SHA-1 ;
4. SHA-512 — на сегодняшний день используется довольно редко, поэтому мы не будем на нем останавливаться.

Все серверные конечные сертификаты, используемые для TLS, можно условно разделить по способу валидации — Extended Validated и прочие (чаще всего Domain Validated).

Технически в extended validated сертификат добавляются дополнительные поля с признаком EV и часто с адресом компании. Наличие EV сертификата подразумевает юридическую проверку существования владельца сертификата, в то время как сертификаты типа Domain Validated подтверждают лишь то, что владелец сертификата действительно контролирует доменное имя.

Кроме того, что появляется красивая зеленая плашка, признак EV-сертификата также влияет на поведение браузеров, связанное с проверкой их статусов отозванности. Так даже браузеры семейства Chromium, которые не используют ни OCSP, ни CRL, а полагаются только на Google CRLsets, для EV проверяют статус с помощью протокола OCSP. Ниже я расскажу об особенностях работы этих протоколов подробнее.

Теперь, когда мы разобрались с сертификатами, нужно понять, какие версии протоколов будут использоваться. Как мы все помним, протоколы версий SSLv2 и SSLv3 содержат фундаментальные уязвимости. Поэтому, их необходимо отключить. Почти все клиенты сейчас имеют поддержку TLS 1.0. Мы рекомендуем использовать TLS версий 1.1 и 1.2.

В случае, если у вас есть значительное число клиентов использующих SSLv3, в качестве компенсационной меры можно разрешить использовать его только с алгоритмом RC4 — на переходный период мы сделали именно так. Однако если у вас не такое количество пользователей со старыми браузерами, как у нас, рекомендую совсем отключить SSLv3. Правильная конфигурация для Nginx в части протоколов будет выглядеть так:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Что касается выбора ciphersuites или наборов шифров и хеш-функций, которые будут использоваться для TLS-соединений, — веб-серверы должны использовать только безопасные шифры. Здесь важно соблюсти баланс между безопасностью, скоростью, производительностью и совместимостью.

Security vs. Perfomance

Различные браузеры по-разному проверяют статусы сертификатов. Так Firefox использует только OCSP для обычных сертификатов, но для EV проверяется и CRL. IE и Opera проверяют и CRL, и OCSP, а Яндекс.Браузер и другие браузеры семейства Chromium не используют традиционных протоколов, полагаясь на CRLsets — списки отозванных сертификатов популярных ресурсов, которые поставляются вместе с обновлениями браузера.

Для оптимизации проверок также был придуман механизм под называнием OCSP stapling, который позволяет передать клиенту ответ OCSP responder'а в виде TLS extension вместе с сертификатом. Все современные десктопные браузеры поддерживают OCSP stapling (кроме Safari).

Включить OCSP stapling в nginx можно следующей директивой: ssl_stapling on; . При этом обязательно указать resolver.

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

При использовании OCSP stapling'а массовые ресурсы могут столкнуться с такой проблемой, как неправильное время на клиентской системе. Происходит это из-за того, что по стандарту время жизни ответа responder'а ограниченно четко заданным временным интервалом, а время на клиентской машине может отставать на 5-10-20 минут. Чтобы решить эту проблему для пользователей, нам пришлось научить сервера раздавать ответы спустя примерно сутки после их генерации (примерно то же самое мы делаем при выкладке новых сертификатов).

Другим эффективным способом оптимизации проверок является использование короткоживущих сертификатов, то есть таких, в которых не заданы точки проверки статуса. Но период жизни таких сертификатов очень небольшой — от одного до трех месяцев.

Использовать такие сертификаты могут себе позволить Удостоверяющие центра. Почти всегда они используются для OCSP responder'ов, так как при наличии точек проверки статуса в сертификате может заставить Internet Explorer проверить еще и статус сертификата самого OCSP responder'а, что создаст дополнительные задержки.
Но даже при использовании OCSP stapling'а или короткоживущих сертификатов, стандартный TLS хендшейк (4 этапа) добавит 2 RTT задержки.

• Сервер анонсирует NPN/ALPN (не требуется для Safari и IE);
• Сервер использует Perfect Forward Secrecy ciphersuites.

Perfect Forward Secrecy

До SSLv3 атакующий, получивший доступ к приватному ключу сервера, мог пассивно расшифровать все коммуникации, которые прошли через сервер. Позднее был придуман механизм Forward Secrecy(иногда используют приставку Perfect), который использует протоколы согласования ключей (обычно на основе схемы Diffie-Hellman'а и гарантирует, что сессионные ключи не могут быть восстановлены, даже если атакующий получит доступ к приватному ключу сервера.

Типичная конфигурация nginx для сервиса работающего c пользовательскими данными, выглядит так:

В данной конфигурации мы ставим максимальный приоритет AES со 128 битным сессионным ключом, который формируется по алогоритму Elliptic Curve Diffie Hellman (ECDH). Далее идут любые другие шифры с ECDH. Вторая «E» в аббревиатуре обозначает Ephemeral, т.е. сессионный ключ, существующий в пределах одного соединения.
Далее разрешаем использовать обычный Diffie Hellman (EDH). Здесь важно отметить, что использование Diffie Hellman с размером ключа 2048 бит, может быть довольно затратным.

Эта часть конфига обеспечивает нам поддержку PFS. Если вы используете процессоры с поддержкой AES-NI, то AES будет для вас бесплатным, с точки зрения ресурсов. Отключаем 3DES, разрешаем AES128 в не-PFS режиме. Оставляем 3DES и EDH и 3DES в CBC режиме для совместимости с совсем старыми клиентами. Отключаем небезопасный RC4 и прочее. При этом важно использовать самые новые версии OpenSSL, тогда «AES128» развернется в том числе в AEAD шифры.

У PFS есть единственный недостаток — performance penalties. Современные веб-сервера (в том числе Nginx) используют event-driven модель. При этом ассиметричная криптография — чаще всего блокирующая операция, так как процесс веб-сервера блокируется, а обслуживаемые им клиенты страдают. Что мы можем оптимизировать в этом месте?

SSL session cache. Данный механизм строится на том, что на каждое соединение клиенту отдается уникальный идентификатор, а на сервере по данному идентификатору сохраняется сессионный ключ. Плюсом является поддержка почти всех, в том числе старых, браузеров. Минусом — необходимость синхронизации кешей, содержащих критичные данные, между физическими серверами и дата-центрами, что может приводить к проблемам безопасности.

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

В nginx конфигурация будет выглядеть примерно так, где SOME_UNIQ_CACHE_NAME это имя кеша, которое рекомендуется использовать различные идентификаторы для различных сертификатов (не обязательно в nginx 1.7.5+, 1.6.2+), 128Mb — размер кеша, 28 часов — время жизни сессии.
ssl_session_cache shared:SOME_UNIQ_CACHE_NAME:128m;

В Nginx поддержка статических ключей для session tickets добавлена в версиях 1.5.8+. Настройка tls session tickets при работе с несколькими серверами делается следующим образом:

В данном случае current.key — ключ, который используется в настоящий момент времени. Prev.key — ключ, используемый N часов до начала использования current.key. Prevprev.key — ключ, используемый N часов до начала использования prev.key. Значение N должно быть равно указанному в ssl_session_timeout. Мы рекомендуем исходить из интервала в 28 часов.

В Яндексе есть специальные механизмы для генерации и безопасной доставки ключей на конечные сервера.

Приложения

Secure Cookies

Параметр max-age задает период (1 год), в течение котого должен использоваться защищенный протокол. Опциональный флаг includeSubdomains говорит о том, что на все поддомены данного домена также можно ходить только через зашифрованные соединения.

Для того чтобы пользователи браузеров семейства Chromium и Firefox всегда использовали защищенные соединения, даже при первом обращении, можно добавить ваш ресурс в HSTS preload list браузера. Кроме того, что это обеспечит безопасность, это также сэкономит один редирект при первом обращении.

Например, Яндекс.Паспорт добавлен в preload list браузеров.

Заключение

Целиком конфигурация одного сервера nginx будет выглядеть примерно следующим образом:

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

  
• Файл не существует либо у вас нет достаточных прав доступа либо файл занят другой программой
  
• Ddst driver что это
  
• Ворд наименование организации при сохранении документов
  
• Как сдать отчетность в фсс через 1с
  
• 1с полекомпоновкиданных как получить имя