Нет, вам не хватает важного нового аспекта, я думаю (я не вижу ваше связанное изображение, вы должны опубликовать все соответствующие данные внутри самого вопроса).
По причинам совместимости TLSv1.3 пытается маскировать себя как TLSv1.2 в течение ClientHello, см. https://tools.ietf.org/html/rfc8446#section-4.1.2:
4.1.2. Клиент Привет
Когда клиент впервые подключается к серверу, ТРЕБУЕТСЯ отправить
ClientHello как его первое сообщение TLS.
Структура этого сообщения:
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
Обратите внимание, что legacy_version на самом деле является TLSv1.2, а затем объяснение:
legacy_version: в предыдущих версиях TLS это поле использовалось для
согласование версии и представляет наибольший номер версии
поддерживается клиентом. Опыт показал, что многие серверы
неправильно реализовывать согласование версии, приводя к «версии»
нетерпимость ", в которой сервер отклоняет иное приемлемое
ClientHello с номером версии выше, чем он поддерживает. В
TLS 1.3, клиент указывает свои предпочтения версии в
Расширение «support_versions» (Раздел 4.2.1) и
Поле legacy_version ДОЛЖНО быть установлено в 0x0303, что является версией
номер для TLS 1.2. TLS 1.3 ClientHellos определены как имеющие
версия legacy_version 0x0303 и расширение support_versions
представить с 0x0304 в качестве самой высокой версии, указанной в нем.
(Подробнее о обратной совместимости см. Приложение D.)
Что касается комплектов шифров и версий TLS, ситуация более сложная. TLSv1.3 стандартизировал только некоторые из них как обязательные по причинам, объясненным в спецификации.
Однако это также не запрещает другим версиям TLS использовать их.
См:
Семейство "AES GCM" было определено 10 лет назад в https://tools.ietf.org/html/rfc5116
TLSv1.3 стандартизирован только для идеальной конфиденциальности пересылки, поэтому подразумевается только обмен ключами DHE (EC), если не используется PSK (см. Раздел 2 RFC8446)
Посмотрите https://security.stackexchange.com/a/77018/137710 и https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites
Но набор шифров TLSv1.3 определен по-другому (новые имена), потому что они разделяют некоторые части в других расширениях.
Следовательно, вы увидите это предупреждение в журнале изменений OpenSSL:
Отдельная конфигурация шифра TLSv1.3 из конфигурации шифра TLSv1.2
конфигурации. Шифрованные наборы TLSv1.3 не совместимы с TLSv1.2 и
ниже. Аналогично, шифровальные наборы TLSv1.2 не совместимы с TLSv1.3.
Во избежание проблем, когда унаследованная конфигурация шифра TLSv1.2
в противном случае непреднамеренно отключить все наборы шифров TLSv1.3
Конфигурация была выделена. Смотрите страницу справочника по шифрам или
Справочная страница SSL_CTX_set_ciphersuites () для получения дополнительной информации.
(https://github.com/openssl/openssl/pull/5392)
Документация CloudFlare на https://support.cloudflare.com/hc/en-us/articles/200933580-What-cipher-suites-does-CloudFlare-use-for-SSL- говорит ниже таблицу:
Хотя TLS 1.3 использует то же пространство наборов шифров, что и предыдущие версии TLS, наборы шифров TLS 1.3 определяются по-разному, задают только симметричные шифры и не могут использоваться для TLS 1.2. Точно так же наборы шифров TLS 1.2 и ниже не могут использоваться с TLS 1.3 (IETF TLS 1.3, черновик 21).