Сетевые протоколы SSL и TLS являются криптографическими протоколами, обеспечивающими аутентификацию и защиту от несанкционированного доступа, нарушения целостности передаваемых данных. Протоколы SSL/TLS предназначены для исключения подмены идентификатора на клиентской или серверной стороне, раскрытия или искажения данных. Для этих целей используется надежный метод аутентификации, применяются шифрование канала связи и коды целостности сообщений. Стандартным портом, устанавливаемым по умолчанию для SSL/TLS, является порт 443 для HTTPS, 465 для SMTPS (электронная почта), 636 для LDAPS, 563 для NNTPS, 994 для IRCS (чат), 995 для POP3S.
Протокол SSL разработан компанией Netscape для защиты данных между сервисными и транспортными протоколами. Первая обнародованная версия была выпущена в 1995 году. Широко используется для VoIP-приложений, сервисов обмена мгновенными сообщениями. SSL представляет собой безопасный канал, имеющий следующие свойства:
Протокол SSL использует как симметричный, так и асимметричный ключи.
Протокола SSL обеспечивает решение двух задач — шифрование передаваемой информации и передача информации именно туда, куда требуется (аутентификация). Основное назначение протокола — предоставление надежного способа обмена данными между приложениями. Реализация SSL выполнена в виде многослойной среды, которая используется для безопасной передачи информации посредством незащищенных каналов связи.
Многослойная структура представлена слоем протокола подтверждения подключения и слоем протокола записи. Первым слоем выступает транспортный протокол, например, TCP — вместе с SSL Record Protocol данные слои образуют ядро SSL, которое впоследствии участвует в формировании сложных инфраструктур.
Среди основных особенностей протокола SSL следует отметить программно-платформенную независимость. В настоящее время протокол SSL не обеспечивает должную защиту — на смену ему пришел протокол TLS.
Протокол TLS представляет собой криптографический протокол, который применяется для защищенной передачи данных между различными узлами в сети интернет. Данный протокол нашел применение в VoIP-приложениях, веб-браузерах, приложениях для мгновенного обмена сообщениями. TLS реализован на спецификации SSL 3.0. Разработкой и развитием протокола занимается компания IETF.
К основным мерам безопасности, которые обеспечивает протокол TLS, относятся:
В протоколе TLS используются следующие алгоритмы:
Приложения осуществляют обмен записями, которые хранят в себе данные. Записи могут быть сжаты, дополнены, зашифрованы или же идентифицированы. При этом в каждой записи указываются данные о длине пакета и используемой версии TLS.
В общем случае применение криптографии в протоколах SSL/TLS значительно снижает производительность приложений, зато обеспечивает надежную защиту передачи данных. Протоколы не требуют практически никаких настроек с клиентской стороны, считаются самыми распространенными протоколами защиты в сети интернет.
Что такое TLS-рукопожатие и как оно устроено
TLS - это один из наиболее часто встречающихся инструментов безопасности, используемых в интернете. Протокол активно работает со многими процессами сетевого взаимодействия: передачей файлов, VPN-подключением (в некоторых реализациях для обмена ключами), службами обмена мгновенными сообщениями или IP-телефонией.
Один из ключевых аспектов протокола - это рукопожатие. Именно о нём мы поговорим в этой статье.
«Рукопожатие SSL/TLS» - это название этапа установки HTTPS-соединения. Большая часть работы, связанной с протоколом SSL/TLS, выполняется именно на этом этапе. В прошлом году IETF доработал TLS 1.3 , полностью обновив процесс рукопожатия.
В статье будут освещены два вида рукопожатия - для протоколов TLS 1.2 и TLS 1.3, которые мы рассмотрим, начиная с абстрактного уровня и постепенно углубляясь в особенности:
В HTTPS-соединении участвуют две стороны: клиент (инициатор соединения, обычно веб-браузер) и сервер. Цель рукопожатия SSL/TLS - выполнить всю криптографическую работу для установки безопасного соединения, в том числе проверить подлинность используемого SSL-сертификата и сгенерировать ключ шифрования.
Каждое программное обеспечение уникально. Поэтому даже самые популярные веб-браузеры имеют различную функциональность. Аналогично и на стороне сервера - Windows Server, Apache и NGINX также отличаются друг от друга. Всё становится ещё сложнее, когда вы добавляете пользовательские конфигурации.
Именно поэтому первый шаг TLS-рукопожатия - обмен информацией о своих возможностях между клиентом и сервером для дальнейшего выбора поддерживаемых криптографических функций.
Как только клиент и сервер согласовывают используемый шифронабор, сервер отправляет клиенту свой SSL-сертификат.
Получив сертификат, клиент проверяет его на подлинность. Это чрезвычайно важный шаг. Чтобы соединение было безопасным, нужно не только зашифровать данные, нужно ещё убедиться, что они отправляются на правильный веб-сайт. Сертификаты SSL/TLS обеспечивают эту аутентификацию, а то, как они это делают, зависит от используемого шифронабора.
Все доверенные SSL-сертификаты выпускаются центром сертификации (ЦС). ЦС должен следовать строгим правилам выдачи и проверки сертификатов, чтобы ему доверяли. Вы можете считать ЦС кем-то вроде нотариуса - его подпись значит, что данные в сертификате реальны.
Во время аутентификационной части TLS-рукопожатия клиент выполняет несколько криптографически безопасных проверок с целью убедиться, что выданный сервером сертификат подлинный. Процесс включает в себя проверку цифровой подписи и того, выдан ли сертификат доверенным ЦС.
На этом этапе клиент косвенно проверяет, принадлежит ли серверу закрытый ключ, связанный с сертификатом.
В RSA, самой распространённой криптосистеме с открытым ключом, клиент с помощью открытого ключа шифрует случайные данные, которые будут использоваться для генерации сеансового ключа. Сервер сможет расшифровать и использовать эти данные, только если у него есть закрытый ключ, наличие которого обеспечивает подлинность стороны.
Если используется другая криптосистема, алгоритм может измениться, но проверка другой стороны на подлинность всё равно останется.
Последняя часть TLS-рукопожатия включает создание «сеансового ключа», который фактически будет использоваться для защищённой связи.
Сеансовые ключи являются «симметричными», то есть один и тот же ключ используется для шифрования и дешифрования.
Симметричное шифрование производительнее, чем асимметричное, что делает его более подходящим для отправки данных по HTTPS-соединению. Точный метод генерации ключа зависит от выбранного шифронабора, два самых распространённых из них - RSA и Диффи-Хеллман.
Чтобы завершить рукопожатие, каждая сторона сообщает другой, что она выполнила всю необходимую работу, а затем проверяет контрольные суммы, чтобы убедиться, что рукопожатие произошло без какого-либо вмешательства или повреждения.
Всё SSL-рукопожатие происходит за несколько сотен миллисекунд. Это первое, что произойдёт при HTTPS-соединении, даже до загрузки веб-страницы. После SSL-рукопожатия начинается зашифрованное и аутентифицированное HTTPS-соединение, и все данные, отправляемые и получаемые клиентом и сервером, защищены.
Вплоть до TLS 1.3 каждый раз, когда вы посещали сайт, рукопожатие происходило заново. Рукопожатие TLS 1.3 поддерживает 0-RTT или нулевое время возобновления приёма-передачи, что значительно увеличивает скорость для вернувшегося посетителя.
Рассмотрим TLS-рукопожатие с использованием RSA подробнее. Использование алгоритма Диффи-Хеллмана будет описано ниже.
После этих шагов SSL-рукопожатие завершено. У обеих сторон теперь есть сеансовый ключ, и они могут взаимодействовать через зашифрованное и аутентифицированное соединение.
На этом этапе могут быть отправлены первые байты веб-приложения (данные, относящиеся к фактическому сервису, - HTML, Javascript и т. д.).
Рукопожатие TLS 1.3 значительно короче, чем его предшественник.
Исторически одна из претензий к SSL/TLS заключалась в том, что он перегружал серверы дополнительными издержками. Это повлияло на ныне несуществующее представление, что HTTPS медленнее, чем HTTP.
Рукопожатия до TLS 1.2 требовали много ресурсов и в больших масштабах могли серьёзно нагрузить сервер. Даже рукопожатия TLS 1.2 могут замедлить работу, если их происходит много в один момент времени. Аутентификация, шифрование и дешифрование - дорогие процессы.
На небольших веб-сайтах это скорее всего не приведёт к заметному замедлению работы, но для корпоративных систем, куда ежедневно приходят сотни тысяч посетителей, это может стать большой проблемой. Каждая новая версия рукопожатия существенно облегчает процесс: TLS 1.2 совершает две фазы, а TLS 1.3 укладывается всего в одну и поддерживает 0-RTT.
В приведённом выше объяснении рукопожатие разделено на десять отдельных этапов. В действительности же многие из этих вещей происходят одновременно, поэтому их часто объединяют в группы и называют фазами.
У рукопожатия TLS 1.2 можно выделить две фазы. Иногда могут потребоваться дополнительные, но когда речь идёт о количестве, по умолчанию подразумевается оптимальный сценарий.
В отличие от 1.2, рукопожатие TLS 1.3 укладывается в одну фазу, хотя вернее будет сказать в полторы, но это всё равно значительно быстрее, чем TLS 1.2.
Никто никогда не собирался использовать 37 наборов для шифрования данных, так эволюционировал протокол. Каждый раз, когда добавлялся новый алгоритм, добавлялись новые комбинации, и вскоре IANA администрировала 37 различных шифронаборов.
Это плохо по двум причинам:
IETF исключил в TLS 1.3 поддержку всех алгоритмов, кроме самых безопасных, убирая путаницу за счёт ограничения выбора. В частности, был убран выбор метода обмена ключами. Эфемерная схема Диффи-Хеллмана стала единственным способом, позволяющим клиенту отправить информацию о своём ключе вместе с «Client Hello» в первой части рукопожатия. Шифрование RSA было полностью удалено вместе со всеми другими схемами обмена статическими ключами.
При этом есть одна потенциальная ахиллесова пята в TLS 1.3.
0-RTT - это то, к чему стремился весь технологический мир, и вот оно здесь с TLS 1.3. Как уже было упомянуто, рукопожатие TLS исторически было не быстрым, так что было важно ускорить его. 0-RTT делает это путём сохранения некоторой секретной информации о клиенте, обычно идентификатора сеанса или сеансовых тикетов, чтобы использовать их при следующем соединении.
Несмотря на все преимущества 0-RTT, он содержит пару потенциальных подводных камней. Режим делает клиентов восприимчивыми к атакам воспроизведения, когда злоумышленник, которому каким-то образом удаётся получить доступ к зашифрованному сеансу, может получить данные 0-RTT, включая первый запрос клиента, и снова отправить их на сервер.
Тем не менее, использовать эксплойт непросто. Вероятно, такой риск - небольшая цена за чрезвычайно полезную функцию.
С самого начала вызывало опасение количество информации, отправляемой в виде открытого текста во время рукопожатия. Очевидно, что это небезопасно, поэтому чем больше шагов рукопожатия происходит в зашифрованном виде, тем лучше.
В рукопожатии TLS 1.2 этапы согласования не были защищены, вместо этого использовалась простая MAC-функция, чтобы никто не вмешался в передачу. В этап согласования входят сообщения «Client Hello» и «Server Hello».
MAC-функция действует как индикатор, но не даёт никаких гарантий безопасности. Возможно, вы слышали об атаке, которая вынуждает стороны использовать менее безопасные протоколы и функции (downgrade attack). Если и сервер, и клиент поддерживают устаревшие шифронаборы - информацию об этом легко получить, прослушивая соединение, - злоумышленник может изменить шифрование, выбранное сервером, на более слабое. Такие атаки не опасны сами по себе, но открывают дверь для использования других известных эксплойтов тех шифронаборов, на которые был изменён выбранный изначально.
Рукопожатие TLS 1.3 использует цифровую подпись на ранних стадиях соединения, что делает его более безопасным и защищает от атак, меняющих шифронабор. Подпись также позволяет быстрее и эффективнее аутентифицировать сервер.
Теперь посмотрим, как эти обновления для рукопожатия TLS 1.3 будут реализованы во всех трёх основных функциях самого рукопожатия SSL/TLS.
Шифронабор - это набор алгоритмов, определяющих параметры безопасного соединения.
В начале любого соединения самое первое взаимодействие, «Client Hello», представляет собой список поддерживаемых шифронаборов. Сервер выбирает лучший, наиболее безопасный вариант, который поддерживается им и отвечает его требованиям. Вы можете посмотреть на шифронабор и выяснить все параметры рукопожатия и соединения.
В приведённом выше примере используется эфемерная система Диффи-Хеллмана (DH) с эллиптической кривой для обмена ключами и алгоритм цифровой подписи эллиптической кривой для аутентификации. DH также может быть соединен с RSA (функционирующим как алгоритм цифровой подписи) для выполнения аутентификации.
Вот список наиболее широко поддерживаемых шифронаборов TLS 1.2:
Мы уже знаем, что будем использовать какую-то версию обмена эфемерными ключами Диффи-Хеллмана, но не знаем параметров, так что первые два алгоритма в шифронаборе TLS 1.2 больше не нужны. Эти функции всё ещё выполняются, их просто больше не нужно согласовывать во время рукопожатия.
Из приведённого выше примера видно, что используется AES (Advanced Encryption Standard) для шифрования большого объёма данных. Он работает в режиме счётчика Галуа с использованием 256-битных ключей.
Вот пять шифронаборов, которые поддерживаются в TLS 1.3:
Важно помнить, что при создании версии 1.3 главным было повышение безопасности и производительности. Для этого в TLS 1.3 был переработан алгоритм генерация ключей и исправлены известные уязвимости.
В рукопожатии TLS 1.3 также стали лучше некоторые процессы, например аутентификация сообщений и цифровые подписи.
Наконец, в дополнение к постепенному отказу от старых алгоритмов генерации ключей или обмена ими, TLS 1.3 устраняет старые симметричные шифры. В TLS 1.3 полностью исключили блочные шифры. Единственный разрешённый в TLS 1.3 тип симметричных шифров называется шифрованием с проверкой подлинности с использованием дополнительных данных (AEAD). Он объединяет шифрование и проверку подлинности сообщений (MAC) в одну функцию.
Исторически двумя основными вариантами обмена ключами являются RSA и Диффи-Хеллман (DH), в наши дни DH часто ассоциируется с эллиптическими кривыми (ECDH). Несмотря на некоторые основные сходства, между этими двумя подходами к обмену ключами есть фундаментальные различия.
Иными словами, TLS-рукопожатие RSA отличается от TLS-рукопожатия ECDH.
RSA использует простую факторизацию и модульную арифметику. Большие простые числа требуют много ресурсов процессора при вычислениях и их сложно подобрать.
Диффи-Хеллмана иногда называют экспоненциальным обменом ключами, что указывает на возведение в степень (в дополнение к модульной арифметике), но на самом деле сам DH вообще ничего не шифрует и не дешифрует. Поэтому называть его «методом шифрования» вместо «математического обоснования» может быть немного неверно.
Небольшой экскурс в историю может пояснить этот момент.
Ещё в 1976 году Уитфилд Диффи и Мартин Хеллман создали протокол обмена ключами, основанный на работе Ральфа Меркля, чьё имя, по мнению обоих, должно также присутствовать в названии протокола.
Они пытались решить проблему безопасного обмена ключами по незащищённому каналу, даже если злоумышленник прослушивает его. У них получилось, но был один серьёзный недостаток: обмен ключами DH не включал в себя проверку подлинности, поэтому не было возможности проверить сторону на другом конце соединения.
Это можно считать рождением криптографии с открытым ключом и ИОК. Вскоре после того, как Диффи и Хеллман представили свой протокол обмена ключами, были завершены самые ранние версии криптосистемы RSA. Диффи и Хеллман создали концепцию шифрования с открытым ключом, но ещё не придумали саму функцию одностороннего шифрования.
Именно Рон Ривест (R в RSA) создал концепцию, которая в итоге стала криптосистемой RSA.
Во многих отношениях RSA является духовным преемником DH. Он осуществляет:
Таким образом, RSA является более функциональным алгоритмом, который может обрабатывать как обмен ключами, так и цифровые подписи, то есть производить аутентификацию в дополнение к безопасному обмену ключами. Поэтому у RSA ключи больше: должна быть обеспечена достаточная безопасность для цифровой подписи.
В то время как RSA осуществляет аутентификацию и обмен ключами, Диффи-Хеллман только облегчает обмен ключами. Существует четыре распространённых варианта семейства DH:
Опять же, Диффи-Хеллман сам по себе ничего не аутентифицирует. Его нужно использовать в паре с алгоритмом цифровой подписи. Так, например, если вы использовали ECDH или ECDHE, большинство шифронаборов будут сопряжены с алгоритмом цифровой подписи эллиптической кривой (ECDSA) или RSA.
Как было только что сказано, дополнительная функциональность RSA для аутентификации с помощью цифровых подписей требует больших ключей, устойчивых к атакам перебором. Размер этих ключей сильно увеличивает затраты на их вычисление, шифрование и дешифрование во время рукопожатия.
С другой стороны, если Диффи-Хеллман не выполняет аутентификацию, то что он делает? Как было сказано выше, DH часто используют совместно с криптографией на основе эллиптических кривых, чтобы обеспечить аутентификацию и обмен ключами.
Эллиптическая криптография (ECC) имеет гораздо меньшие размеры ключей, которые соответствуют эллиптической кривой, на которой они основаны. Для этого контекста есть пять подходящих кривых:
Но это не единственное различие между открытыми/закрытыми ключами ECC и ключами RSA. Они используются для двух совершенно разных целей во время рукопожатия TLS.
В RSA пара открытый/закрытый ключ используется как для проверки подлинности сервера, так и для обмена симметричным ключом сеанса. Фактически, именно успешное использование секретного ключа для расшифровки секрета (pre-master secret) аутентифицирует сервер.
С Диффи-Хеллманом пара открытый/закрытый ключ НЕ используется для обмена симметричным сеансовым ключом. Когда задействован Диффи-Хеллман, закрытый ключ фактически связан с прилагаемым алгоритмом подписи (ECDSA или RSA).
Процесс RSA-аутентификации связан с процессом обмена ключами. Точнее обмен ключами является частью процесса аутентификации.
Когда клиенту предоставляется SSL-сертификат сервера, он проверяет несколько показателей:
Если все эти проверки прошли, то проводится последний тест - клиент шифрует pre-master secret с помощью открытого ключа сервера и отправляет его. Любой сервер может попытаться выдать любой SSL/TLS-сертификат за свой. В конце концов, это общедоступные сертификаты. А так клиент может провести аутентификацию сервера, увидев закрытый ключ «в действии».
Таким образом, если сервер может расшифровать pre-master secret и использовать его для вычисления сессионного ключа, он получает доступ. Это подтверждает, что сервер является владельцем используемой пары из открытого и закрытого ключа.
Когда используются Диффи-Хеллман и ECDSA/RSA, аутентификация и обмен ключами разворачиваются бок о бок. И это возвращает нас к ключам и вариантам их использования. Открытый/закрытый ключ RSA используется как для обмена ключами, так и для аутентификации. В DH + ECDSA/RSA асимметричная пара ключей используется только для этапа цифровой подписи или аутентификации.
Когда клиент получает сертификат, он всё ещё проводит стандартные проверки:
Но владение закрытым ключом подтверждается по-другому. Во время обмена ключами TLS-рукопожатия (шаг 4) сервер использует свой закрытый ключ для шифрования случайного числа клиента и сервера, а также свой DH-параметр. Он действует как цифровая подпись сервера, и клиент может использовать связанный открытый ключ для проверки, что сервер является законным владельцем пары ключей.
В TLS 1.3 аутентификация и цифровые подписи всё ещё играют важную роль, но они были исключены из шифронаборов для упрощения согласования. Они реализованы на стороне сервера и используют несколько алгоритмов, поддерживаемых сервером, из-за их безопасности и повсеместного распространения. В TLS 1.3 разрешены три основных алгоритма подписи:
В отличие от рукопожатия TLS 1.2, аутентификационная часть рукопожатия TLS 1.3 не связана с самим обменом ключами. Скорее она обрабатывается параллельно с обменом ключами и аутентификацией сообщений.
Вместо запуска симметричной схемы MAC для проверки целостности рукопожатия, сервер подписывает весь хеш расшифровки, когда возвращает «Server Hello» со своей частью общего ключа.
Клиент получает всю информацию, передающуюся с «Server Hello», и выполняет стандартную серию проверок подлинности сертификата SSL/TLS. Она включает в себя проверку подписи на сертификате, а затем проверку на соответствие подписи, которая была добавлена в хеш расшифровки.
Совпадение подтверждает, что сервер владеет секретным ключом.
Если выделить главную мысль этого раздела, она будет звучать так:
RSA облегчает обмен ключами, позволяя клиенту шифровать общий секрет и отправлять его на сервер, где он используется для вычисления соответствующего сеансового ключа. Обмен ключами DH на самом деле вообще не требует обмена открытым ключом, скорее обе стороны создают ключ вместе.
Если сейчас это звучит немного абстрактно, к концу этого раздела всё должно проясниться.
Называть это обменом ключами RSA на самом деле неправильно. На самом деле это RSA-шифрование. RSA использует асимметричное шифрование для создания ключа сеанса. В отличие от DH, пара открытого/закрытого ключей играет большую роль.
Вот как это происходит:
Вот как работает ECDH:
Существует свойство показателей по модулю, которое говорит, что каждая сторона получит одно и то же значение, которое будет ключом, используемым для симметричного шифрования во время соединения.
Теперь, когда мы узнали, чем DH отличается от RSA, посмотрим, как выглядит рукопожатие TLS 1.2 на основе DH.
Опять же, между этими двумя подходами существует множество сходств. Мы будем использовать ECDHE для обмена ключами и ECDSA для аутентификации.
Существует две основные причины, по которым сообщество криптографов предпочитает использовать DHE, а не RSA: совершенная прямая секретность и известные уязвимости.
Ранее вы, возможно, задавались вопросом, что означает слово «эфемерный» в конце DHE и ECDHE. Эфемерный буквально означает «недолговечный». И это может помочь понять совершенную прямую секретность (Perfect Forward Secrecy, PFS), которая является особенностью некоторых протоколов обмена ключами. PFS гарантирует, что сессионные ключи, которыми обмениваются стороны, не могут быть скомпрометированы, даже если скомпрометирован закрытый ключ сертификата. Другими словами, он защищает предыдущие сессии от извлечения и дешифрования. PFS получила высший приоритет после обнаружения ошибки Heartbleed. Это основной компонент TLS 1.3.
Существуют уязвимости, которые могут использовать заполнение (padding ), используемое во время обмена ключами в старых версиях RSA (PKCS #1 1.5). Это один из аспектов шифрования. С RSA pre-master secret должен быть зашифрован открытым ключом и расшифрован закрытым ключом. Но когда этот меньший по длине pre-master secret помещается в больший открытый ключ, он должен быть дополнен. В большинстве случаев попытавшись угадать заполнение и отправив поддельный запрос на сервер, вы ошибётесь, и он распознает несоответствие и отфильтрует его. Но есть немалая вероятность, что вы сможете отправить на сервер достаточное количество запросов, чтобы угадать правильное заполнение. Тогда сервер отправит ошибочное законченное сообщение, что, в свою очередь, сузит возможное значение pre-master secret. Это позволит злоумышленнику рассчитать и скомпрометировать ключ.
Вот почему RSA был удалён в пользу DHE в TLS 1.3.
В рукопожатии TLS 1.3 из-за ограниченного выбора схем обмена ключами клиент может успешно угадать схему и отправить свою часть общего ключа во время начального этапа (Client Hello) рукопожатия.
RSA была не единственной схемой обмена ключами, которая была удалена в TLS 1.3. Неэфемерные схемы Диффи-Хеллмана тоже были ликвидированы, как и перечень недостаточно безопасных параметров Диффи-Хеллмана.
Что имеется в виду под недостаточно безопасными параметрами? Не углубляясь в математику, сложность Диффи-Хеллмана и большинства криптосистем с открытым ключом - это сложность решения задач дискретного логарифма. Криптосистема должна быть достаточно сложной для вычисления, если неизвестны входные параметры (случайные числа клиента и сервера), иначе вся схема окажется бесполезной. Схемы Диффи-Хеллмана, которые не могли обеспечить достаточно большие параметры, были исключены в TLS 1.3.
Это очень похоже на то, что происходит с DH в рукопожатии TLS 1.2, кроме того, что в TLS 1.3 обмен ключами происходит раньше.
SSL/TLS-рукопожатие - это увлекательный процесс, который имеет ключевое значение для безопасного интернета, и всё же он происходит так быстро и незаметно, что большинство людей даже никогда не задумывается об этом.
По крайней мере, пока что-то не пойдёт не так, как нужно.
По требованиям российского законодательства признается только использование TLS-соединений, установленных по российским криптографическим алгоритмам ГОСТ 28147-89, ГОСТ Р 34.10-94, ГОСТ Р 34.11-94 и ГОСТ Р 34.10-2001. Поэтому, если вам требуется использование сайтов, использующих шифрование по ГОСТ алгоритмам, необходимо установить программу «КриптоПро CSP» .
В операционных системах Windows используется программа КриптоПро CSP - набор криптографических утилит для генерации электронной подписи, работы с сертификатами
Для установки КриптоПро CSP воспользуйтесь материалами с официального сайта:
После установки КриптоПро CSP браузер проверяет наличие и работоспособность этой программы.
Если сайт запрашивает шифрование ГОСТ TLS, браузер проверяет, установлено ли программа КриптоПро CSP. Если программа установлена, ей передается управление.
Примеры сайтов, запрашивающих шифрование: www.gosuslugi.ru , сайты на домене .gov.ru , .kamgov.ru , .nalog.ru .
Если сайта нет в списке, то запрашивается дополнительное подтверждение. Если вы доверяете сайту и соединение должно быть произведено с использованием шифрования ГОСТ TLS, нажмите кнопку Продолжить .
При переходе на какой-либо государственный или служебный портал (например, «ЕИС») пользователь может внезапно столкнуться с ошибкой «Не удается безопасно подключиться к этой странице. Возможно, на сайте используются устаревшие или ненадежные параметры безопасности протокола TLS». Данная проблема имеет довольно распространённый характер, и фиксируется на протяжении нескольких лет у различных категорий пользователей. Давайте разберёмся с сутью данной ошибки, и вариантами её решения.
Как известно, безопасность подключения пользователей к сетевым ресурсам обеспечивается за счёт использования SSL/TSL – криптографических протоколов, ответственных за защищённую передачу данных в сети Интернет. Они используют симметричное и ассиметричное шифрование, коды аутентичности сообщений и другие специальные возможности, позволяющие сохранять конфиденциальность вашего подключения, препятствуя расшифровке сессии со стороны третьих лиц.
Если при подключении к какому-либо сайту браузер определяет, что на ресурсе используются некорректные параметры протокола безопасности SSL/TSL, то пользователь получает указанное выше сообщение, а доступ к сайту может быть заблокирован.
Довольно часто ситуация с протоколом TLS возникает на браузере IE – популярном инструменте работы со специальными государственными порталами, связанными с различными формами отчётности. Работа с такими порталами требует обязательного наличия браузера Internet Explorer, и именно на нём рассматриваемая проблема возникает особенно часто.
Причины ошибки «Возможно, на сайте используются устаревшие или ненадежные параметры безопасности протокола TLS» могут быть следующими:
Решение возникшей проблемы может состоять в способах, описанных ниже. Но перед их описанием рекомендую просто перезагрузить ваш ПК – при всей тривиальности данный способ часто оказывается довольно эффективным.
Если же он не помог, тогда выполните следующее:
Затем нажмите на кнопку «Сайты» выше, и снимите галочку с опции «Для всех сайтов этой зоны…». Нажмите на «Ок», и попробуйте перейти на проблемный сайт.
Деактивируйте в БИОСе опцию «Secure Boot»
Причиной ошибки «Возможно, на сайте используются устаревшие или ненадежные параметры безопасности протокола TLS» довольно часто является локальный антивирус ПК, по определённым причинам блокирующий доступ к нужному интернет-порталу. При возникновении проблемной ситуации рекомендуется первым делом отключить ваш антивирус, дабы убедиться, что он не вызывает рассматриваемую проблему. Если же ошибка продолжает повторяться, тогда рекомендую перейти к реализации других советов, описанных ниже, чтобы позволит решить проблему ненадёжных параметров безопасности протокола TSL на вашем ПК.
Вконтакте
При открытии web-страничек появляются ошибки без каких либо на то причин? Или браузер выдает сообщение, что нельзя установить безопасное соединение? Пытаетесь открыть zakupki.gov.ru и lkul.nalog.ru, а появляется ошибка “Клиент и сервер поддерживают разные версии протокола ssl или набора шифров”? Пора разобраться, чем это вызвано и как выйти из сложившейся ситуации.
Вышеуказанные проблемы проявляются при открытии HTTPS платформ и ресурсов, у которых есть опция входа с цифровой подписью. Прежде, чем приступить к устранению ошибок, нужно убедиться, что проблема связана не с вашим ПО и компьютером. Попробуйте открыть необходимый интернет-ресурс на другом устройстве или подключившись к другой интернет-сети. Посмотрите, как обстоят дела со входом через прочие браузеры.
Первое, что нужно сделать для решения проблемы с SSL – это почистить браузер от мусора, включая куки и кэш. В Хроме, Яндексе и Опере в меню очистки можно попасть через комбинацию «CTRL+H». В Мозилле скопируйте вот этот адрес: about:preferences#privacy и найдите пункт «Куки и данные сайтов». Делая очистку, следует указать в строке выбора временного промежутка «Все время». В меню очистки выберите все пункты и подтвердите действие.
Доступ может блокироваться из-за различных установленных расширений и дополнений в рабочих браузерах. В первую очередь это касается плагинов, вмешивающихся в трафик и сетевые экраны, например ВПН, антивирусы, прокси. После открытия раздела с расширениями нужно удалить все подозрительные. Если нужный сайт по прежнему не открывается, попробуйте отключить все установленные расширения.
Попасть в меню управления плагинами достаточно просто. Можете просто скопировать этот путь в своем браузере:
Блокировать открытые ресурсы могут антивирусники и межсетевой экран. Попробуйте ненадолго их отключить, чтобы проверить, не они ли блокируют доступ к необходимому HTTPS сайту.
Последние версии антивирусных программ содержат в себе опцию проверки SST/TLS сертификатов. Опция эта работает в автоматическом режиме. Если антивирусник заметит, что интернет-платформа применяет самоподписанный или плохо защищенный сертификат (бесплатные SSL) – он может ограничить к ней доступ. Это также касается неактуальной версии SSL-протокола.
Для выхода из сложившейся ситуации необходимо открыть параметры антивирусной программы, найти раздел со сканированием и отключить режим проверки SSL сертификатов и HTTP/HTTPS трафика. Единого решения для всех антивирусников нет, так как каждый из них блокирует свои разделы. Так, например, в Dr.Web может не пускать на страницу опция «SpIDer Gate», а ESET NOD 32 – в фильтр веб-протоколов.
Даже такие незначительные детали, как часовой пояс или не отвечающая действительности дата, могут послужить причиной отказа в доступе к HTTPS площадке. Связана такая закономерность с выполнением сетевой аутентификации. Система осуществляет проверку даты создания и истечения сертификатов, из-за чего и появляются “несостыковки”. Во избежание подобных сложностей в настройках лучше всегда правильно указывать часовой пояс.
Правильно узнать свой часовой пояс можно через сервис 2ip.ru, который укажет город регистрации вашего провайдера. Именно по этому городу выставляйте свой часовой пояс. В случае с правильным временем нужно установить автоматическое определение.
Одна из вероятных причин блокировки доступа к определенным платформам может заключаться в корневых сертификатах вашей операционки. Если вы долгий период не обновляли Windows, то на ПК с большой долей вероятности отсутствует «TrustedRootCA» – корневые сертификаты (доверенные). Этот нюанс решается простым и очевидным решением – обновлением операционной системы. Следует запустить установку актуальных апдейтов через Центр обновлений. Если же на ПК установлена Windows 7, то необходимо заняться обязательной инсталляцией SP1 (KB976932), а также обновлением KB2998527.
Устаревшие версии указанных протоколов отключены потому, что сейчас злоумышленники могут создавать слишком много угроз для перехвата данных в трафике HTTPS типа. Включение старых протоколов может поставить под угрозу безопасность пользователя во время использования Интернета. Используйте способ только в том случае, если предыдущие не помогли.
На сегодняшний день браузеры не используют ненадежные старые протоколы и уже давно перешли на актуальные. Чтобы активировать устаревшие протоколы SSL/TLS необходимо:
Если и этот способ не помог, то можно попробовать такой вариант:
Если аналогичные ошибки возникают при входе на сайт zakupki.gov.ru или прочие государственные порталы – следует проверить следующие моменты:
Полную инструкцию с детальным описанием каждого пункта можно найти на сайте zakupki.gov.ru/epz , скачав “Инструкцию по настройке рабочего стола”.
Как показывает практика – на обновленных Windows такие ошибки на сайтах не выскакивают, а клиент и сервер поддерживают совместимые версии ssl-протоколов и наборы шифров соответствуют всем требованиям. В случае с закупками советуем обновить Internet Exprolel и провести настройку доступов, строго придерживаясь указанной в ссылке инструкции.
