Рекомендации по использованию протокола tls с .net framework

Сертификат и конверсия

Современные требования к защите данных настолько строги, что браузеры буквально приучили пользователей негативно реагировать на сайты без сертификата. Пользователя пугает уведомление и связанные с ним риски — едва ли он посетит подобный сайт. Если протокол TLS установить корректно, то браузер не только уберет страшное уведомление, но еще и подсветит адресную строку зеленым. Посетители приучены доверять таким сайтам, ведь за доверием стоит TLS-технология, обеспечивающая безопасность обмена данными.
Особенно важен сертификат для сайтов, на которых необходимо указывать приватную информацию: пароли, коды, данные платежных систем. Сайт, имеющий сертификат, будет качественнее индексироваться поисковыми системами, в отличие от своего не сертифицированного собрата.

Уже купили виртуальный хостинг для сайта? Не забудьте о домене и сертификате TLS

Если только еще подумываете покупать сертификат – обращайте внимание на стандарты шифрования, которыми пользуется компания, предоставляющая защищенный канал связи

Краткие рекомендации

Включите через групповую политику протоколы TLS 1.1 и 1.2 для всех клиентов и серверов в домене.
Обязательно отключите SSL 2.0 на всех клиентах и серверах.
Обязательно отключите SSL 3.0 на всех серверах, используемых для внутренних сервисов (DC, порталы, CA, всё подобное).
Осторожно отключите SSL 3.0 и TLS 1.0 на всех клиентах, проверив, все ли требуемые для работы внешние сервисы будут доступны в этом случае.
Включите на всех клиентах и серверах пересогласование TLS.
Включите его (пересогласования) строгое соответствие RFC 5746 – не имеет смысла устанавливать “высокотехнологичный” TLS последней модели, и при этом не брать во внимание well-known security hole.

Более жесткое закручивание гаек – по вкусу.

Кто еще отказался от старых TLS

По данным ресурса Ars Technica, отказаться от TLS 1.0 и 1.1 в I квартале 2020 г. вместе с Microsoft планировали Google, Apple и Mozilla.

Apple отключила поддержку TLS 1.0 и 1.1 штатном интернет-ПО в iOS 13.4 и macOS 10.15.4 (обе вышли 24 марта 2020 г., а 11 марта 2020 г. Mozilla выпустила браузер Firefox 74, тоже с отключенной по умолчанию поддержкой этих протоколов. В конце марта 2020 г. она снова включила ее, мотивировав это тем, что правительственные сайты с информацией о коронавирусе, доступ к которым может потребоваться пользователям во время пандемии, могут не поддерживать TLS 1.2 и 1.3.

BEAST: как работает атака на SSL 2.0/3.0 и TLS 1.0

Эта достаточно нашумевшая атака (ну, благодаря прессе, у неё статус “Конец Интернета Почти Вот-Вот”), на самом деле, устроена достаточно просто.
Суть в том, что во всех протоколах до TLS 1.1 вместо генерации нового случайного IV (для каждого нового TLS message), использовался последний блок предыдущего TLS message. BEAST пользуется этим, чтобы значительно упростить процесс атаки на ключ – в частности, получив доступ к сессии, он может значительно упростить себе процедуру перебора сессионного ключа, влияя на состав нового вектора инициализации. В TLS 1.1 халтурить перестали, поэтому данная атака там просто не работает.

Если попробовать рамочно описать алгоритм атаки, можно это сделать так.

• Пользователь инициирует SSL-сессию к ресурсу (например, к веб-серверу). В этой сессии он постоянно передаёт какой-то элемент (например, жмёт на кнопку Like). Ну т.е. сессия одна, а он ходит по сайтам и делает что-то, что сопровождается хотя бы частично совпадающим обменом данными.
• Например, предположим, что согласовался протокол AES-128 (заметьте – стойкость самого протокола не критична, я его выбрал просто для удобного примера). Его блок будет равняться 128 / 8 = 16 байт.
• Атакующий участвует в обмене трафиком так, что может добавлять свои данные перед данными пользователя. Вариантов много – например, доп.заголовок в HTTP, или модификация исходных данных на уровне источника. Суть в том, чтобы атакующий мог добавить свои данные так, чтобы получился блок “Добавленные_данные_известные_атакующему + нормальные_данные_неизвестные_атакующему”. Т.е. исходное в атаке – это MITM. Если вы думаете, что условий дофига и это всё малореально, просто представьте себе обычного пользователя, который игнорирует антивирус, потому как, к примеру, верит рекламе “В нашей ОС нет вирусов, т.к. у неё красивые скруглённые уголочки да и цена намекает, что качество ну просто обязано быть”, который хочет в онлайне что-нибудь оплатить по карте и видит успокаивающую надпись “Protected by SSL 2.0/3.0 128bit cipher”.
• Атакующий начинает работать. Он вкидывает такие блоки данных в поток, чтобы последним получился блок, у которого 15 байт – добавленные данные, а единственный оставшийся – секретные. После пробует тестово расшифровывать этот блок перебором – перебирать-то интересно, т.к. из 16 байт 15 известны. А подбор 2^8 – это уже очень перспективно, учитывая, что в случае выигрыша можно будет вскрыть всю сессию (ведь никто не мешает впрок отправлять куда-нибудь полный дамп сессии, а после, в случае успеха метода, расшифровать всё целиком).
• Вскрыли 1 байт? Теперь будем подгадывать так, чтобы наших байт в блоке было 14, плюс один известный, плюс один пока что неизвестный

Как SSL/TLS влияет на продвижение

Для Google безопасность всегда среди главных приоритетов: поисковик учитывает наличие HTTPS при ранжировании с 2014 года и постоянно обновляет требования к SSL-/TLS-сертификатам. Яндекс тоже делает акцент на безопасности, признавая HTTPS знаком качества сайта и предупреждая пользователей о некорректном сертификате. 

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

Информация о безопасности подключения в Chrome

Хоть преимущества технологии SSL/TLS довольно очевидны, многие сайты до сих пор не перешли на HTTPS или же используют недостаточно надежные версии протоколов. Статистика 2019 года говорит о том, что не используют безопасный протокол, а по данным на начало 2020 года, только 18% доменных имен в зоне .ru используют узлы HTTPS.

Многие владельцы сайтов не хотят заморачиваться с покупкой и обновлением SSL-/TLS-сертификата или считают, что он им не нужен, если ресурс не собирает пользовательские данные. Но в современных реалиях ваш сайт будет попросту терять клиентов и позиции в поиске, если вы не перейдете на HTTPS и не будете следить за актуальностью шифрования. Для вашего удобства существует множество инструментов для настройки и мониторинга SSL-/TLS-сертификатов, в том числе бесплатные, как Let’s Encrypt.

Ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера

В процессе активации сертификата можно столкнуться с ошибкой «Invalid CSR». Такая ошибка возникает по следующим причинам:

• Неправильное имя FQDN (полное имя домена) в качестве Common Name (в некоторых панелях управления это поле может также называться Host Name или Domain Name). В этом поле должно быть указано полное доменное имя вида domain.com или subdomain.domain.com (для субдоменов). Имя домена указывается без https://. В качестве данного значения нельзя использовать интранет-имена (text.local). В запросе для wildcard-сертификатов доменное имя необходимо указывать как *.domain.com.
• В CSR или пароле есть не латинские буквы и цифры. В CSR поддерживаются только латинские буквы и цифры – спецсимволы использовать запрещено. Это правило распространяется и на пароли для пары CSR/RSA: они не должны содержать спецсимволов.
• Неверно указан код страны. Код страны должен быть двухбуквенным ISO 3166-1 кодом (к примеру, RU, US и т.д.). Он указывается в виде двух заглавных букв.
• В управляющей строке не хватает символов. CSR-запрос должен начинаться с управляющей строки ——BEGIN CERTIFICATE REQUEST—— и заканчиваться управляющей строкой ——END CERTIFICATE REQUEST——. С каждой стороны этих строк должно быть по 5 дефисов.
• В конце или начале строки CSR есть пробелы. Пробелы на концах строк в CSR не допускаются.
• Длина ключа меньше 2048 бит. Длина ключа должна быть не менее 2048 бит.
• В CRS-коде для сертификата для одного доменного имени есть SAN-имя. В CSR-коде для сертификата, предназначенного защитить одно доменное имя, не должно быть SAN (Subject Alternative Names). SAN-имена указываются для мультидоменных (UCC) сертификатов.
• При перевыпуске или продлении сертификата изменилось поле Common Name. Это поле не должно меняться.

Закручиваем гайки: Включаем безопасное пересогласование TLS на Windows-системе

К стандартам семейства TLS есть интересные дополнительные механизмы, не вошедшие в основные спецификации. Данные механизмы известны гораздо меньше, чем что-то вида “ну ё, TLS же новый, SSL старый, значит включаешь TLS и безопаснее становится”, но не в моих правилах подходить к вопросу с такой стороны.

Безопасное пересогласование TLS описывается в стандарте RFC 5746 и решает проблему безопасности, которая возникает в случае работы классического TLS 1.2, который по RFC 5246.

По сути, Windows-хост может работать в плане этого RFC в двух режимах – в режиме совместимости (т.е. допускать и небезопасное, “классическое” пересогласование TLS 1.2), и в “безопасном”, допуская только пересогласование в новом формате. По умолчанию, работа идёт в режиме совместимости. Это не всегда полезно, поэтому надо знать, как включать только безопасное пересогласование TLS 1.2.

Включаем поддержку TLS Renegotiation Indication Extension

Мы будем работать с ключом реестра

В нём будет необходимо создать следующие ключи: , , , , . Все – обычные DWORD 32. Теперь подробнее про каждый.

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

Обратите внимание – это серверная настройка; т.е. она анализируется, когда какой-либо сервис на этом хосте “слушает” входящие подключения по TLS

Например, IIS. Если хотите, чтобы можно было подключаться всем – поставьте единицу, если только “умным” клиентам, поддерживающим RFC 5746 – то нуль.

Примечание: Патч, который добавляет поддержку этого механизма, вышел в августе 2010 года. То есть, если у Вас XP или выше, и на ней установлены обновления, то поддержка есть.

Параметр будет обозначать, можно ли будет с этого хоста подключаться к серверам, которые не поддерживают механизм безопасного пересогласования. Если параметр равен нулю – клиенты будут прерывать фазу согласования TLS, если сервер ведёт себя некорректно. Если хотите, чтобы можно было подключаться к любым TLS-серверам, вне зависимости от реализации на них поддержки RFC 5746 – поставьте единицу.

Параметр заслуживает отдельного обсуждения. Дело в том, что в RFC 5746 указывается, что данное расширение необходимо упаковывать в сообщение “ClientHello” протокола TLS. Но это может быть причиной проблем, потому что некоторые сервера – заметьте, именно сервера, т.е. это клиентская настройка – которые не поддерживают данный стандарт, не просто не смогут переключиться на новый механизм, а просто не смогут обработать этот неизвестный им подвид сообщения ClientHello. Это, например, Vista без SP. Чтобы подстраховаться от ситуации, когда “новый” клиент посылает “новый вариант” ClientHello и серверная сторона рвёт связь, надо установить этот параметр в единицу. В этом случае клиент просто отправит т.н. “Signaling Cipher Suite Value” (как раз SCSV). Ставьте этот параметр только в случае, когда Вам реально нужно подключаться к системе, которая “сбрасывает” сессию после ClientHello.

Можно и масштабнее. Если параметры выше описывали варианты поведения при пересогласовании TLS, то следующие будут включать-выключать поддержку пересогласования как такового.

Если параметр есть и не равен нулю, то клиент со своей стороны не будет пробовать проводить пересогласование TLS (например, периодически) и не будет отвечать на запросы пересогласования (будет не рвать сессию, а именно игнорировать). Если же параметр равен нулю (или отсутствует), то всё ОК – клиент будет поддерживать пересогласование и пробовать делать его сам.

Если параметр есть и не равен нулю, то сервер со своей стороны не будет пробовать проводить пересогласование TLS и не будет отвечать на запросы пересогласования (тоже будет не рвать сессию, а именно игнорировать). Если же параметр равен нулю (или отсутствует), сервер будет поддерживать пересогласование и пробовать делать его сам.

Включенный экспериментальный протокол QUIC

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

Показываем как отключить QUIC на примере браузера Google Chrome:

• Откройте браузер и введите команду chrome://flags/#enable-quic;
• В появившемся окне будет выделен параметр: Experimental QUIC protocol (Экспериментальный протокол QUIC). Под названием этого параметра вы увидите выпадающее меню, в котором нужно выбрать опцию: Disable.

Этот способ работает и в Windows и в Mac OS.

Краткая история вопроса – SSL

• Обязательность подтверждения подлинности сервером
• Опциональная проверка подлинности клиента
• Совместная генерация случайного сеансового ключа
• Поддержка различных симметричных алгоритмов для шифрования данных
• Поддержка различных алгоритмов хэширования для реализации проверки целостности через MAC

Первая версия SSL не особо показывалась публике, отсчёт рабочих версий можно начинать с SSL 2.0 (1995й год). Эта версия была первой, которая эксплуатировалась в production, и достаточно оперативно она была доработана до SSL 3.0. Заметим, что хотя это произошло достаточно давно – в 1996 году – стандарт от этого не стал общим и открытым; он оставался стандартом, разработанным конкретной фирмой Netscape, и для его использования в ряде случаев нужна была лицензия. Опубликован IETF он был совсем недавно, в августе; RFC 6101 описывает то, что 15 лет уже стандарт де-факто для защиты сессий множества приложений. Но по сути, с ним уже давно пора прощаться; TLS существует годы (с 1999, если быть точнее), а достаточно безопасная на данный момент версия 1.1 – с 2006 года. Пора, пора.

Защита популярных приложений

Ниже будет описано, как отключить протокол SSLv3 в наиболее популярных серверных приложениях. Но для начала необходимо самостоятельно оценить свой сервер, чтобы защитить все дополнительные сервисы, которые поддерживают шифрование SSL/TCP.

Поскольку уязвимость POODLE является внутренним недостатком самого протокола, а не проблемой его использования, обходных путей нет, единственное надежное решение – не использовать его.

Защита веб-сервера Nginx

Чтобы отключить поддержку SSLv3 на веб-сервере Nginx, используйте директиву ssl_protocols, которая находится в блоке настроек server или http.

К примеру, в Ubuntu можно либо внести ее глобально в блок http файла /etc/nginx/nginx.conf, либо добавить ее в каждый блок server в каталоге /etc/nginx/sites-enabled.

Чтобы отключить SSLv3, нужно задать директиву ssl_protocols следующим образом:

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

Защита веб-сервера Apache

Для защиты Apache от POODLE нужно отредактировать параметр SSLProtocol модуля mod_ssl.

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

В Ubuntu настройки сервера можно изменить в файле /etc/apache2/mods-available/ssl.conf. Если mod_ssl включен, символическая ссылка соединит этот файл с подкаталогом mods-enabled:

В CentOS конфигурационный файл SSL (если SSL включен) находится в:

В данном файле найдите параметр SSLProtocol. Если такого параметра в файле нет, создайте его. Теперь отключите поддержку SSLv3, удалив этот протокол из строки:

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

В Ubuntu наберите:

В CentOS:

Защита балансировщика нагрузки HAProxy

Чтобы отключить поддержку SSLv3 в балансировщике HAProxy, откройте файл haproxy.cfg, который находится в /etc/haproxy/haproxy.cfg:

Обратите внимание на настройки фронт-энда: если SSL включен, параметр bind будет указывать IP-адрес и порт. Чтобы отключить SSLv3, нужно внести в конец этой строки no-sslv3:. Сохраните и закройте файл

Сохраните и закройте файл.

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

Защита сервера OpenVPN

Последние версии OpenVPN не поддерживают SSLv3. Следовательно, данный сервис не подвержен этой конкретной уязвимости, потому редактировать настройки нет необходимости.

Защита SMTP-сервера Postfix

Для настройки шифрования на сервере Postfix используется праметр smtpd_tls_mandatory_protocols. Его можно найти в главном конфигурационном файле:

Чтобы Postfix постоянно использовал шифрование, установите следующий параметр, который отключит поддержку SSLv3 и SSLv2. Если же вы не используете  шифрование, никаких изменений вносить не нужно.

Сохраните новые настройки и перезапустите сервис, чтобы активировать их:

IMAP и POP3 сервер Dovecot

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

В большинстве дистрибутивов этот параметр можно найти в файле:

При использовании Dovecot 2.1+ отключите поддержку SSLv2 и SSLv3 при помощи параметра ssl_protocols:

При использовании более старых версий Dovecot (ниже 2.1) отключить SSLv3 можно при помощи параметра ssl_cipher_list так:

Сохраните и закройте файл.

Перезапустите сервис, чтобы обновить настройки.

Параметры безопасности

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

• Конфиденциальность. Пользуясь симметричными алгоритмами, протокол TLS шифрует данные, которые передаются. Если данные окажутся перехваченными, прочесть их будет невозможно.
• Аутентификация. Гарантия, что обмен данными идет между теми узлами, для которых изначально создавался канал связи.
• Контроль целостности. Односторонним хэшированием проверяется входящая информация, исключая возможность подмены или искажения.

При использовании протокола веб-браузером поддерживаются параметры, способные обеспечить высшую степень безопасности. Статистика протокола TLS дает следующие данные:

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

Оглавление

• Краткая история вопроса – SSL
• Версии и преимущества TLS
  • Про TLS 1.0
  • Про TLS 1.1
  • Про TLS 1.2
  • Про TLS 1.2 и Windows XP SP3
  • Про TLS 1.2 и Windows 2003 SP2
• BEAST: как работает атака на SSL 2.0/3.0 и TLS 1.0
• Включаем TLS на Windows-системе
• Отключаем SSL на Windows-системе
• Закручиваем гайки: Включаем безопасное пересогласование TLS на Windows-системе
• Атака на SSL/TLS – THC-SSL-DOS
• Закручиваем гайки: настройки криптоалгоритмов на хосте
• Управляем настройками согласования SSL/TLS в браузерах
• Проверяем работу TLS 1.1 и 1.2
• Что делать, если у меня нет возможности включить TLS новых версий

Приступим.

Преимущества и недостатки протокола TLS

Еще в 1999 году, когда в SSL обнаружили уязвимости, было очевидно, что необходим обновленный протокол защиты данных. Это обстоятельство задало курс и тенденцию протоколу TLS. В 2014 POODLE успешно атаковал SSL 3.0, не оставив протоколу малейшего шанса. Что уж говорить о ранних версиях SSL.

Осенью 2014 Бодо Мёллер и его коллеги из Google Security Team обнаружили уязвимость в архитектуре протокола SSL 3.0. Атака POODLE подменяет пользовательские данные, и байт за байтом расшифровывает содержимое защищенного канала. Не существует способа обойти кодовую уязвимость, единственное логичное решение — блокировка использования протокола SSL 3.0 на всех рабочих системах.

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

Протокол TLS имеет ряд концептуальных отличий от SSL-протокола:

• В TLS используются другие ключи и увеличенный набор шифров.
• Улучшены стандарты формирования ключа на основе пароля.
• Есть различия в хэшировании HMAC, которое выполняет функцию создания блока симметричных ключей.
• Введены алгоритмы, увеличивающие безопасность канала.

Начинающие веб-разработчики сталкиваются с непростым вопросом: какой протокол выбрать? Для специалиста со стажем выбор очевиден – настройка протокола TLS идентична SSL, при этом безопасность шифрования на несколько порядков выше. Более того, специалисты по безопасности Google настоятельно рекомендуют не использовать SSL-протокол, отдавая предпочтение TLS.

Тем не менее, огромное количество пользователей ошибочно называют TLS «SSL-шифрованием». Откуда пошла путаница: поставщики сертификатов и веб-браузеры «застряли» в термине, который давно и плотно укоренился.

Знайте: когда вам предлагают «SSL-шифрование» — подразумевают TLS.

Протокол обеспечивает безопасность различных каналов связи: веб-трафик, электронную почту, систему телеконференций. Если в адресной строке виднеется шифровальная магия, имя которой  — в вашем браузере устанавливается соединение по протоколу TLS.

Управляем настройками согласования SSL/TLS в браузерах

Internet Explorer

Если Вы дочитали до этого места и всё поняли, но не знаете, как включить TLS в IE, то это, по сути, уникальная ситуация. Но тем не менее. Для включения поддержки TLS старших версий необходимо зайти в меню Internet Options -> Advanced, там в списке промотать до раздела Security и сделать соответствующие изменения (как минимум отключить SSL 2.0 и включить TLS 1.1 и TLS 1.2, остальное – на усмотрение).

Google Chrome

У меня под рукой кроме IE только хром, но, как известно из фольклора, оно не браузер. Что хорошо подтверждается тем, что никакого TLS 1.1 и TLS 1.2 в доступной сейчас рабочей версии (14.0.835.137) нет. Т.е. можно сказать проще – на сегодняшний день, 2.10.2011, все поддерживаемые хромом виды безопасных соединений на основе SSL/TLS уязвимы для сентябрьской атаки и данный инструмент не имеет смысла использовать для, допустим, финансовых транзакций, онлайн-платежей и прочих security sensitive штук.

Opera

Поставил оперу 11.51. Пожалуй, тут лучше всех сделано – можно не только выставить нужные протоколы (доступен выбор из SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2), но и нужные комплекты алгоритмов. Делается это зайдя в меню, там – Settings -> Preferences -> Advanced -> Security -> Security Protocols -> Details.
Правда, сделано плохо, потому что при включенном варианте “TLS 1.0 + 1.1 + 1.2” согласовывать начинает с TLS 1.0. Специально перепроверил, плюс посмотрел через netmon – удивительно, реально начинает с 1.0, согласовывает и успокаивается. Т.е. если включить все эти 3 протокола в Internet Explorer, то на тестовых сайтах клиент будет определяться как “TLS 1.2 compatible”, а в случае оперы – “TLS 1.0”. Плохо, по сути перечеркивает всё преимущество тонкой настройки – т.е. ну поддерживает она 1.2, что с того-то, если согласовывать пробует 1.0 для начала. То есть или надо вручную выключать TLS 1.0 (тогда большинство публичных https-сайтов типа gmail или facebook отвалятся), или сидеть с уязвимой версией.

После таких “мелочей” люди удивляются, почему IE является корпоративным стандартом.

SSL TLS

Протокол SSL TLS

Пользователи бюджетных организаций, да и не только бюджетных, чья деятельность напрямую связана с финансами, во взаимодействии с финансовыми организациями, например, Минфином, казначейством и т.д., все свои операции проводят исключительно по защищенному протоколу SSL. В основном, в своей работе они используют браузер Internet Explorer. В некоторых случаях — Mozilla Firefox.

Ошибка SSL

Основное внимание, при проведении данных операций, да и работе в целом, уделено системе защиты: сертификаты, электронные подписи. Для работы используется программное обеспечение КриптоПро актуальной версии

Что касается проблемы с протоколами SSL и TLS
, если ошибка SSL
появилась, вероятнее всего отсутствует поддержка данного протокола.

Ошибка TLS

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

Поддержка протоколов SSL и TLS

Итак, при использовании Microsoft Internet Explorer, чтобы посетить веб-сайт по защищенному протоколу SSL, в строке заголовка отображается Убедитесь что протоколы ssl и tls включены
. В первую очередь, необходимо включить поддержку протокола TLS 1.0 в Internet Explorer.

Если вы посещаете веб-сайт, на котором работает Internet Information Services 4.0 или выше, настройка Internet Explorer для поддержки TLS 1.0 помогает защитить ваше соединение. Конечно, при условии, что удаленный веб-сервер, который вы пытаетесь использовать поддерживает этот протокол.

Для этого в меню Сервис
выберите команду Свойства обозревателя
.

На вкладке Дополнительно
в разделе Безопасность
, убедитесь, что следующие флажки выбраны:

Использовать SSL 2.0
Использовать SSL 3.0
Использовать TLS 1.0

Нажмите кнопку Применить

, а затем ОК

. Перезагрузите браузер

.

После включения TLS 1.0, попытайтесь еще раз посетить веб-сайт.

Системная политика безопасности

Если по-прежнему возникают ошибки с SSL и TLS
, если вы все еще не можете использовать SSL, удаленный веб-сервер, вероятно, не поддерживает TLS 1.0. В этом случае, необходимо отключить системную политику, которая требует FIPS-совместимые алгоритмы.

Чтобы это сделать, в Панели управления
выберите Администрирование
, а затем дважды щелкните значок Локальная политика безопасности
.

В локальных параметрах безопасности, разверните узел Локальные политики
, а затем нажмите кнопку Параметры безопасности
.

В соответствии с политикой в ​​правой части окна, дважды щелкните Системная криптография: использовать FIPS-совместимые алгоритмы для шифрования, хеширования и подписывания
, а затем нажмите кнопку Отключено
.

Внимание! Изменение вступает в силу после того, как локальная политика безопасности повторно применяется. То есть включите ее
и перезапустите браузер