Продвинутые сведения про сертификаты

какие крипто алгоритмы используются при установке защищённого соединения используются следующие алгоритмы алгоритм шифрования; алгоритмы хеширования; алгоритмы аутентификации наиболее часто используемыми алгоритмами шифрования, которые используются для криптографических операций в tls/ssl, являются комбинации алгоритмов rsa (аббревиатура от фамилий создателей rivest, shamir и adleman), dsa (англ digital signature algorithm, запатентованный национальным институтом стандартов и технологий сша) и несколько вариаций алгоритма диффи–хеллмана (англ diffie–hellman, dh), такие как единовременный dh (англ ephemeral diffie–hellman, edh) и dh на основе эллиптических кривых (англ elliptic curve diffie–hellman, ecdh) данные вариации диффи хэллмана, в отличие от исходного алгоритма, обладают свойством прогрессивной секретности, т е когда записанные ранее данные невозможно дешифровать через какое то время, даже если удалось получить секретный ключ сервера, т к исходные параметры алгоритма генерируются заново при повторном установлении канала после принудительного разрыва в течение определённого таймаута соединения в основе алгоритмов хеширования лежит семейство математических функций вычисления хеша sha (англ secure hash algorithm) хеш функция позволяет преобразовать исходный массив данных в строку определённой длины, в зависимости от которой варьируется время обработки и требуемые вычислительные мощности все алгоритмы шифрования сегодня поддерживают алгоритм хеширования sha2, чаще всего sha 256 sha 512 имеет похожую структуру, но в нем длина слова равна 64 бита вместо 32, количество раундов в цикле равно 80 вместо 64, а сообщение разбивается на блоки по 1024 бита, вместо 512 бит раньше для тех же целей применялись алгоритмы sha1 и md5, но сегодня они считаются уязвимыми современные сервисы используют ключи длиной 64 бита и выше актуальная версия алгоритма sha 3 (keccak) хеш алгоритм также использует величину, необходимую для проверки целостности передаваемых данных, — mac (англ message authentication code) mac использует функцию отображения, чтобы представлять данные сообщения как фиксированное значение длины, а затем хеширует сообщение в современных версиях протокола tls применяется hmac (англ hashed message authentication code), который использует хеш функцию сразу с общим секретным ключом данный ключ передаётся вместе с потоком информации, и для подтверждения подлинности обе стороны должны использовать одинаковые секретные ключи, что обеспечивает большую безопасность общий алгоритм работы ssl 1 соглашение о рукопожатии (handshake protocol) протокол подтверждения соединения (квитирования) – порядок операций, выполняемый непосредственно при инициализации ssl соединения между клиентом и сервером протокол позволяет серверу и клиенту проводить взаимную аутентификацию, определять алгоритм шифрования и mac, а также секретные ключи для защиты данных в ходе дальнейшего сеанса ssl протокол рукопожатия используется участниками на этапе до обмена данными каждое сообщение, передаваемое в рамках протокола рукопожатия, содержит следующие поля тип категория сообщений существует 10 категорий сообщений длина длина каждого сообщения в байтах содержимое непосредственно сообщение и его параметры в ходе соглашения о рукопажитии проходят следуюзие этапы 1 1 определение поддерживаемых алгоритмов на первом этапе инициируется соединение между клиентом и сервером и осуществляется выбор алгоритмов шифрования сначала клиент отправляет клиенту приветственное сообщение на сервер и переходит в режим ожидания ответа сервер после получения приветственного сообщения клиента возвращает клиенту собственное приветственное сообщение для подтверждения установки соединения приветственное сообщение клиента включает следующие данные максимальный номер версии ssl, который может поддерживать клиент 32 байтовое случайное число, используемое для генерации главного секрета идентификатор сеанса список комплектов шифров список алгоритмов сжатия формат списка комплектов шифров <1> <2> <3> <4> где название протокола, например, «ssl» или «tls» алгоритм обмена ключами (с указанием алгоритма аутентификации) алгоритм шифрования алгоритм хеширования например, запись «ssl dhe rsa with des cbc sha» означает, что фрагмент «dhe rsa» (временный diffie hellman с цифровой подписью rsa) определяется как алгоритм обмена ключами; фрагмент «des cbc» определяется, как алгоритм шифрования; а фрагмент «sha» определяется как алгоритм хеширования как будет рассмотрено далее, в tlsv1 3 протоколы обмена ключами и шифрования объединены в алгоритм аутентифицированного шифрования с присоединёнными данными (aead), поэтому запись там будет короче пример tls aes 256 gcm sha384 ответ сервера включает в себя следующие поля номер версии ssl на клиенте сравниваются самый низкий номер версии, поддерживаемый клиентом, и самый большой номер версии, поддерживаемый сервером в зависимости от настроек сервера приоритет в выборе может отдаваться клиенту либо серверу 32 байтовое случайное число, используемое для генерации главного секрета идентификатор сессии набор шифров из списка шифров, поддерживаемых клиентом метод сжатия из списка методов сжатия, поддерживаемых клиентом 1 2 проверка подлинности сервера и обмен ключами на втором этапе все сообщения отправляет сервер этот этап делится на 4 стадии \ отправка цифрового сертификата клиенту, чтобы клиент мог использовать открытый ключ сервера для аутентификации \ обмен ключами на сервере в зависимости от установленного алгоритма данный этап может отсутствовать \ запрос сертификата у клиента в зависимости от настроек сервер может потребовать от клиента отправку собственного сертификата \ сообщение о завершении этапа и перехода к следующим операциям 1 3 аутентификация клиента и обмен ключами на третьем этапе все сообщения отправляет клиент этот этап делится на 3 стадии \ отправка сертификата на сервер, если сервер запрашивал его, в зависимости от установленного алгоритма таким образом клиент может подтвердить подлинность на сервере, например, в iis можно настроить обязательную проверку подлинности сертификата клиента \ обмен ключами клиента (англ pre master secret) – отправка мастер ключа на сервер, который впоследствии будет шифроваться ключом сервера клиент знает мастер ключ и в случае подмены сервера сможет прервать соединение \ подписание случайного числа для подтверждения владения открытым ключом сертификата данный этап также зависит от выбранного алгоритма 1 4 завершение работы сервера на четвёртом этапе осуществляется непосредственно обмен сообщениями и контроль ошибок, при обнаружении которых вступает в силу протокол тревоги этот этап состоит из обмена сообщениями о сеансе первые 2 приходят от клиента, а последние 2 сообщения – от сервера 2 ㅤпроцесс генерации ключей чтобы обеспечить целостность и конфиденциальность информации, ssl требует шесть секретов шифрования четыре ключа и два значения вектора инициализации (англ initialization vector, iv, см далее) достоверность информации гарантируется ключом аутентификации (например, hmac), шифрование данных обеспечивается открытым ключом, и блоки данных создаются на основе iv ключи, требуемые ssl, являются однонаправленными, что значит при взломе клиента полученные данные нельзя использовать для взлома сервера 3 ㅤзапись соглашения (record protocol) протокол записи используется после успешной установки соединения между клиентом и сервером, после того, как клиент и сервер пройдут взаимную аутентификацию и определят алгоритм, используемый для обмена информацией о применяемых алгоритмах протокол записи реализует следующие функции конфиденциальность путём использования секретного ключа, определённого на этапе рукопожатия целостность путём анализа mac определённого при квитировании 4 ㅤпротокол тревоги когда клиент и сервер обнаруживают ошибку, они отправляют соответствующее сообщение если это критичная ошибка, алгоритм немедленно закрывает соединение ssl, и обе стороны сначала удаляют реквизиты сеанса идентификатор, секрет и ключ каждое сообщение об ошибке имеет длину 2 байта первый байт указывает тип ошибки при сбое соединения, значение равно 1, при обнаружении критичной ошибки – 2 второй байт указывает фактический тип ошибки версии ssl (ssl, tls) и чем они отличаются при первоначальной установке защищённого соединения между клиентом и сервером осуществляется выбор протокола среди поддерживаемых обеими сторонами из набора sslv3, tlsv1, tlsv1 1, tlsv1 2 или tlsv1 3 более ранние версии протокола ssl не используются версия sslv1 так и не была обнародована версия sslv2 была выпущена в феврале 1995 года, но содержала много недостатков безопасности, которые привели к разработке sslv3 различные it компании начали предпринимать попытки реализовать собственные версии протоколов безопасной передачи данных чтобы предотвратить разобщённость и монополизацию в сфере безопасности в сети, международное сообщество проектировщиков, учёных, сетевых операторов и провайдеров (англ internet engineering task force, ietf), созданное советом по архитектуре интернета в 1986 году и занимающееся развитием протоколов и организации работы интернета, стандартизировало протокол tls версии 1, незначительно отличающийся от ssl 3 0 технические детали работы протокола фиксируются выпуском документа под названием rfc (англ request for comments, рабочее предложение) данные документы можно найти на сайте ietf , где xxxx — состоящий из 4 цифр номер rfc таким образом, версия tlsv1 зафиксирована в rfc 2246, версия tlsv1 1 – в rfc 4346, версия tlsv1 2 – в rfc 5246, а версия tlsv1 3 – в rfc 8446 кроме того, в rfc 3546 определено несколько расширений для случаев, когда tls используются в системах с ограниченной пропускной способностью, таких как беспроводные сети; в rfc 6066 определён ряд дополнительных изменений tls, внесённых в формат расширенного приветствия клиента (представленного в tlsv1 2 ); в rfc 6961 определён метод уменьшения трафика, когда клиент запрашивает у сервера информацию о состоянии сертификата; и, наконец, в rfc 7925 определяется, что происходит с tls (и dtls) при его использовании в iot (англ internet of things, интернет вещей) при обмене данными между аппаратными средствами и иными физическими объектами без участия человека как было сказано выше, протокол tlsv1 был выпущен в качестве обновления sslv3 как указано в rfc 2246, «различия между этим протоколом и sslv3 не являются существенными, но они достаточно значительны, чтобы исключить взаимодействие между tlsv1 и sslv3» протокол tlsv1 1 по сравнению с tls версии 1 0 имел следующие отличия добавлена защита от атак с использованием cbc (англ cipher block chaining), когда каждый блок открытого текста перед шифрованием связывается с предыдущим блоком зашифрованного текста неявный вектор инициализации (исходное псевдослучайное число инициирующее вычисление дальнейшего шифра, iv) был заменён на явный, являющийся не секретным, а непредсказуемым за разумное время изменение в обработке ошибок заполнения блоков, когда пакет данных дополняется до размера фиксированного блока поддержка регистрации параметров ip адресов серверов и прочей сетевой информации протокол tls 1 2 основан на спецификации tls 1 1 наиболее распространён на текущий момент основные отличия включают комбинация алгоритмов хеширования md5–sha 1 в псевдослучайной функции (англ pseudorandom function, prf) была заменена на более устойчивую к взлому sha 256, с возможностью использования набора шифров, указанной функции размер хеша в готовом сообщении стал составлять не менее 96 бит комбинация алгоритмов хеширования md5–sha 1 в цифровой подписи была заменена одним хешем, согласованным во время рукопожатия, который по умолчанию равен sha 1 реализация функции выбора алгоритмов шифрования и хеширования для клиента и сервера расширение поддержки аутентифицированных шифров шифрования, используемых в основном для режима galois/ counter (gcm) и режима ccm для стандарта advanced encryption standard (aes) добавление определений расширений tls и наборов шифров aes удаление обратной совместимости с sslv2 в рамках 6176 rfc таким образом, сеансы tls перестали согласовывать использование ssl версии 2 0 уровня защищённых сокетов протокол tls 1 3 основан на спецификации tls 1 2 осуществляется постепенный переход на данный протокол у интернет сервисов основные отличия включают в себя отделение алгоритмов согласования ключей и аутентификации от наборов шифров удаление поддержки неустойчивых и менее используемых именованных эллиптических кривых удаление поддержки криптографических хеш функций md5 и sha 224 требование цифровых подписей даже при использовании предыдущей конфигурации интеграция функции формирования ключа, основанной на hmac (англ hkdf), и полу эфемерного предложения dh поддержка однократного времени возобновления сеанса приёма передачи (англ round trip time или 1 rtt) рукопожатий, и начальная поддержка нулевого времени возобновления сеанса приёма передачи (наименование режима 0 rtt) гарантия невозможности компрометации сессионных ключей, полученных при помощи набора ключей долговременного пользования, при получении злоумышленниками доступа к ним данное свойство называется совершенная прямая секретность (англ perfect forward secrecy, pfs) и реализуется посредством использования эфемерных ключей во время соглашения о ключах dh отказ от поддержки многих небезопасных или устаревших функций, включая сжатие, повторное согласование, шифры, отличные от aead режимов блочного шифрования (англ authenticated encryption with associated data), обмен ключами, отличными от pfs (среди которых статический обмен ключами rsa и статический обмен ключами dh), настраиваемые группы edh, согласование формата точки эллиптической кривой ecdh, протокол спецификации изменения шифрования, приветственное сообщение unix time и т д запрет на согласование ssl или rc4, присутствовавшее для обеспечения обратной совместимости отказ от использования номера версии уровня записи и фиксация номера для улучшения обратной совместимости добавление потокового шифра chacha20 с кодом аутентификации сообщения poly1305 добавление алгоритмов цифровой подписи ed25519 и ed448 добавление протоколов обмена ключами x25519 и x448 добавление поддержки отправки нескольких ответов протокола определения состояния сетевого сертификата (англ online certificate status protocol, ocsp) шифрование всех подтверждений приёма передачи блока данных после вызова сервера что такое pki (public key infrastructure) инфраструктура открытых ключей (англ public key infrastructure, pki) – система программных, аппаратных и регламентных способов, обеспечивающих решение криптографических задач на базе пары закрытого и открытого ключей в основе pki лежит эксклюзивное доверие участников обмена удостоверяющему центру при отсутствии информации друг о друге удостоверяющий центр в свою очередь подтверждает или опровергает принадлежность открытого ключа заданному лицу, которое владеет соответствующим закрытым ключом основные компоненты pki удостоверяющий центр или центр сертификации – организация, осуществляющая в том числе и юридическую проверку данных об участниках сетевого взаимодействия (клиент или сервер) с технической точки зрения, удостоверяющий центр представляет собой программно аппаратный комплекс, который осуществляет управление жизненным циклом сертификатов, но не их непосредственным использованием является доверенной третьей стороной сертификат открытого ключа (чаще всего просто сертификат) – это данные клиента или сервера, а также открытый ключ, подписанные электронной подписью удостоверяющего центра выпуск сертификата открытого ключа удостоверяющим центром гарантирует, что лицо, указанное в сертификате, владеет и закрытой частью единой ключевой пары регистрационный центр (рц) – промежуточный удостоверяющий центр, действующий на основания доверия к корневому удостоверяющему центру корневой удостоверяющий центр доверяет данным, полученным регистрационным центром в ходе проверки информации о субъекте регистрационный центр после проверки достоверности информации подписывает её собственным ключом и передаёт полученные данные корневому удостоверяющему центру корневой удостоверяющий центр проверяет подпись регистрационного центра и в случае успеха выпускает сертификат один регистрационный центр может работать с несколькими удостоверяющими центрами (иными словами, состоять в нескольких pki), так же, как и один удостоверяющий центр может работать с несколькими регистрационными центрами данный компонент может отсутствовать в корпоративной инфраструктуре репозиторий – хранилище действующих сертификатов и список отозванных сертификатов, которые постоянно обновляются список отозванных сертификатов (англ certificate revocation list, crl) содержит данные о выпущенных сертификатах, у которых истёк оплаченный период или срок действия, а также сертификаты владельцев ресурсов, которые были скомпрометированы или не была подтверждена подлинность в федеральном законе рф № 63 «об электронной подписи» российской федерации данный компонент называется реестром сертификатов ключей подписей архив сертификатов – хранилище всех выпущенных когда либо сертификатов (включая сертификаты с закончившимся сроком действия) в рамках текущей pki архив сертификатов используется для расследований инцидентов безопасности, которые включают в себя проверку когда либо подписанных данных центр запросов – личный кабинет клиента удостоверяющего центра, где конечные пользователи могут запросить новый или отозвать имеющийся сертификат реализуется чаще всего в виде веб интерфейса для регистрационного центра конечные пользователи – клиенты, приложения или системы, являющиеся владельцами сертификата и использующие инфраструктуру управления открытыми ключами