Tls рукопожатие что это

TLS Handshake : Under The Hood

TLS which is the successor of SSL is a protocol that provides a secure mechanism for authentication using x509 certificates. It also provides a two-way encrypted channel between two parties. Two way encryption means that TLS client can encrypt data to unreadable form and upon receiving, TLS server can decrypt it back to readable form such that any third party entity cannot eavesdrop on the conversation.

The TLS specification defines two protocols — The record protocol and the handshake protocol. Out of them, the handshake protocol is used to negotiate and set up a secure, encrypted channel between the client and the server. This helps in achieving both confidentiality and authenticity among the two parties by allowing them to verify each other, negotiate cipher suites and other parameters required to establish a secure connection.

The handshake protocol involves four sets of messages that are exchanged between the client and server before establishing the encrypted communication channel as depicted in the diagram below. Each set is typically transmitted in a separate TCP segment.

Client — ClientHello

The handshake is initiated when the client sends a ‘ClientHello’ message. The most important elements in this message are as follows.

TLS version used by the client
Cipher suites that the client supports
List of compression methods
List of extensions
A random string that will be used later for generating cryptographic keys

The cipher suite consists of a code that represents four parameters: the authentication algorithm, key exchange method, encryption cipher and hashing algorithm. The client lists these cipher suites in its preferred order. Furthermore, instead of authenticating each time, client can restart a previous session through the inclusion of a ‘SessionId’ field.

Server — ServerHello

The server replies to client with a ‘ServerHello’ message, which contains its choice of cipher from the client’s…

TCP and TLS Handshaking

I have a customer and they have a client which connects to our provided server. While others can connect to the server seamlessly, this client cannot connect in any way.

So I told them to make sure that their client can ping, telnet and openssl to the server. Everything seems OK. So it is time for me to take responsibility.

I collected the client debug logs and reviewed the sever side debug logs. I found that client’s logs suggested that An existing connection was forcibly closed by the remote host , and the error number is 10054 . In the server side, the debug logs showed that a connection is broken.

I searched in the Internet and found that there are many reasons for this error:

You are sending malformed data to the application
The network link between the client and server is going down for some reason
You have triggered a bug in the third-party application that caused it to crash
The third-party application has exhausted system resources

However, I don’t think any of these cause my situation because all things seemed work OK.

In the end, I had to seek help from lower layer information. I used TCPDUMP to collection some information. Luckily, after comparing the broken connection and correct ones, I found something quite strange.

Usually, after three steps’ handshaking, a client will send a client hello to the server, like this:

But for the broken ones, client will send [RST ACK] after the basic three steps’ handshaking.

Quite strange. Most situations in the internet are like this: the connection is closed or reseted by the server . So when a client chose to close the connection, it is quite abnormal.

I seek help from my network colleagues. And she suggested me that, from the pcap file, it shows that the TCP connection is OK, but when it comes to application protocol, it gets wrong. There maybe some security policy in the client side, for example, URL blocking. So when the three steps’ handshaking is been done, the connection will be closed immediately.

I verified it by putting a URL blocking device in front or the client, and the connection is reseted after handshaking, that’s wonderful!

So next I will have some notes about what happens during TCP and TLS handshaking.

2. TCP handshaking

The first host (Client) sends the second host (Server) a "synchronize" (SYN) message with its own sequence number x, which Server receives.
Server replies with a synchronize-acknowledgment (SYN-ACK) message with its own sequence number y and acknowledgement number x+1, which Client receives.
Client replies with an acknowledgment (ACK) message with acknowledgement number y+1, which Server receives and to which he doesn’t need to reply.

3. TLS handshaking

TLS is an application layer protocol, it is beyond TCP. So everything related to TLS are happened after basic TCP handshaking.

3.1. Basic TLS handshake

Negotiation phase:

A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and suggested compression methods . If the client is attempting to perform a resumed handshake, it may send a session ID. If the client can use Application-Layer Protocol Negotiation, it may include a list of supported application protocols, such as HTTP/2.
The server responds with a ServerHello message, containing the chosen protocol version, a random number, CipherSuite and compression method from the choices offered by the client . To confirm or allow resumed handshakes the server may send a session ID. The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS version 1.1 and the server supports version 1.2, version 1.1 should be selected; version 1.2 should not be selected.
The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).
The server sends its ServerKeyExchange message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE and DH_anon ciphersuites.
The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.
The client and server then use the random numbers and PreMasterSecret to compute a common secret , called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.

The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The ChangeCipherSpec is itself a record-level protocol with content type of 20.

Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages.
The server will attempt to decrypt the client’s Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.

Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated)."

The server sends its authenticated and encrypted Finished message.
The client performs the same decryption and verification procedure as the server did in the previous step.

Application phase:

3.2. Resumed TLS handshake

Public key operations (e.g., RSA) are relatively expensive in terms of computational power. TLS provides a secure shortcut in the handshake mechanism to avoid these operations: resumed sessions. Resumed sessions are implemented using session IDs or session tickets.

Apart from the performance benefit, resumed sessions can also be used for single sign-on, as it guarantees that both the original session and any resumed session originate from the same client. This is of particular importance for the FTP over TLS/SSL protocol, which would otherwise suffer from a man-in-the-middle attack in which an attacker could intercept the contents of the secondary data connections.

Session IDs

In an ordinary full handshake, the server sends a session id as part of the ServerHello message. The client associates this session id with the server’s IP address and TCP port, so that when the client connects again to that server, it can use the session id to shortcut the handshake. In the server, the session id maps to the cryptographic parameters previously negotiated, specifically the "master secret". Both sides must have the same "master secret" or the resumed handshake will fail (this prevents an eavesdropper from using a session id). The random data in the ClientHello and ServerHello messages virtually guarantee that the generated connection keys will be different from in the previous connection. In the RFCs, this type of handshake is called an abbreviated handshake. It is also described in the literature as a restart handshake.

Что такое TLS-рукопожатие и как оно устроено

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

Один из ключевых аспектов протокола — это рукопожатие. Именно о нём мы поговорим в этой статье.

«Рукопожатие SSL/TLS» — это название этапа установки HTTPS-соединения. Большая часть работы, связанной с протоколом SSL/TLS, выполняется именно на этом этапе. В прошлом году IETF доработал TLS 1.3, полностью обновив процесс рукопожатия.
В статье будут освещены два вида рукопожатия — для протоколов TLS 1.2 и TLS 1.3, которые мы рассмотрим, начиная с абстрактного уровня и постепенно углубляясь в особенности:

согласование криптографических протоколов;
аутентификация с помощью SSL-сертификата;
генерация сеансового ключа.

Как происходит TLS-рукопожатие

В 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 1.2

Рассмотрим TLS-рукопожатие с использованием RSA подробнее. Использование алгоритма Диффи-Хеллмана будет описано ниже.

Первое сообщение называется «Client Hello». В этом сообщении перечислены возможности клиента, чтобы сервер мог выбрать шифронабор, который будет использовать для связи. Также сообщение включает в себя большое случайно выбранное простое число, называемое «случайным числом клиента».
Сервер вежливо отвечает сообщением «Server Hello». Там он сообщает клиенту, какие параметры соединения были выбраны, и возвращает своё случайно выбранное простое число, называемое «случайным числом сервера». Если клиент и сервер не имеют общих шифронаборов, то соединение завершается неудачно.
В сообщении «Certificate» сервер отправляет клиенту свою цепочку SSL-сертификатов, включающую в себя листовой и промежуточные сертификаты. Получив их, клиент выполняет несколько проверок для верификации сертификата. Клиент также должен убедиться, что сервер обладает закрытым ключом сертификата, что происходит в процессе обмена/генерации ключей.
Это необязательное сообщение, необходимое только для определённых методов обмена ключами (например для алгоритма Диффи-Хеллмана), которые требуют от сервера дополнительные данные.
Сообщение «Server Hello Done» уведомляет клиента, что сервер закончил передачу данных.
Затем клиент участвует в создании сеансового ключа. Особенности этого шага зависят от метода обмена ключами, который был выбран в исходных сообщениях «Hello». Так как мы рассматриваем RSA, клиент сгенерирует случайную строку байтов, называемую секретом (pre-master secret), зашифрует её с помощью открытого ключа сервера и передаст обратно.
Сообщение «Change Cipher Spec» позволяет другой стороне узнать, что сеансовый ключ сгенерирован и можно переключиться на зашифрованное соединение.
Затем отправляется сообщение «Finished», означающее, что на стороне клиента рукопожатие завершено. С этого момента соединение защищено сессионным ключом. Сообщение содержит данные (MAC), с помощью которых можно убедиться, что рукопожатие не было подделано.
Теперь сервер расшифровывает pre-master secret и вычисляет сеансовый ключ. Затем отправляет сообщение «Change Cipher Spec», чтобы уведомить, что он переключается на зашифрованное соединение.
Сервер также отправляет сообщение «Finished», используя только что сгенерированный симметричный сеансовый ключ, и проверяет контрольную сумму для проверки целостности всего рукопожатия.

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

На этом этапе могут быть отправлены первые байты веб-приложения (данные, относящиеся к фактическому сервису, — HTML, Javascript и т. д.).

Пошаговый процесс рукопожатия в TLS 1.3

Рукопожатие TLS 1.3 значительно короче, чем его предшественник.

Как и в случае TLS 1.2, сообщение «Client Hello» запускает рукопожатие, но на этот раз оно содержит гораздо больше информации. TLS 1.3 сократил число поддерживаемых шифров с 37 до 5. Это значит, что клиент может угадать, какое соглашение о ключах или протокол обмена будет использоваться, поэтому в дополнение к сообщению отправляет свою часть общего ключа из предполагаемого протокола.
Сервер ответит сообщением «Server Hello». Как и в рукопожатии 1.2, на этом этапе отправляется сертификат. Если клиент правильно угадал протокол шифрования с присоединёнными данными и сервер на него согласился, последний отправляет свою часть общего ключа, вычисляет сеансовый ключ и завершает передачу сообщением «Server Finished».
Теперь, когда у клиента есть вся необходимая информация, он верифицирует SSL-сертификат и использует два общих ключа для вычисления своей копии сеансового ключа. Когда это сделано, он отправляет сообщение «Client Finished».

Издержки TLS-рукопожатия

Исторически одна из претензий к SSL/TLS заключалась в том, что он перегружал серверы дополнительными издержками. Это повлияло на ныне несуществующее представление, что HTTPS медленнее, чем HTTP.

Рукопожатия до TLS 1.2 требовали много ресурсов и в больших масштабах могли серьёзно нагрузить сервер. Даже рукопожатия TLS 1.2 могут замедлить работу, если их происходит много в один момент времени. Аутентификация, шифрование и дешифрование — дорогие процессы.

На небольших веб-сайтах это скорее всего не приведёт к заметному замедлению работы, но для корпоративных систем, куда ежедневно приходят сотни тысяч посетителей, это может стать большой проблемой. Каждая новая версия рукопожатия существенно облегчает процесс: TLS 1.2 совершает две фазы, а TLS 1.3 укладывается всего в одну и поддерживает 0-RTT.

Улучшения рукопожатия TLS 1.3 по сравнению с TLS 1.2

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

У рукопожатия TLS 1.2 можно выделить две фазы. Иногда могут потребоваться дополнительные, но когда речь идёт о количестве, по умолчанию подразумевается оптимальный сценарий.

В отличие от 1.2, рукопожатие TLS 1.3 укладывается в одну фазу, хотя вернее будет сказать в полторы, но это всё равно значительно быстрее, чем TLS 1.2.

Сокращение шифронаборов

Никто никогда не собирался использовать 37 наборов для шифрования данных, так эволюционировал протокол. Каждый раз, когда добавлялся новый алгоритм, добавлялись новые комбинации, и вскоре IANA администрировала 37 различных шифронаборов.

Это плохо по двум причинам:

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

IETF исключил в TLS 1.3 поддержку всех алгоритмов, кроме самых безопасных, убирая путаницу за счёт ограничения выбора. В частности, был убран выбор метода обмена ключами. Эфемерная схема Диффи-Хеллмана стала единственным способом, позволяющим клиенту отправить информацию о своём ключе вместе с «Client Hello» в первой части рукопожатия. Шифрование RSA было полностью удалено вместе со всеми другими схемами обмена статическими ключами.

При этом есть одна потенциальная ахиллесова пята в TLS 1.3.

Нулевое время возобновления приёма-передачи — 0-RTT

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.

Шифронаборы TLS-рукопожатия

Шифронабор — это набор алгоритмов, определяющих параметры безопасного соединения.

В начале любого соединения самое первое взаимодействие, «Client Hello», представляет собой список поддерживаемых шифронаборов. Сервер выбирает лучший, наиболее безопасный вариант, который поддерживается им и отвечает его требованиям. Вы можете посмотреть на шифронабор и выяснить все параметры рукопожатия и соединения.

Шифронаборы TLS 1.2

TLS — протокол.
ECDHE — алгоритм обмена ключами.
ECDSA — алгоритм аутентификации.
AES 128 GCM — алгоритм симметричного шифрования.
SHA256 — алгоритм хеширования.

В приведённом выше примере используется эфемерная система Диффи-Хеллмана (DH) с эллиптической кривой для обмена ключами и алгоритм цифровой подписи эллиптической кривой для аутентификации. DH также может быть соединен с RSA (функционирующим как алгоритм цифровой подписи) для выполнения аутентификации.

Вот список наиболее широко поддерживаемых шифронаборов TLS 1.2:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384;
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA;
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA;
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA;
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA;
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384;
TLS_DHE_RSA_WITH_AES_128_CBC_SHA;
TLS_DHE_RSA_WITH_AES_256_CBC_SHA;
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256.

Шифронаборы TLS 1.3

TLS — протокол.
AES 256 GCM — алгоритм аутентифицированного шифрования с присоединёнными данными (AEAD).
SHA384 — алгоритм функции формирования хешированного ключа (HKFD).

Мы уже знаем, что будем использовать какую-то версию обмена эфемерными ключами Диффи-Хеллмана, но не знаем параметров, так что первые два алгоритма в шифронаборе TLS 1.2 больше не нужны. Эти функции всё ещё выполняются, их просто больше не нужно согласовывать во время рукопожатия.

Из приведённого выше примера видно, что используется AES (Advanced Encryption Standard) для шифрования большого объёма данных. Он работает в режиме счётчика Галуа с использованием 256-битных ключей.

Вот пять шифронаборов, которые поддерживаются в TLS 1.3:

TLS_AES_256_GCM_SHA384;
TLS_CHACHA20_POLY1305_SHA256;
TLS_AES_128_GCM_SHA256;
TLS_AES_128_CCM_8_SHA256;
TLS_AES_128_CCM_SHA256.

Что изменилось в TLS 1.3 по сравнению с TLS 1.2?

Важно помнить, что при создании версии 1.3 главным было повышение безопасности и производительности. Для этого в TLS 1.3 был переработан алгоритм генерация ключей и исправлены известные уязвимости.

В рукопожатии TLS 1.3 также стали лучше некоторые процессы, например аутентификация сообщений и цифровые подписи.

Наконец, в дополнение к постепенному отказу от старых алгоритмов генерации ключей или обмена ими, TLS 1.3 устраняет старые симметричные шифры. В TLS 1.3 полностью исключили блочные шифры. Единственный разрешённый в TLS 1.3 тип симметричных шифров называется шифрованием с проверкой подлинности с использованием дополнительных данных (AEAD). Он объединяет шифрование и проверку подлинности сообщений (MAC) в одну функцию.

Аутентификация в TLS-рукопожатии

Исторически двумя основными вариантами обмена ключами являются RSA и Диффи-Хеллман (DH), в наши дни DH часто ассоциируется с эллиптическими кривыми (ECDH). Несмотря на некоторые основные сходства, между этими двумя подходами к обмену ключами есть фундаментальные различия.

Иными словами, TLS-рукопожатие RSA отличается от TLS-рукопожатия ECDH.

RSA использует простую факторизацию и модульную арифметику. Большие простые числа требуют много ресурсов процессора при вычислениях и их сложно подобрать.

Диффи-Хеллмана иногда называют экспоненциальным обменом ключами, что указывает на возведение в степень (в дополнение к модульной арифметике), но на самом деле сам DH вообще ничего не шифрует и не дешифрует. Поэтому называть его «методом шифрования» вместо «математического обоснования» может быть немного неверно.

Небольшой экскурс в историю может пояснить этот момент.

Ещё в 1976 году Уитфилд Диффи и Мартин Хеллман создали протокол обмена ключами, основанный на работе Ральфа Меркля, чьё имя, по мнению обоих, должно также присутствовать в названии протокола.

Они пытались решить проблему безопасного обмена ключами по незащищённому каналу, даже если злоумышленник прослушивает его. У них получилось, но был один серьёзный недостаток: обмен ключами DH не включал в себя проверку подлинности, поэтому не было возможности проверить сторону на другом конце соединения.

Это можно считать рождением криптографии с открытым ключом и ИОК. Вскоре после того, как Диффи и Хеллман представили свой протокол обмена ключами, были завершены самые ранние версии криптосистемы RSA. Диффи и Хеллман создали концепцию шифрования с открытым ключом, но ещё не придумали саму функцию одностороннего шифрования.

Именно Рон Ривест (R в RSA) создал концепцию, которая в итоге стала криптосистемой RSA.

Во многих отношениях RSA является духовным преемником DH. Он осуществляет:

генерацию ключей;
обмен ключами;
шифрование;
дешифрование.

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

В то время как RSA осуществляет аутентификацию и обмен ключами, Диффи-Хеллман только облегчает обмен ключами. Существует четыре распространённых варианта семейства DH:

Диффи-Хеллман (DH);
эфемерный (краткосрочный) Диффи-Хеллман (DHE);
эллиптическая кривая Диффи-Хеллмана (ECDH);
эллиптическая кривая эфемерного Диффи-Хеллмана (ECDHE).

Опять же, Диффи-Хеллман сам по себе ничего не аутентифицирует. Его нужно использовать в паре с алгоритмом цифровой подписи. Так, например, если вы использовали ECDH или ECDHE, большинство шифронаборов будут сопряжены с алгоритмом цифровой подписи эллиптической кривой (ECDSA) или RSA.

Аутентификация в рукопожатии TLS 1.2

Как было только что сказано, дополнительная функциональность RSA для аутентификации с помощью цифровых подписей требует больших ключей, устойчивых к атакам перебором. Размер этих ключей сильно увеличивает затраты на их вычисление, шифрование и дешифрование во время рукопожатия.

С другой стороны, если Диффи-Хеллман не выполняет аутентификацию, то что он делает? Как было сказано выше, DH часто используют совместно с криптографией на основе эллиптических кривых, чтобы обеспечить аутентификацию и обмен ключами.

Эллиптическая криптография (ECC) имеет гораздо меньшие размеры ключей, которые соответствуют эллиптической кривой, на которой они основаны. Для этого контекста есть пять подходящих кривых:

192 бит;
224 бита;
256 бит;
384 бит;
521 бит.

Но это не единственное различие между открытыми/закрытыми ключами ECC и ключами RSA. Они используются для двух совершенно разных целей во время рукопожатия TLS.

В RSA пара открытый/закрытый ключ используется как для проверки подлинности сервера, так и для обмена симметричным ключом сеанса. Фактически, именно успешное использование секретного ключа для расшифровки секрета (pre-master secret) аутентифицирует сервер.

С Диффи-Хеллманом пара открытый/закрытый ключ НЕ используется для обмена симметричным сеансовым ключом. Когда задействован Диффи-Хеллман, закрытый ключ фактически связан с прилагаемым алгоритмом подписи (ECDSA или RSA).

RSA-аутентификация

Процесс RSA-аутентификации связан с процессом обмена ключами. Точнее обмен ключами является частью процесса аутентификации.

Когда клиенту предоставляется SSL-сертификат сервера, он проверяет несколько показателей:

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

Если все эти проверки прошли, то проводится последний тест — клиент шифрует pre-master secret с помощью открытого ключа сервера и отправляет его. Любой сервер может попытаться выдать любой SSL/TLS-сертификат за свой. В конце концов, это общедоступные сертификаты. А так клиент может провести аутентификацию сервера, увидев закрытый ключ «в действии».

Таким образом, если сервер может расшифровать pre-master secret и использовать его для вычисления сессионного ключа, он получает доступ. Это подтверждает, что сервер является владельцем используемой пары из открытого и закрытого ключа.

DH-аутентификация

Когда используются Диффи-Хеллман и ECDSA/RSA, аутентификация и обмен ключами разворачиваются бок о бок. И это возвращает нас к ключам и вариантам их использования. Открытый/закрытый ключ RSA используется как для обмена ключами, так и для аутентификации. В DH + ECDSA/RSA асимметричная пара ключей используется только для этапа цифровой подписи или аутентификации.

Когда клиент получает сертификат, он всё ещё проводит стандартные проверки:

проверяет подпись на сертификате,
цепочку сертификатов,
срок действия,
статус отзыва.

Но владение закрытым ключом подтверждается по-другому. Во время обмена ключами TLS-рукопожатия (шаг 4) сервер использует свой закрытый ключ для шифрования случайного числа клиента и сервера, а также свой DH-параметр. Он действует как цифровая подпись сервера, и клиент может использовать связанный открытый ключ для проверки, что сервер является законным владельцем пары ключей.

Аутентификация в рукопожатии TLS 1.3

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

RSA (только подпись),
алгоритм цифровой подписи эллиптической кривой (ECDSA),
алгоритм цифровой подписи Эдвардса (EdDSA).

В отличие от рукопожатия TLS 1.2, аутентификационная часть рукопожатия TLS 1.3 не связана с самим обменом ключами. Скорее она обрабатывается параллельно с обменом ключами и аутентификацией сообщений.

Вместо запуска симметричной схемы MAC для проверки целостности рукопожатия, сервер подписывает весь хеш расшифровки, когда возвращает «Server Hello» со своей частью общего ключа.

Клиент получает всю информацию, передающуюся с «Server Hello», и выполняет стандартную серию проверок подлинности сертификата SSL/TLS. Она включает в себя проверку подписи на сертификате, а затем проверку на соответствие подписи, которая была добавлена в хеш расшифровки.

Совпадение подтверждает, что сервер владеет секретным ключом.

Обмен ключами в TLS-рукопожатии

Если выделить главную мысль этого раздела, она будет звучать так:

RSA облегчает обмен ключами, позволяя клиенту шифровать общий секрет и отправлять его на сервер, где он используется для вычисления соответствующего сеансового ключа. Обмен ключами DH на самом деле вообще не требует обмена открытым ключом, скорее обе стороны создают ключ вместе.

Если сейчас это звучит немного абстрактно, к концу этого раздела всё должно проясниться.

Обмен ключами RSA

Называть это обменом ключами RSA на самом деле неправильно. На самом деле это RSA-шифрование. RSA использует асимметричное шифрование для создания ключа сеанса. В отличие от DH, пара открытого/закрытого ключей играет большую роль.

Вот как это происходит:

Клиент и сервер обмениваются двумя простыми числами (x и y), которые называют случайными числами.
Клиент генерирует pre-master secret (a), а затем использует открытый ключ сервера для его шифрования и отправки на сервер.
Сервер расшифровывает pre-master secret с помощью соответствующего закрытого ключа. Теперь обе стороны имеют все три входных переменных и смешивают их с некоторыми псевдослучайными функциями (PRF) для создания мастер-ключа.
Обе стороны смешивают мастер-ключ с ещё большим количеством PRF и получают совпадающие сеансовые ключи.

Обмен ключами DH

Вот как работает ECDH:

Клиент и сервер обмениваются двумя простыми числами (x и y), которые называют случайными числами.
Одна сторона выбирает секретный номер, называемый pre-master secret (a), и вычисляет: x a mod y. Затем отправляет результат (A) другому участнику.
Другая сторона делает то же самое, выбирая свой собственный pre-master secret (b) и вычисляет x b mod y, а затем отправляет обратно своё значение (B).
Обе стороны заканчивают эту часть, принимая заданные значения и повторяя операцию. Один вычисляет b a mod y, другой вычисляет a b mod y.

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

Рукопожатие TLS 1.2 для DH

Теперь, когда мы узнали, чем DH отличается от RSA, посмотрим, как выглядит рукопожатие TLS 1.2 на основе DH.

Опять же, между этими двумя подходами существует множество сходств. Мы будем использовать ECDHE для обмена ключами и ECDSA для аутентификации.

Как и в случае с RSA, клиент начинает с сообщения «Client Hello», которое включает в себя список шифронаборов, а также случайное число клиента.
Сервер отвечает своим сообщением «Server Hello», которое включает в себя выбранный шифронабор и случайное число сервера.
Сервер отправляет свой SSL-сертификат. Как и при TLS-рукопожатии RSA клиент выполнит серию проверок подлинности сертификата, но, поскольку сам DH не может аутентифицировать сервер, необходим дополнительный механизм.
Чтобы провести аутентификацию, сервер берёт случайные числа клиента и сервера, а также параметр DH, который будет использоваться для вычисления сеансового ключа, и шифрует их с помощью своего закрытого ключа. Результат будет выполнять роль цифровой подписи: клиент использует открытый ключ для проверки подписи и того, что сервер является законным владельцем пары ключей, и ответит своим собственным параметром DH.
Сервер завершает эту фазу сообщением «Server Hello Done».
В отличие от RSA, клиенту не нужно отправлять pre-master secret на сервер с использованием асимметричного шифрования, вместо этого клиент и сервер используют параметры DH, которыми они обменялись ранее, чтобы получить pre-master secret. Затем каждый использует pre-master secret, который он только что рассчитал, для получения одинакового сеансового ключа.
Клиент отправляет сообщение «Change Cipher Spec», чтобы сообщить другой стороне о своём переходе на шифрование.
Клиент отправляет финальное сообщение «Finished», чтобы сообщить, что он завершил свою часть рукопожатия.
Аналогично, сервер отправляет сообщение «Change Cipher Spec».
Рукопожатие завершается сообщением «Finished» от сервера.

Преимущества DHE перед RSA

Существует две основные причины, по которым сообщество криптографов предпочитает использовать DHE, а не RSA: совершенная прямая секретность и известные уязвимости.

Совершенная прямая секретность

Ранее вы, возможно, задавались вопросом, что означает слово «эфемерный» в конце DHE и ECDHE. Эфемерный буквально означает «недолговечный». И это может помочь понять совершенную прямую секретность (Perfect Forward Secrecy, PFS), которая является особенностью некоторых протоколов обмена ключами. PFS гарантирует, что сессионные ключи, которыми обмениваются стороны, не могут быть скомпрометированы, даже если скомпрометирован закрытый ключ сертификата. Другими словами, он защищает предыдущие сессии от извлечения и дешифрования. PFS получила высший приоритет после обнаружения ошибки Heartbleed. Это основной компонент TLS 1.3.

Уязвимость обмена ключами RSA

Существуют уязвимости, которые могут использовать заполнение (padding), используемое во время обмена ключами в старых версиях RSA (PKCS #1 1.5). Это один из аспектов шифрования. С RSA pre-master secret должен быть зашифрован открытым ключом и расшифрован закрытым ключом. Но когда этот меньший по длине pre-master secret помещается в больший открытый ключ, он должен быть дополнен. В большинстве случаев попытавшись угадать заполнение и отправив поддельный запрос на сервер, вы ошибётесь, и он распознает несоответствие и отфильтрует его. Но есть немалая вероятность, что вы сможете отправить на сервер достаточное количество запросов, чтобы угадать правильное заполнение. Тогда сервер отправит ошибочное законченное сообщение, что, в свою очередь, сузит возможное значение pre-master secret. Это позволит злоумышленнику рассчитать и скомпрометировать ключ.

Вот почему RSA был удалён в пользу DHE в TLS 1.3.

Обмен ключами в рукопожатии TLS 1.3

В рукопожатии TLS 1.3 из-за ограниченного выбора схем обмена ключами клиент может успешно угадать схему и отправить свою часть общего ключа во время начального этапа (Client Hello) рукопожатия.

RSA была не единственной схемой обмена ключами, которая была удалена в TLS 1.3. Неэфемерные схемы Диффи-Хеллмана тоже были ликвидированы, как и перечень недостаточно безопасных параметров Диффи-Хеллмана.

Что имеется в виду под недостаточно безопасными параметрами? Не углубляясь в математику, сложность Диффи-Хеллмана и большинства криптосистем с открытым ключом — это сложность решения задач дискретного логарифма. Криптосистема должна быть достаточно сложной для вычисления, если неизвестны входные параметры (случайные числа клиента и сервера), иначе вся схема окажется бесполезной. Схемы Диффи-Хеллмана, которые не могли обеспечить достаточно большие параметры, были исключены в TLS 1.3.

В начале рукопожатия TLS 1.3, зная, что будет использоваться DHE-схема соглашения о ключах, клиент включает свою часть общего ключа на основе предполагаемой схемы обмена ключами в своё сообщение «Client Hello».
Сервер получает эту информацию и, если клиент угадал, возвращает свою часть общего ключа в «Server Hello».
Клиент и сервер вычисляют сеансовый ключ.

Это очень похоже на то, что происходит с DH в рукопожатии TLS 1.2, кроме того, что в TLS 1.3 обмен ключами происходит раньше.

Вместо заключения

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

TLS Handshake

This page is under construction! This page or section is a work in progress and may thus be incomplete. Its content may be changed in the near future.

Any TLS communication starts with a TLS handshake, which establishes what protocol will be used. We will focus on this page about what happens when the TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite is used (see SSL/TLS for more information about what this means)

Handshake Overview

Most packets during the communication are of type Handshake (0x16) and are followed by a Handshake packet header:

This header may be followed by another TLS header, such as a TLS Handshake header. Like for a TCP connection, a TLS connection starts with a handshake between the client and the server:

The client sends a Client Hello message, including a list of 32-byte list of random data and the list of its supported cipher suites. In our example we only send one supported cipher suite (code 0x0033)
The server responds with a Server Hello message, telling the client what cipher suite is going to be used as well as its own 32-byte list of random data
The server sends its certificates. These are used by the client to verify that it is actually talking to the site it thinks it is talking to, as opposed to a malicious site
The server sends a Server Key Exchange message, initiating the key exchange and signing it with its public key
The server sends a Server Hello Done message, indicating it is waiting for the client
The client sends a Client Key Exchange message, containing its part of the key exchange transaction
The client sends a Change Cipher Spec message
The client sends a Encrypted Handshake Message
The server sends a Change Cipher Spec
The server sends a Encrypted Handshake Message
The client and the server can communicate by exchanging encrypted Application Data messages

The Change Cipher Spec message tells the other party its is OK with the terms of the handshake.

The Encrypted Handshake messages are the first ones to be sent encrypted. They contain a hash of the initial handshake messages and are here to ensure these were not tampered with.

Any subsequent communication is of type Application Data and encrypted.

Client Hello Message

The Client Hello message initiates the TLS handshake. It is composed of a specific header, followed by some (optional) extensions, followed by some optional padding. If some servers such as wikipedia.org are quite forgiving in the types of Client Hello messages they accept, others such as Google require the Client Hello message to be exactly 512 bytes (excluding the TLS Record header) and declare a server_name extension

Here is an example of a Client Hello message:

0x01: Client Hello handshake type
0x0001FC: size=508 (512-4)
0x0303: TLS 1.2
0x5716. 0A40: 32-bytes random client data
0x00: session ID length=0 (if it was not null, it would be followed by the session ID)
0x0002: Cipher Suites Length=2 (1 cipher suite supported)
- 0x0033: TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite code
- 0x00: compression method=null
- 0x0001: length=1
- 0x00: renegotiation info extension length=0
- 0x0016: length=22
- 0x0014: server name list length=20
- 0x00: server name type=host_name
- 0x0011: server name length=17
- 0x7777772E. 7267: «www.wikipedia.org»
- 0x0012: length=18
- 0x0010: signature hash algorithms length=16
  - 0x0601: SHA512 + RSA
  - 0x0603: SHA512 + ECDSA
  - 0x0501: SHA384 + RSA
  - 0x0503: SHA384 + ECDSA
  - 0x0401: SHA256 + RSA
  - 0x0403: SHA256 + ECDSA
  - 0x0201: SHA1 + RSA
  - 0x0203: SHA1 + ECDSA
  - 0x0002: length=2
  - 0x02: EC point formats length=1
  - 0x00: EC point format=uncompressed
  - 0x0006: length=6
  - 0x0004: elliptic curve length=4 (2 curves)
  - 0x0017: secp256r1 elliptic curve
  - 0x0018: secp384r1 elliptic curve
  - 0x0188: length=392
  - 0x0000. 0000: 392 bytes of padding data
  Server Hello Message
  
  The Server Hello message indicates which cipher suite is going to be used and provides some server random data that will be used later on.
  
  Here is a sample Server Hello message:
  - 0x02: Handshake type=Server Hello
  - 0x00004D: length=77
  - 0x0303: TLS version 1.2
  - 0xC8CA. 4F6C: 32-bytes server random data
  - 0x20: session ID length=32
  - 0xE402. 362B: session ID (can be used in a future TLS connection to avoid going through the handshake again)
  - 0x0033: cipher suite used=TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  - 0x00: compression method used=null
  - 0x0005: extensions length=5
  - 0xFF01: extension type=renegotiation_info
    - 0x0001: length=1
    - 0x00: renegotiation info extension length=0
    Certificate Message
    
    The server then sends a Certificate message containing its SSL Certificate chain. The first certificate is the server’s SSL certificate. The next certificate is the certificate from a Certificate Authority (CA) which signed the first certificate. The next certificate signs the previous certificate, and so on. The last certificate in the chain should belong to a root CA and is self-signed (each TLS client should have a list of all the root CAs)
    
    Here is how the Certificate Message is encoded:
    - 0x0B: handshake type=Certificate
    - 0x000C58: length=3160
    - 0x000C55: certificates length=3157
      - 0x0007E2: certificate #1 Length=2018
        
        0x3082. C0F3: first certificate (ASN.1 encoded)
        
        0x3080. 4998: second certificate (ASN.1 encoded)
        
        Key Exchange
        
        TLS encryption is performed using symmetric encryption. The client and server thus need to agree on a secret key. This is done in the key exchange protocol.
        
        In our example, TLS is using the DHE/RSA algorithms: the Diffie-Hellman Ephemeral protocol is used to come up with the secret key, and the server is using the RSA protocol to sign the numbers it sends to the client (the signature is linked to its SSL certificate) to ensure that a third party cannot inject a malicious number. The upside of DHE is that it is using a temporary key that will be discarded afterwards. Key exchange protocols such as DH or RSA are using numbers from the SSL certificate. As a result, a leak of the server’s private key (for example through Heartbleed) means that a previously recorded SSL/TLS encryption can be decrypted. Ephemeral key exchange protocols such as DHE or ECDHE offer so-called forward secrecy and are safe even if the server’s private key is later compromised.
        
        Diffie-Hellman Ephemeral works as follows:
        
        The server comes up with a secret number y, with a number g and a modulo p (p typically being a 1024 bit integer) and sends (p, g, pubKey=g y mod p) to the client in its «Server Key Exchange» message. It also sends a signature of the Diffie-Hellman parameters (see SSL Certificate section)
        
        The client comes up with a secret number x and sends pubKey=g x mod p to the server in its «Client Key Exchange» message
        
        The client and server derive a common key premaster_secret = (g x ) y mod p = (g y ) x mod p = g xy mod p. If p is large enough, it is extremely hard for anyone knowing only g x and g y (which were transmitted in clear) to find that key.
        
        Because computing g xy mod p using 1024-bytes integers can be tedious in most programming languages, if security is not a concern, one way to avoid this is to use x=1. This way, premaster_secret is just g y mod p, a value directly sent by the server. The security in such a case is of course compromised.
        
        premaster_key is however only a first step. Both client and server uses the PRF function to come up with a 48-byte master secret. The PRF function is used once again to generate a 104-bytes series of data which will represent all the secret keys used in the conversation (the length may differ depending on the cipher suite used):
        
        Note how different secret keys are used for the client and for the server, as well as for encryption and to compute the MAC.
        
        Server Key Exchange Message
        
        The server then sends its part of the key exchange. In the following case it will send the Diffie-Hellman parameters p, g and pubKey=g y
        
        0x0C: handshake type=server key exchange
        
        0x00030B: length=779
        
        0x0100: p length=256
        
        . : 256-bytes p (1024-bit integer)
        
        0x02: g = 2
        
        . : 256-bytes pubKey
        
        . : 256-bytes signature
        
        Server Hello Done Message
        
        This message indicates that the server is done and is awaiting for client input.
        
        Client Key Exchange Message
        
        The client then sends its key exchange parameters: pubKey=g x
        
        0x10: handshake type=client key exchange
        
        0x000102: length=258
        
        0x0100: pubKey length=256
        
        . 256-bytes pubKey
        
        Change Cipher Spec Message
        
        The client sends the Change Cipher Spec message to indicate it has completed its part of the handshake. The next message the server will expect is the Encrypted Handshake Message.
        
        The whole message (including the TLS Record header) is 6 bytes long:
        
        Another Key Exchange: Elliptical Curve Diffie Hellman Ephemeral
        
        If Diffie-Hellman is a very powerful algorithm, it requires very large numbers to be considered secure (1024-bit at minimum). A variant is Elliptical Curve Diffie-Hellman, which is much harder to break even with 256-bit numbers. Numerous TLS cipher suites now rely on the ECDHE_RSA key exchange instead of DHE_RSA, like in the TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA cipher suite.
        
        Elliptic Curve Diffie-Hellman works as follows: consider a point G = (x, y) on a curve y 2 = x 3 + a.x + b mod p. Both parties come up with secret numbers secret1 and secret2, and will send each other G.secret1 and G.secret2 (G.secret1 means multiplying the point G to secret1 using Elliptic Curve point multiplication). The shared secret key is G.secret1.secret2.
        
        TLS can use the ECDHE key exchange to come up with an ephemeral shared secret key the following way:
        
        The server indicates in the Server Key Exchange message what type of curve is going to be used (secp256r1 is a very common one). This tells what parameters a, b, p and G to use (see [1] to see the domain parameters for each curve)
        
        The server comes up with a random 256-bit number (or whatever the curve says) server_secret and sends pubKey = G*server_secret in the Server Key Exchange message. pubKey is sent as a 65-bytes block composed of the concatenation 0x04 | Gx | Gy (both numbers being 32-bytes long)
        
        The client comes up with a random 256-bit number client_secret and sends pubKey = G*client_secret in the Client Key Exchange message. pubKey is sent in the same format as the server’s
        
        Both parties will derive premaster_secret by computing server_pubKey * client_secret = client_pubKey * server_secret = G * client_secret * server_secret. The x coordinate of this result is the premaster_secret
        
        Once premaster_secret is determined, the rest of the computation works the same regardless of the key exchange protocol used
        
        Regarding how to compute elliptic curve point multiplication, Wikipedia offers more details. Note that, because we are only dealing with integers, you should use modular multiplicative inverse instead of divisions.
        
        If you want to test Elliptic Curves in Python, TinyEC is a very useful package (along with the source code in pure Python):
        
        Another Key Exchange: RSA
        
        The RSA key exchange is by today’s standard an old key exchange protocol and does not provide forward secrecy. It is however simpler to implement than ECDHE and still supported by multiple sites (for example, Google supports the RSA key exchange but not the simple Diffie-Hellman key exchange).
        
        With the RSA key exchange, the server does not send any «Server Key Exchange» message. Instead, the client decides the premaster_secret, which is a 48-bytes string composed of a two-bytes TLS version (0x0303 for TLS 1.2) followed by 46 random bytes. It then encrypts that premaster_secret using the PKCS #1 protocol (aka RSA encryption version 1.5) as well as the key from the Web site’s certificate as the public key. Because the public key is always the same, a leak of the Web site’s private key would allow to decrypt previously recorded TLS conversations. This is why the RSA key exchange protocol offers no forward secrecy.
        
        Without the Crypto.Cipher.PKCS1_v1_5 package:
        
        SSL Certificate (optional)
        
        In order to prevent a Man-In-The-Middle attack (MITM), the server will sign the Diffie-Hellman parameters it sent to the client. Because the client may have never contacted the server before (and thus cannot securely obtain its public key), the client and server rely on a trusted third party known as a Certificate Authority (CA).
        
        In order to verify the signature using the RSA algorithm, the client need to do the following:
        
        Retrieve the Certificate message sent by the server, which contains one or more certificates (look at a such a packet in Wireshark)
        
        Verify that the first certificate’s RDN sequence (signedCertificate / subject:rdnSequence / rdnSequence) contains the Web site the client is trying to contact
        
        Get the RSA e and n values from the first certificate’s public key (signedCertificate / subjectPublicKeyInfo / subjectPublicKey). Those parameters are encoded using the ASN.1 format (as a verification, e is very often 65537, or 0x10001)
        
        Compute the hash of the whole DH parameters (as sent by the server) preceded with the client and server random data. The certificate indicates what type of hash to use (signedCertificate / subjectPublicKeyInfo / algorithm):
        
        Compute signature e mod n, convert it to a string and take the last 20 bytes (or more, depending on the hash function being used)
        
        Both computations should be the same
        
        Because this certificate is probably generated by an intermediate CA, the client needs to verify that certificate
        
        Compute the hash of the whole signedCertificate section and repeat the operation using the next certificate
        
        Follow the certificate chain up to the end. The last certificate should belong to a root CA (any TLS implementation should contain a list of the root CAs and their public key) and is self-signed
        
        Encrypted Handshake Message
        
        The TLS handshake is concluded with the two parties sending a hash of the complete handshake exchange, in order to ensure that a middleman did not try to conduct a downgrade attack.
        
        If your TLS client technically does not have to verify the Encrypted Handshake Message sent by the server, it needs to send a valid Encrypted Handshake Message of its own, otherwise the server will abort the TLS session.
        
        Похожие публикации:
        
        Активатор луции айон где купить
        
        Как проверить гост шифрования файла в windows
        
        Регулятор оборотов pwm что это
        
        Смарт контракты эфириума что можно сделать