кодированая строка XXX сертификат = некодированая строка

[Pavia]

ArtGrek
Давай ещё раз вернёмся назад. У нас протокол TLS 1.2.
SSL 2.0->SSL 3.0->TLS 1.0 -> TLS 1.1 -> TLS 1.2
Так уж сложилось что SSL 3.0 лучше документирован чем TLS 1.2

Основную часть будем брать отсюда
https://ru.wikipedia.org/wiki/TLS
А сюда будем лазить за пояснениями
https://tools.ietf.org/html/rfc6101

Сообщение от SSL 3.0

6. Cryptographic Computations

The key exchange, authentication, encryption, and MAC algorithms are
determined by the cipher_suite selected by the server and revealed in
the server hello message.

SSL 3.0 предназначен для обмена ключами, проверки подленности узлов, шифрования, проверки подленности сообщения - алгоритмы которых постулируются в cipher_suite. Сервер выбирает нужное и посылает в
hello message.

[Pavia]

ECDHE-RSA-AES128-GCM-SHA256
1) ECDHE - key exchange
2) RSA - authentication
3) AES128 - encryption
4) GCM просто рекомендация по кодированию.
5) SHA256 - MAC

[Pavia]

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

Грубо говоря мы имеем стек из 3-х протоколов.
AES128 ему нужно два открытых ключа. Сам по себе он не гарантирует надёжность от атак внедрения. Поэтому нужен RSA который проверит достоверность открытого ключа.
RSA позволяет проверить подлинность сервера, но для работы ему нужно переслать закрытый ключ.
По сути замкнутый круг. Но на помощь приходит ECDHE он позволяет обменять ключи через 3-сервер который выше этих двух. Но что-бы третий не смог подделать ключи вводится ещё контрольная сумма в виде SHA256.

[ArtGrek]

вот хороший пример и переводится нормально
http://www.moserware.com/2009/06/fir...-of-https.html
но там TLS_RSA_WITH_RC4_128_MD5
читаю...

[ArtGrek]

1) ECDHE - способ создания эфемерных ключей по протоколу Д-Х на эллиптических кривых?

Ephemeral keys are temporary and not necessarily authenticated,
so if authentication is desired, authenticity assurances must be obtained by other means

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

RSA (Rivest-Shamir-Adleman)
DSA (Digital Signature Algorithm)
Elgamal (Шифросистема Эль-Гамаля)
Diffie-Hellman (Обмен ключами Диффи — Хелмана) // кроме этого
ECDSA (Elliptic Curve Digital Signature Algorithm) — алгоритм с открытым ключом для создания цифровой подписи.
ГОСТ Р 34.10-2001
Rabin
Luc
McEliece
Williams System

то есть вместо ECDHE-RSA, могло бы, быть ECDHE_DSA или ECDHE_Rabin или ...
я правильно все понял или нет?

[Pavia]

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

Это не тот список. У вас список с алгоритмами для обмена ключами. А для проверки подленности есть отдельный список. Он покороче.

[ArtGrek]

можно увидеть этот список?