Оригинальная ссылка:блог Прошлое и Ванга / 2018/03-Red Glowing…
1. Определение TLS
SSL(Secure Sockets Layer) Secure Sockets Layer — это протокол безопасности, который превратился в стандартный протокол безопасности после версий SSL 1.0, 2.0 и 3.0.TLS(Безопасность транспортного уровня) Протокол безопасности транспортного уровня. TLS доступен в версиях 1.0 (RFC 2246), 1.1 (RFC 4346), 1.2 (RFC 5246), 1.3 (RFC 8446).
TLS реализован взаписывающий слойислой рукопожатияДва уровня, из которых уровень рукопожатия содержит четыре подпротокола: протокол рукопожатия, протокол изменения спецификации шифра, протокол данных приложения и протокол оповещения.
2. HTTPS = HTTP over TLS.
Вам нужно только настроить параметры браузера и связанных с сервером, чтобы включить TLS для реализации HTTPS. TLS очень развязан, съемный и сотрудничает с протоколом слоя расширенного уровня в верхнем слое и не зависит друг от друга.
3. Шифрование
Реализация функции TLS/SSL в основном зависит от трех основных алгоритмов: хеш-функция Hash, симметричное шифрование и асимметричное шифрование.Он использует асимметричное шифрование для реализации аутентификации личности и согласования ключей, а алгоритм симметричного шифрования использует согласованный ключ для шифрования данных. проверяет целостность информации на основе хеш-функции.
Основной метод рабочего метода TLS состоит в том, что клиент использует асимметричное шифрование для связи с сервером, реализует аутентификацию и согласится с ключом, используемым для симметричного шифрования, а затем симметричный алгоритм шифрования использует согласованный ключ для шифрования информационной и информации информации. Симметричные ключи Используемые между ними разные, которые могут гарантировать, что информация может быть получена только обеими сторонами связи.
Например, в протоколе HTTPS, когда клиент отправляет запрос, сервер отправляет клиенту открытый ключ.После проверки клиента ключ генерируется, шифруется с помощью открытого ключа и отправляется на сервер (асимметричное шифрование). Во время рукопожатия TLS генерируется согласованный ключ (симметричный ключ), и после успеха устанавливается зашифрованное соединение. В процессе связи клиент шифрует данные запроса с помощью согласованного ключа и отправляет их, сервер также использует согласованный ключ для их расшифровки, и ответ также использует тот же согласованный ключ. Последующая связь использует симметричное шифрование, поскольку симметричное шифрование и дешифрование выполняются быстро, а асимметричное шифрование в процессе рукопожатия может обеспечить эффективность шифрования, но этот процесс сложен, а объем вычислений относительно велик.
4. Записывающий слой
Протокол записи отвечает за все базовые сообщения, которыми обмениваются через транспортное соединение, и можно настроить шифрование. Каждая запись TLS начинается с короткого заголовка. Заголовок содержит тип (или подпротокол), версию протокола и длину содержимого записи. Исходное сообщение фрагментируется (или объединяется), сжимается, аутентифицируется и шифруется в части данных записи TLS.
Фрагментация
Уровень записи разбивает блоки информации на записи TLSPlaintext, которые несут данные в блоках размером 2^14 байт (16 КБ) или меньше.
Протокол записи транспортирует непрозрачные буферы данных, переданные ему другими уровнями протокола. Если буфер превышает предел длины записи (2^14), протокол записи разделит его на более мелкие части. Возможно и обратное, и небольшие буферы, принадлежащие одному и тому же подпротоколу, также могут быть объединены в одну запись.
struct {
uint8 major, minor;
} ProtocolVersion;
enum {
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23), (255)
} ContentType;
struct {
ContentType type; // 用于处理封闭片段的较高级协议
ProtocolVersion version; // 使用的安全协议版本
uint16 length; // TLSPlaintext.fragment 的长度（以字节为单位），不超过 2^14
opaque fragment[TLSPlaintext.length]; // 透明的应用数据，被视为独立的块，由类型字段指定的较高级协议处理
} TLSPlaintext;
Запись сжатия и распаковки
Алгоритм сжатия TLSPlaintext преобразует структуру в структуру TLSCompressed. Если вы определяете CompressionMethod как null, это означает отсутствие сжатия
struct {
ContentType type; // same as TLSPlaintext.type
ProtocolVersion version; // same as TLSPlaintext.version
uint16 length; // TLSCompressed.fragment 的长度，不超过 2^14 + 1024
opaque fragment[TLSCompressed.length];
} TLSCompressed;
Стандарт эфирного или потокового шифрования (нулевой или стандартный потоковый шифр)
Потоковое шифрование (BulkCipherAlgorithm) преобразует структуру TLSCompressed.fragment в потоковую структуру TLSCiphertext.fragment.
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
Метод генерации MAC следующий:
HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));
seq_num (порядковый номер записи), hash (алгоритм хеширования, указанный SecurityParameters.mac_algorithm)
MAC(код аутентификации сообщения) - код аутентификации сообщения
Обратите внимание, что MAC вычисляется перед шифрованием. Потоковое шифрование шифрует весь блок, включая MAC. Для потоковых шифров, которые не используют векторы синхронизации (например, RC4), состояние потокового шифра с конца одной записи используется только для последующих пакетов. Если CipherSuite имеет значение TLS_NULL_WITH_NULL_NULL, шифрование состоит из операций идентификации (данные не зашифрованы, размер MAC равен нулю, что подразумевает отсутствие использования MAC). TLSCiphertext.length — это TLSCompressed.length плюс CipherSpec.hash_size.
CBC Block Chipher (зашифрованный пакет)
Блочный шифр (такой как RC2 или DES), структура преобразуется в блочную структуру TLSCompressed.fragment TLSCiphertext.fragment
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
заполнение: добавленное заполнение заставляет длину открытого текста быть целым числом, кратным длине блока блочного шифра. Заполнение может быть любой длины до 255 байт, если TLSCiphertext.length является целым числом, кратным длине блока. Длина, превышающая требуемую, предотвращает атаки протокола на основе анализа длины сообщений, которыми обмениваются. Каждый uint8 в векторе данных заполнения должен быть заполнен значением длины заполнения (т. е. padding_length).
padding_length: длина заполнения должна быть такой, чтобы общий размер структуры GenericBlockCipher был кратен длине зашифрованного блока. Допустимые значения варьируются от нуля до 255 (включительно).Длина определяет длину полей заполнения, кроме самого поля padding_length.
Длина данных зашифрованного блока (TLSCiphertext.length) представляет собой сумму TLSCompressed.length, CipherSpec.hash_size и padding_length плюс один.
Пример. Если длина блока составляет 8 байт, длина сжатого содержимого (TLSCompressed.length) — 61 байт, а длина MAC — 20 байт, длина до заполнения — 82 байта (padding_length занимает 1 байт). Итак, чтобы общая длина была кратна длине блока (8 байт), длина заполнения по модулю 8 должна быть равна 6, поэтому длина заполнения может быть 6, 14, 22 и т. д. Если длина заполнения является минимально необходимой, скажем, 6, заполнение будет 6 байтов, и каждый блок будет содержать значение 6. Таким образом, последние 8 октетов GenericBlockCipher перед блочным шифрованием будут xx 06 06 06 06 06 06 06, где xx — последний октет MAC.
XX - 06 06 06 06 06 06 - 06 MAC - padding[6] - padding_length
Рекордная защита полезной нагрузки
Функции шифрования и Mac Преобразуют TLSCompressed структуру в TLSCIFLETEXTEXT. Записанный MAC также включает серийный номер для обнаружения потерь, дополнительных или повторяющихся сообщений.
struct {
ContentType type; // same
ProtocolVersion version; // same
uint16 length; // TLSCiphertext.fragment 的长度，不超过 2^14 + 2048
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment; // TLSCompressed.fragment 的加密形式，带有 MAC
} TLSCiphertext;
Уведомление Упомянутые здесь — это сначала MAC, а затем зашифрованные, которые написаны на основе схемы RFC 2246 (TLS 1.0). Однако новая схема выбирает сначала шифрование, а затем MAC.В этом варианте сначала шифруются открытый текст и заполнение, а затем результат передается алгоритму MAC. Это гарантирует, что активные кибер-злоумышленники не смогут манипулировать зашифрованными данными.
Ключевой расчет
Протокол записи требует алгоритма для генерации ключей из параметров безопасности, предоставляемых протоколом рукопожатия.IVи секрет MAC.
Главный секрет: 48-байтовый ключ, используемый обеими сторонами в соединении. client random: 32-байтовое значение, предоставленное клиентом server random: 32-байтовое значение, предоставленное сервером
5. Слой рукопожатия
- Протокол рукопожатия отвечает за создание общего секретного ключа, необходимого для процесса связи, и выполнение аутентификации. Эта часть не использует набор шифров и обменивается данными с помощью криптографии с открытым ключом или технологии обмена ключами Диффи-Хеллмана, чтобы предотвратить прослушивание данных.
- Протокол изменения спецификации шифра, используемый для синхронизации переключения шифров, является протоколом, следующим за протоколом квитирования. Протокол, используемый в протоколе рукопожатия, представляет собой «незашифрованный» набор шифров, а согласованный набор шифров используется после завершения протокола рукопожатия.
- Протокол предупреждения, который используется для уведомления взаимодействующей стороны в случае возникновения ошибки, такой как исключение во время процесса рукопожатия, неправильный код аутентификации сообщения и невозможность распаковки данных.
- Протокол данных приложения — это протокол для фактической передачи данных приложения между двумя сторонами связи.Процесс передачи передается через протокол данных приложения TLS и протокол записи TLS.
Рукопожатие — самая сложная часть протокола TLS. В этом процессе обе стороны согласовывают параметры подключения и завершают аутентификацию. В зависимости от используемой функции весь процесс обычно требует обмена от 6 до 10 сообщений. Вариантов процесса обмена может быть много, в зависимости от конфигурации и поддерживаемых расширений протокола. Часто используются следующие три процесса: (1) полное рукопожатие, которое аутентифицирует сервер, (2) короткое рукопожатие, которое восстанавливает предыдущий сеанс, (3) процесс, который аутентифицирует и клиента, и сервер. .
Информация заголовка сообщения протокола рукопожатия содержит тип сообщения (1 байт) и длину (3 байта), остальная информация зависит от типа сообщения:
struct {
HandshakeType msg_type;
uint24 length;
HandshakeMessage message;
} Handshake;
5.1 Полное рукопожатие
Каждое TLS-соединение начинается с рукопожатия. Если клиент ранее не устанавливал сеанс с сервером, обе стороны выполняют полное рукопожатие для согласования сеанса TLS. Во время рукопожатия клиент и сервер проходят следующие четыре основных этапа:
- Обменяйтесь их поддерживаемыми функциями и согласуйте необходимые параметры подключения
- Подтвердите представленный сертификат или используйте другие средства аутентификации.
- Согласуйте общий мастер-ключ, который будет использоваться для защиты сеанса.
- Убедитесь, что сообщение рукопожатия не было изменено третьей стороной
Ниже описаны наиболее распространенные правила рукопожатия, рукопожатие, которое не требует аутентификации клиента, но требует аутентификации сервера:
5.1.1 ClientHello
Это сообщение передает серверу возможности и предпочтения клиента.
- Версия: версия протокола (версия протокола) указывает лучшую версию протокола, поддерживаемую клиентом.
- Random: 32-байтовые данные, 28 байтов генерируются случайным образом (Random Bytes на диаграмме); остальные 4 байта содержат дополнительную информацию, связанную с часами клиента (на диаграмме используется GMT Unix Time). Во время рукопожатия и клиент, и сервер предоставляют случайные числа, а приостановка клиента — random_C (для последующей генерации ключа). Эта случайность уникальна для каждого рукопожатия и играет ключевую роль в аутентификации. это предотвращаетповторить атаку, и подтвердите целостность исходного обмена данными.
- Идентификатор сеанса: при первом подключении поле идентификатора сеанса пусто, что означает, что клиент не хочет восстанавливать существующий сеанс. Типичный идентификатор сеанса содержит 32 байта случайно сгенерированных данных, которые обычно генерируются сервером и возвращаются клиенту через ServerHello.
- Наборы шифров: Блок наборов шифров представляет собой список всех наборов шифров, поддерживаемых клиентом, в порядке приоритета.
- Сжатие: клиент может отправить один или несколько методов, поддерживающих сжатие. Метод сжатия по умолчанию равен нулю, что означает отсутствие сжатия.
- Расширения: Блок расширения состоит из любого количества расширений. Эти расширения несут дополнительные данные
5.1.2 ServerHello
заключается в передаче параметров соединения, выбранных сервером, обратно клиенту.
Структура этого сообщения аналогична ClientHello, за исключением того, что каждое поле содержит только одну опцию, которая содержит параметр random_S сервера (для последующего согласования ключа). Серверу не обязательно поддерживать лучшую версию, поддерживаемую клиентом. Если сервер не поддерживает ту же версию, что и клиент, может быть предоставлена какая-то другая версия в расчете на то, что клиент ее примет.
на картинкеCipher SuiteЭто набор шифрования, используемый для последующего согласования ключей и аутентификации.Выбранный здесь алгоритм обмена ключами и подписи — ECDHE_RSA, а алгоритм симметричного шифрования — AES-GCM, который будет обсуждаться позже.
Еще один момент заключается в том, что сжатие TLS по умолчанию отключено, т.к.CRIMEАтаки будут использовать сжатие TLS для восстановления зашифрованных файлов cookie аутентификации для перехвата сеанса и обычно настраивают gzip и другое сжатие контента перед сжатием фрагментов TLS, что нецелесообразно и требует дополнительных ресурсов, поэтому сжатие TLS обычно отключается.
5.1.3 Certificate
Типичное сообщение сертификата используется для переноса сервера X.509.цепочка сертификатов. Сервер должен гарантировать, что отправляемый им сертификат соответствует выбранному набору алгоритмов. Например, алгоритм открытого ключа и алгоритм, используемый в наборе, должны совпадать. Кроме того, некоторые алгоритмы обмена ключами полагаются на определенные данные, встроенные в сертификат, и требуют, чтобы сертификат был подписан с помощью алгоритма, поддерживаемого клиентом. Все это указывает на то, что сервер должен быть настроен с несколькими сертификатами (каждый сертификат может быть оснащен другой цепочкой сертификатов).
Сообщение о сертификате является необязательным, поскольку не все пакеты используют аутентификацию, и не все методы аутентификации требуют сертификата. Кроме того, хотя сообщения по умолчанию используют сертификаты X.509, но также могут нести другие типы признаков, это зависит от количества пакетов.PGP-ключ
5.1.4 ServerKeyExchange
Несут дополнительные данные, необходимые для обмена ключами. ServerKeyExchange является необязательным, и содержимое сообщения отличается для разных наборов алгоритмов согласования. В некоторых сценариях, например при использовании алгоритма RSA, серверу не нужно отправлять это сообщение.
ServerKeyExchange отправляется сервером только в том случае, если сообщение сертификата сервера (также известное как сообщение сертификата выше) не содержит достаточно данных, чтобы позволить клиенту обмениваться предварительным секретом.
Например, в процессе рукопожатия на основе алгоритма DH необходимо отправить отдельное сообщение ServerKeyExchange с параметрами DH:
5.1.5 ServerHelloDone
Указывает, что сервер отправил все ожидаемые сообщения подтверждения. После этого сервер ждет, пока клиент отправит сообщение.
5.1.6 verify certificate
Клиент проверяет действительность сертификата. Если проверка пройдена, будет выполнена последующая связь. В противном случае будут выполняться подсказки и операции в соответствии с различными условиями ошибки. Содержание проверки достоверности включает следующее:
- Надежность пути доверенного сертификата цепочки сертификатов;
- Отзыв отзыва сертификата, есть два способа - CRL в автономном режиме и онлайн OCSP, поведение клиентов будет разным;
- Дата истечения срока действия, находится ли сертификат в допустимом временном диапазоне;
- Домен имени домена, проверьте, соответствует ли имя домена сертификата текущему имени домена доступа;
Зависит отPKI 体系Из содержимого видно, что подпись сертификата, отправленная одноранговой стороной, зашифрована закрытым ключом ЦС.После получения сертификата сначала прочитайте соответствующую информацию открытого текста в сертификате, используйте ту же хеш-функцию для вычисления дайджеста информации, а затем использовать соответствующий ЦС Открытый ключ расшифровывает данные подписи и сравнивает информационный дайджест сертификата.Если они непротиворечивы, можно подтвердить действительность сертификата, затем проверить отзыв сертификата и т. д.
5.1.7 ClientKeyExchange
После прохождения проверки валидности клиент вычисляет и генерирует предварительное мастер-ключ (Pre-master) со случайным числом, шифрует его с помощью открытого ключа сертификата и отправляет на сервер со всей информацией, предоставленной клиентом для обмена ключами. . На это сообщение влияет набор согласованных шифров, и его содержимое зависит от разных наборов согласованных шифров.
На этом этапе клиент получил всю информацию, необходимую для расчета ключа согласования: два случайных числа открытого текста random_C и random_S и Pre-master, сгенерированный собственным вычислением, а затем получил согласованный ключ (для последующего шифрования сообщения).
enc_key = PRF(Pre_master, "master secret", random_C + random_S)
Алгоритм FIG используется ECDHE, параметры клиента ClientKeyExchange передаются алгоритму DH, если используется алгоритм RSA, здесь должен быть передан предварительно зашифрованный мастер-ключ
5.1.8 ChangeCipherSpec
Уведомление сервера о последующей связи с использованием согласованных ключей связи и алгоритмов шифрования для зашифрованной связи.
Уведомление ChangeCipherSpec не относится к сообщению рукопожатия, это другой протокол только с одним сообщением, которое реализовано как его подпротокол.
5.1.9 Finished (Encrypted Handshake Message)
Сообщение Finished означает, что рукопожатие завершено. Содержимое сообщения шифруется, чтобы обе стороны могли безопасно обмениваться данными, необходимыми для проверки целостности всего рукопожатия.
Это сообщение содержит поле verify_data, значение которого представляет собой хэш всех сообщений во время рукопожатия. Эти сообщения находятся в том порядке, в котором они видят его на обоих концах соединения, и хэшируются с помощью согласованного главного ключа (enc_key). Этот процесс осуществляется с помощью псевдослучайной функции (PRF), которая может генерировать любое количество псевдослучайных данных. Метод расчета одинаков на обоих концах, но используются разные метки (finished_label): клиент использует завершение клиента, а сервер использует завершение сервера.
verify_data = PRF(master_secret, finished_label, Hash(handshake_messages))
Поскольку сообщения Finished зашифрованы, а их целостность гарантируется согласованным алгоритмом MAC, активный сетевой злоумышленник не может изменить сообщение рукопожатия и фальсифицировать значение vertify_data. В TLS 1.2 длина сообщения Finished по умолчанию составляет 12 байт (96 бит), а для наборов шифров разрешены более длинные длины. Предыдущие версии использовали 12-байтовые сообщения фиксированной длины, за исключением SSL 3, в котором использовались 36-байтовые сообщения фиксированной длины.
5.1.10 Server
Сервер расшифровывает зашифрованные данные Pre-master с помощью закрытого ключа, а также вычисляет согласованный ключ на основе двух случайных чисел открытого текста random_C и random_S, которыми обменивались ранее:enc_key = PRF(Pre_master, "master secret", random_C + random_S);
Также вычислить хэш-значение всех ранее отправленных и полученных сообщений, а затем расшифровать файл verify_data_C, отправленный клиентом с согласованным ключом, чтобы проверить правильность сообщения;
5.1.11 change_cipher_spec
После того, как проверка на стороне сервера пройдена, сервер также отправляет change_cipher_spec, чтобы проинформировать клиента о том, что последующая связь зашифрована с помощью согласованного ключа и алгоритма (на рисунке есть еще один новый билет сеанса, который является билетом сеанса, который будет объясняется в сеансе восстановления) ;
5.1.12 Finished (Encrypted Handshake Message)
Сервер также объединяет всю текущую информацию о параметрах связи, чтобы сгенерировать часть данных (verify_data_S), зашифровать ее с помощью согласованного секрета сеанса ключа (enc_key) и алгоритма и отправить ее клиенту;
5.1.13 Окончание рукопожатия
Клиент вычисляет хеш-значение всей полученной информации, расшифровывает verify_data_S с помощью согласованного ключа, проверяет данные и ключ, отправленные сервером, и завершает рукопожатие, если проверка пройдена;
5.1.14 Зашифрованная связь
Начните зашифрованную связь с использованием согласованных ключей и алгоритмов.
5.2 Ключевым обменом и алгоритмами подписи
Часто используемые алгоритмы обмена ключами и подписи
HTTPS обеспечивает три функции: шифрование контента, аутентификацию и целостность данных через уровень TLS и механизм сертификатов. В процессе шифрования используются два алгоритма: асимметричный обмен ключами и симметричное шифрование содержимого.
Сила шифрования симметричного контента очень высока, скорость шифрования и дешифрования также высока, но невозможно безопасно генерировать и хранить ключи. В протоколе TLS окончательные данные приложения передаются после симметричного шифрования, а симметричный ключ согласования (enc_key выше), используемый при передаче, получается путем обмена асимметричным ключом на этапе установления связи. Общие AES-GCM и ChaCha20-Poly1305 являются алгоритмами симметричного шифрования.
Обмен асимметричным ключом может генерировать симметричный ключ шифрования, известный только взаимодействующим сторонам в незащищенном канале данных. Наиболее часто используемые алгоритмы обмена ключами — RSA и ECDHE.
RSA имеет долгую историю и хорошую поддержку, но не поддерживаетсяИдеальная секретность пересылки — PFS (совершенная секретность пересылки); и ECDHE — это алгоритм DH (Diffie-Hellman), использующий ECC (эллиптическая кривая), который быстр в вычислениях и поддерживает PFS.
существуетPKI 体系В разделе поясняется, что только обмен асимметричным ключом не может противостоять MITM-атакам, поэтому для аутентификации необходимо ввести сертификат системы PKI, в котором открытый ключ, сгенерированный асимметричным шифрованием сервера, будет помещен в сертификат и передается на клиентский конец.
При обмене ключами RSA браузер использует открытый ключ RSA, предоставленный сертификатом, для шифрования соответствующей информации.Если сервер может его расшифровать, это означает, что сервер имеет закрытый ключ, соответствующий открытому ключу, а также может вычислить ключ требуется для симметричного шифрования. Обмен ключами и аутентификация на стороне сервера объединены.
При обмене ключами ECDH сервер использует закрытый ключ (RSA или ECDSA) для подписи соответствующей информации. Если браузер может проверить подпись с помощью открытого ключа сертификата, это означает, что сервер имеет соответствующий закрытый ключ, таким образом завершая аутентификация сервера. Обмен ключами завершается отправкой параметров DH отдельно, а обмен ключами и аутентификация сервера полностью разделены.
Алгоритмы, которые можно использовать для цифровых подписей ECDHE, в основном следующие:RSAиECDSA — Алгоритм цифровой подписи на основе эллиптических кривых, то есть на данный момент существует три основных варианта обмена ключами + подпись:
-
RSA- Обмен ключами RSA (подпись не требуется) -
ECDHE_RSA- Обмен ключами ECDHE, подпись RSA -
ECDHE_ECDSA- Обмен ключами ECDHE, подпись ECDSA
Например, на моем веб-сайте используется набор шифрования ECDHE_RSA.Вы можете видеть, что алгоритм цифровой подписи представляет собой хэш sha256 плюс шифрование RSA.PKI 体系В разделе подпись создается путем шифрования хеш-значения дайджеста информации о сервере.
Сертификат со встроенным открытым ключом ECDSA обычно называется сертификатом ECC, а сертификат со встроенным открытым ключом RSA — сертификатом RSA. Поскольку 256-битный ключ ECC эквивалентен 3072-битному ключу RSA в плане безопасности, сертификат ECC меньше сертификата RSA, а скорость работы ECC выше, обмен ключами ECDHE + цифровая подпись ECDSA в настоящее время является лучшим набором шифрования.
Вышеизложенное взято из этой статьи:Начните работу с сертификатами ECC
Подробнее о сертификатах ECC можно прочитать в документации:ECC Cipher Suites for TLS - RFC4492
Разница между обменом ключами RSA и обменом ключами DH
Процесс рукопожатия с использованием RSA для обмена ключами в основном аналогичен предыдущему описанию, за исключением того, что отсутствует сообщение ServerKeyExchange, в котором согласованный ключ включает три параметра (client random_C, server random_S, premaster secret), Первые два случайных числа и алгоритм, используемый в согласовании, представлены в виде обычного текста и их легко получить.Последний секрет Premaster будет зашифрован с помощью открытого ключа, предоставленного сервером, и передан на сервер (обмен ключами).Если premaster секрет перехвачен и взломан. Тогда можно взломать и согласованный ключ.
Подробнее об алгоритме RSA см.wikiиПринцип алгоритма RSA (2) - Руан Ифэн
Основная идея алгоритма RSA заключается в использовании чрезвычайно больших целых чисел.факторизацияВычислительная сложность
при использованииАлгоритм DH (Диффи-Хеллмана)Для обмена ключами обеим сторонам нужно только обменять свои собственные параметры DH (отправить параметры сервера в ServerKeyExchange и отправить параметры клиента в ClientKeyExchange), не передавая секрет Premaster, они могут вычислить pre-master ключ отдельно.
Процесс рукопожатия DH выглядит следующим образом.Общий процесс аналогичен процессу RSA.На рисунке показано только, как сгенерировать предварительный мастер-ключ:
Сервер использует закрытый ключ для подписи случайного числа клиента random_C, случайного числа сервера random_S и параметра DH сервера. Параметры сервера для создания подписи, а затем отправляет параметр DH сервера и подпись в сообщении ServerKeyExchange;
После того, как клиент его получает, он расшифровывает и проверяет подпись с помощью открытого ключа, предоставленного сервером, и отправляет параметр клиента DH Client params в сообщении ClientKeyExchange;
После того, как сервер получает его, обе стороны имеют эти два параметра, а затем используют эти два параметра для создания предварительного секрета.Последующие шаги, такие как согласование ключа, в основном такие же, как RSA.
Самая большая разница между рукопожатием на основе алгоритма RSA и алгоритмом DH заключается в обмене ключами и аутентификации личности. Первый клиент использует открытый ключ для шифрования предварительного главного ключа и отправляет его на сервер для завершения обмена ключами, а сервер использует закрытый ключ для расшифровки для завершения аутентификации личности. Последний использует параметры DH, отправленные каждым из них, для завершения обмена ключами, закрытый ключ сервера подписывает данные, а открытый ключ клиента проверяет подпись для завершения аутентификации личности.
О том, как алгоритм DH генерирует предварительный мастер-ключ, рекомендуется прочитать следующее.WikiиEphemeral Diffie-Hellman handshake
Его ядро мышление должно использоватьпроблема с дискретным логарифмомВычислительная сложность
Первообразный корень: если предположить, что целое число g является первообразным корнем для простого числа P, то результаты g^i mod P (1 ≦ i пример
Дискретные логарифмы: если для целого числа n и первообразного корня g простого числа P можно найти уникальный показатель степени i, такой что n = g^i mod P (0 ≦ i
Эффективность алгоритма Диффи-Хеллмана зависит от сложности вычисления дискретных логарифмов, а это означает, что когда известно большое простое число P и один из его первообразных корней g, вычисление i для заданного n считается очень сложным. в то время как относительно легко вычислить n при заданном i
Процесс алгоритма может быть абстрагирован на следующий рисунок:
Обе стороны предварительно согласовали пару значений Pg (общедоступных), у Алисы есть приватный номер a (непубличный, соответствующий приватному ключу), у Боба есть приватный номер b (непубличный, соответствующий приватному ключу). ключ)
-
Алиса вычисляет A = g^a mod P и отправляет A (открытый, соответствующий открытому ключу) Бобу.
-
Боб вычисляет B = g^b mod P и отправляет B (открытый, соответствующий открытому ключу) Алисе.
-
Обе стороны вычисляют общий ключ, K = B^a mod P = A^b mod P (= g^ab mod P)
Для Алисы и Боба окончательный ключ может быть получен через параметры открытого ключа, отправленные другой стороной, и закрытый ключ в их собственных руках.
Третья сторона знает самое большее P g AB, и получить закрытый ключ и окончательный ключ очень сложно.Конечно, предпосылка состоит в том, что ab P достаточно велико (в документе RFC3526 есть несколько часто используемых больших простых чисел для использования), в противном случае также можно попробовать взлом методом грубой силы. Ответ, как и для g, обычно принимает меньшее значение
Следующие изображения представляют собой содержимое, отправленное фактическим рукопожатием DH:
Видно, что параметры, отправляемые обеими сторонами друг другу, несут значение открытого ключа, соответствующее вышеуказанным A и B.
И фактически используемый набор шифровОбмен ключами DH на эллиптических кривых (ECDH), использование шифрования на основе эллиптических кривых для установления пары открытого и закрытого ключей может дополнительно усилить безопасность DH, поскольку решить проблему дискретного логарифмирования на эллиптических кривых сложнее, чем факторинг, а длина ключа, используемого ECC, больше, чем шифрования RSA. Гораздо более короткие ключи (в настоящее время для защиты ключей RSA требуется более 2048 бит, а для ключей ECC достаточно 256 бит).
оКриптография на эллиптических кривых — ECC, рекомендуется посмотретьУчебник по криптографии на основе эллиптических кривых — оригинал - перевод
5.3 Аутентификация клиента
Хотя вы можете выбрать либо конец для аутентификации, но это практически все аутентификация включена на сервере. Если сервер выбирает пакет не является анонимным, то вам нужно идти в ногу со своим собственным сертификатом в сообщении сертификата.
Напротив, сервер запрашивает аутентификацию клиента, отправляя сообщение CertificateRequest. Все допустимые клиентские сертификаты перечислены в сообщении. В ответ клиент отправляет собственное сообщение сертификата (в том же формате, в котором сервер отправил сертификат) с прикрепленным сертификатом. После этого клиент отправляет сообщение CertificateVerify, чтобы доказать, что у него есть соответствующий закрытый ключ.
Только аутентифицированные серверы могут запрашивать аутентификацию клиента. По этой причине этот вариант также известен как взаимная проверка подлинности.
5.3.1 CertificateRequest
Выдается во время ServerHello, запрашивая аутентификацию клиента и передавая открытый ключ и алгоритм подписи сертификата, который он принимает, клиенту.
Он также может дополнительно отправить список принимаемых им центров сертификации, представленных их отличительными именами:
struct {
ClientCertificateType certificate_types;
SignatureAndHashAlgorithm supported_signature_algorithms;
DistinguishedName certificate_authorities;
} CertificateRequest;
5.3.2 CertificateVerify
Отправляется во время ClientKeyExchange, чтобы доказать, что ваш закрытый ключ соответствует открытому ключу в сертификате клиента, отправленном ранее. Сообщение содержит подпись для всех сообщений рукопожатия до этого момента:
struct {
Signature handshake_messages_signature;
} CertificateVerify;
5.4 Восстановление сеанса
Оригинальный механизм восстановления сеанса заключался в том, что клиент, и сервер сохранят параметры безопасности сеанса в течение определенного периода времени, когда полностью согласованное соединение было отключено. Серверы, которые хотят использовать восстановление сеанса, назначают уникальный идентификатор на сеанс, называемый идентификатором сеанса. Сервер отправляет идентификатор сеанса обратно на клиент в сообщении ServerHello.
Клиент, желающий возобновить предыдущий сеанс, помещает соответствующий идентификатор сеанса в сообщение ClientHello и отправляет. Если сервер соглашается возобновить сеанс, он возвращает тот же идентификатор сеанса в сообщении ServerHello, затем использует ранее согласованный главный ключ для создания нового набора ключей, переключается в режим шифрования и отправляет сообщение Finished. Клиент делает то же самое после получения сообщения о возобновлении сеанса. Результатом этого является то, что для рукопожатия требуется только один круговой обход сети.
Идентификатор сеанса поддерживается сервером и является стандартным полем в протоколе, поэтому его поддерживают практически все серверы.Сервер сохраняет идентификатор сеанса и согласованную информацию о связи, которая занимает много ресурсов сервера.
Альтернативой кэшированию и восстановлению сеанса сервера является использование сеансовых билетов. Таким образом, поток сообщений аналогичен кэшу сеанса сервера, за исключением того, что все состояние сохраняется на стороне клиента (аналогично принципу файлов cookie HTTP).
Идея состоит в том, что сервер берет все свои данные сеанса (состояние), шифрует их (ключ известен только серверу) и отправляет обратно клиенту в виде билета. При последующих подключениях клиент возобновляет сеанс вПоля расширения для ClientHelloSession_ticket несет зашифрованную информацию о зашифрованной билете будет отправлен обратно на сервер, сервер проверяет целостность билета, чтобы расшифровать его содержимое, а затем использовать информацию для восстановления сеанса.
Такой подход может упростить масштабирование серверных кластеров, поскольку в противном случае сеансы необходимо будет синхронизировать между узлами сервисного кластера. Сессионные билеты должны поддерживаться как сервером, так и клиентом, они относятся к расширенному полю и занимают очень мало ресурсов сервера.
предупреждать Билеты сеанса нарушают модель безопасности TLS. Он использует зашифрованное состояние сеанса ключа билета и предоставляет его по сети. В некоторых реализациях ключ билета может быть слабее, чем шифр, используемый для соединения. Если ключ билета раскрыт, все данные о соединении могут быть расшифрованы. Следовательно, при использовании сеансовых билетов ключ билета необходимо часто менять.
References
- RFC 2246 - The TLS Protocol Version 1.0
- NPN/ALPN - wiki
- TLS - wiki
- SSL/TLS in detail
- Подробное объяснение протокола шифрования HTTPS
- Keyless SSL: The Nitty Gritty Technical Details
- DSA — алгоритм цифровой подписи
- Полное руководство по HTTPS — развертывание SSL/TLS и PKI на серверах и в веб-приложениях