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

При установке защищённого соединения используются следующие алгоритмы:

Наиболее часто используемыми алгоритмами шифрования, которые используются для криптографических операций в 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. Протокол рукопожатия используется участниками на этапе до обмена данными. Каждое сообщение, передаваемое в рамках протокола рукопожатия, содержит следующие поля:

В ходе соглашения о рукопажитии проходят следуюзие этапы:

1.1 Определение поддерживаемых алгоритмов На первом этапе инициируется соединение между клиентом и сервером и осуществляется выбор алгоритмов шифрования. Сначала клиент отправляет клиенту приветственное сообщение на сервер и переходит в режим ожидания ответа. Сервер после получения приветственного сообщения клиента возвращает клиенту собственное приветственное сообщение для подтверждения установки соединения. Приветственное сообщение клиента включает следующие данные:

Формат списка комплектов шифров:

Где:

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) Протокол записи используется после успешной установки соединения между клиентом и сервером, после того, как клиент и сервер пройдут взаимную аутентификацию и определят алгоритм, используемый для обмена информацией о применяемых алгоритмах. Протокол записи реализует следующие функции:

4.ㅤПротокол тревоги

Когда клиент и сервер обнаруживают ошибку, они отправляют соответствующее сообщение. Если это критичная ошибка, алгоритм немедленно закрывает соединение SSL, и обе стороны сначала удаляют реквизиты сеанса: идентификатор, секрет и ключ. Каждое сообщение об ошибке имеет длину 2 байта. Первый байт указывает тип ошибки. При сбое соединения, значение равно 1, при обнаружении критичной ошибки – 2. Второй байт указывает фактический тип ошибки.

При первоначальной установке защищённого соединения между клиентом и сервером осуществляется выбор протокола среди поддерживаемых обеими сторонами из набора 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 имел следующие отличия:

Протокол TLS 1.2 основан на спецификации TLS 1.1. Наиболее распространён на текущий момент. Основные отличия включают:

Протокол TLS 1.3 основан на спецификации TLS 1.2. Осуществляется постепенный переход на данный протокол у интернет-сервисов. Основные отличия включают в себя:

Инфраструктура открытых ключей (англ. Public Key Infrastructure, PKI) – система программных, аппаратных и регламентных способов, обеспечивающих решение криптографических задач на базе пары закрытого и открытого ключей. В основе PKI лежит эксклюзивное доверие участников обмена удостоверяющему центру при отсутствии информации друг о друге. Удостоверяющий центр в свою очередь подтверждает или опровергает принадлежность открытого ключа заданному лицу, которое владеет соответствующим закрытым ключом.

Основные компоненты PKI: