dxdt.ru: занимательный интернет-журнал

Снова пишут про то, что в TLS браузера Chrome длинное ClientHello с ключом Kyber768 ломает обработчики TLS-трафика на каких-то “специальных” веб-серверах и на промежуточных фильтрах. Между тем, чтобы разобраться, как там и что происходит, достаточно посмотреть на конкретное ClientHello, но в некоторых деталях. В качестве примера я взял сообщение от браузера Chrome 124 в том виде, как оно отображается на тестовом сервере TLS. Чтобы просмотр дампа не был скучным, листинг перебивается техническими пояснениями.

Итак, ClientHello TLS 1.3 с постквантовой криптосистемой Kyber768 внутри. CH здесь уже извлечено из TLS-записей и разобранно на элементы: то есть, здесь не учитываются и не упоминаются дополнительные байты, которые расходуются внутри структуры CH на представление полей – идентификаторы, длина записи; обычно – это несколько дополнительных байтов на один элемент структуры. Если бы разбирать и эти байты, то описание излишне усложнилось бы (подробности – можно прочитать в техническом описании TLS).

Version: 0x0303
Cipher suites:
 0xBABA,0x1301,0x1302,0x1303,0xC02B,0xC02F,0xC02C,0xC030
 0xCCA9,0xCCA8,0xC013,0xC014,0x009C,0x009D,0x002F,0x0035

Начальная часть сообщения ClientHello (далее – CH) содержит “исторический” номер версии (здесь указано 0x0303) и перечень шифронаборов. Полезных данных: два байта – номер версии, 32 байта (16*2) – идентификаторы шифронаборов.

 
Client Random: 
85:32:22:08:24:07:B2:98:F3:23:08:4D:A5:FB:E4:59:41:93:13:88:AA:58:53:4E:B4:EF:E7:DA:E8:78:FE:71
Client SessionID: 
C0:39:BC:CE:BB:60:5F:76:D8:75:F9:84:69:E9:9F:C2:AE:7B:8F:D5:9C:E8:01:51:71:9D:21:D2:13:26:DB:5A

Случайное значение от клиента (Client Random). А также клиентский “идентификатор сессии” – в TLS 1.3 этот идентификатор играет роль простого сигнала и ни на какую сессию не указывает.
Здесь всего 64 байта данных, по 32 на каждое поле.

Далее идёт важная часть, которая, собственно, определяет значимые параметры TLS-соединения – набор расширений CH.

Extensions:
 Type: 14906 (0x3A3A); "_undef_ (GREASE)"
 Type: 35 (0x0023); /non-TLS-1.3/
 Type: 23 (0x0017); /non-TLS-1.3/
 Type: 16 (0x0010); "application_layer_protocol_negotiation"
  00:0C:02:68:32:08:68:74:74:70:2F:31:2E:31
 Type: 65281 (0xFF01); /non-TLS-1.3/
  00

Здесь 0x3A3A (тип 14906, первое расширение) – это пример того, что называется GREASE, а именно – специальных, заведомо неподдерживаемых, значений и идентификаторов, которые Chrome дописывает в TLS-сообщения с целью (как заявлено) проверки корректной работы парсеров и прочего программного обеспечения, задействованного в обработке TLS. Такие обработчики, согласно спецификации, должны успешно игнорировать неизвестные расширения и параметры (если контекст позволяет, конечно). Так что, вообще говоря, добавление разных там новых “постквантовых ключей” не является чем-то особенным – всякие фиктивные элементы писались в браузерные сообщения и раньше, именно для того, чтобы обновления не оказывались полной неожиданностью (ниже нам встретятся и другие GREASE). Другие расширения из этого фрагмента, с типами 35 (session_ticket), 23 (extended_master_secret), 16 (ALPN) и 65281 можно не рассматривать: они небольшие по объёму (например, extended_master_secret – это всего лишь сигнал, вообще не содержащий байтов данных), часть из них не поддерживается в TLS 1.3. Поэтому – переходим дальше.

Как говорится, а вот и он – постквантовый элемент. Клиентский открытый ключ Kyber768 содержится уже в следующем расширении – key_share. Оцените огромный размер данных, которые тут приводятся без сокращений.

 Type: 51 (0x0033); "key_share"
  _undef_ (GREASE) (0xAAAA)
   Unsupported group: 0xAAAA (_undef_ (GREASE))
  X25519Kyber768Draft00 (0x6399)
   Hybrid: X25519 + Kyber
   Len (octets, dec.): 1216
   Key share data:
    X25519
     x = 0xF2C744A07B3BC36F6C427620351A009D29BB36E6EF259A177A3881ECEB22100D
    Kyber768 client public key:
     Vpoly_1 (packed):
      6CA39FB332275395989A56958E6B61A7B3B447D6A2C9062837E39695B44E4A5B
      36C9A7B06F4A912ED6ABC2E3BD2FD8584BE42F5822A3A54A4CC14812F3D87A05
      5371F2E1222817A63FAA531CD7691DE59694F9B4ACD3B8CD638A44B9B566C094
      3A95B7DCB186CC840C53A90041FB15FFBB214E3BCE8AB0C3D278897A61992601
      BB88427608A8AEC6385C0C6319A56B8B47CA240F3A134DD6AF4B56A6333158A9
      D391B495A76EA0C5F67C49457042AFFB508766414C88A8EA23B1328723FC9199
      8BA78414527F2DC234C0213CF5DAB976910EA3DC641C8B818FF73F4CEB53C929
      C03F61CFD8A04CE88A3EB16CCAE02C9541438A16D4A7FE8129F7F04C0C0A9E14
      60ACA4049F84C2C4E5DB1B4185CF0FE8C305333CBC7B3970A27E42C23F47F003
      E3815FDE20830B912501E388BEB9B14399ADD2EA174E3C040810917E555084E1
      5B75B9599914523799B6885721D08A46741501EBACA747C905B7AA31E3D3137C
      718B50A908DC111E49161448B102D3F0411EA70D9F91CFF6F50D5D54B9AB7B11
     Vpoly_2 (packed):
      1356BAA03CAD6E2730C334C24D492E6A11088F7B036A7ACBEF26407C1A9DCDFA
      473D677C3447915AE28EB094326093668FC27DCB85086219A1A0E6A6FC367CE0
      9A4396EA75FAFA1CD336311DE505BE5075A36C436B58673CF6387AF45BDBD523
      C082864EB6BD20E6A587C99976FA04C9548FB9731BC5B80D483984D8E84D89A3
      8A0D210D58C22C9DA0316D9214B45B46C7353228C67A62F101DD79267C071CEE
      9C1FA2DA976294AD6031C245397BDFB11A3AF012DF154B6D126439F579F85C38
      77AB844586159ECCAD0D468A3D94A5DABA43B26722B4C24FEFDC19FC62355341
      29B1FBABC7D242DDEB59DB00C564546DBD384653CCB55436BCCA4B7C4BA585E3
      50B078A48B8F02C9BA79154DF463E42538DB7616AC04C9C1284F0E2918009CAE
      49EB18708A2BD322A3A613CCCF43B3CA288780546FEBF03B6FC3394816359406
      5642DC4930B4B36D5B5122A90871006975496515650608E632414B5054019BB5
      CB280DF34DA9087AB2FA2ADB94588AB2A8C8D3CA3DAB7248357001D0C175269C
     Vpoly_3 (packed):
      AAF30D9EA1ADEF802799581653A0A0D4D692EB2B644F6C84059388947838138A
      1D24464054A9A3E9385FD3E4A6C0C56D09D80F984705B2E4B4244A4D67C3CD58
      7739688170695AC9AA4C354A349AB04ACBD4753E6B519468EB900A290C3AD255
      A004307B1572C0072946B73639F897D434086C515F6BBA53BB10B6A3D4B4AC86
      58E4A4C3EE452C3D7442536756D4F7041775897C2240C4B437CC97CC5E4270FD
      986DEE9842831B1F233B543F724A9E5B0446BB22CF6C8AC278CD4E275482F61B
      A3461582291443967ED0AA78723A2EBE448AC24726D8EA8F5264BC45A4A7D8B4
      C04EFC7A7271AA361B454EE43365644E5DA9A5F8A5A838D4C93EB6970716B98D
      5617F4E4829E93A816432C9B7621ECF2CB5A75BDD4446F58BC57F1A36215467F
      1722A31FFA2432574F028848A92A0FC5C48C4F391FDF2214429454A6015DD9E6
      496A3B1D5F9768C5326AB2997E038CA5E7E34347D5C5C8E7AE00A9CB48FA4A43
      54768F3C586430B8C4E8C3CAE13EE0265910A0B01FA037CAE333B13B63601397
     Rho (bytes):
      44D2E20D0D57AA501ED3DE916106FF5DA95E4BE2AD4335034F2C757352305980
  X25519 (0x001D)
   x = 0xFB6C61B9A2E5323674FD2C49FA02DF5E1335F52EFBF984C9FC2401F01B1F7C5E

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

В данном случае браузер Chrome прислал нам значение X25519 (внизу) и гибридный набор из X25519 и Kyber768 – то есть, X25519Kyber768draft0 (идентификатор 0x6399 – в начале). Важно не запутаться: криптосистема с постквантовой стойкостью тут одна, она называется Kyber768 (“на научном языке” это KEM – Key Encapsulation Mechanism). Однако в TLS эта криптосистема внедряется в гибридном варианте, то есть, на прицепе к классической, хорошо отработанной, криптосистеме X25519, которая есть разновидность реализации протокола Диффи-Хеллмана. Данный гибрид всё ещё считается “черновым вариантом” – draft. Поэтому полное название X25519Kyber768draft0.

Если приглядеться, то в этом же расширении есть ещё один, не столь массивный, блок, названный X25519. Это другое, отдельное открытое значение X25519, которое может быть использовано сервером, если сервер не поддерживает X25519Kyber768draft0. К входящему в гибридный вариант значению X25519 свободный вариант отношения не имеет. Это та же криптосистема X25519, в гибриде она работает абсолютно и точно так же, как и без “гибридизации”, но название отличается, как отличаются и значения ключей (обозначены “x”).

Постквантовая часть ключей указана в блоке “Kyber768 client public key”. Ключ Kyber768 состоит из четырёх обособленных значений: это три полинома (Vpoly_N) и параметр Rho. И только лишь ключ Kyber768 занимает уже 1216 байтов. X25519 добавляет лишь 32 байта (в составе гибрида).

Другие элементы расширения key_share, которые тоже отмечены GREASE, это, опять, фиктивные значения, как и в следующем расширении – supported_groups.

 Type: 10 (0x000A); "supported_groups"
  0xAAAA (_undef_ (GREASE))
  0x6399 (X25519Kyber768Draft00)
  0x001D (X25519)
  0x0017 (Secp256r1)
  0x0018 (Secp384r1)

В этом расширении – поддерживаемые клиентом схемы криптосистем. Расширение называется “Поддерживаемые группы” (supported_groups). “Группы” здесь – это технический термин, обозначающий математическую структуру (группу), которая применяется в той или иной криптосистеме (кстати, можно сказать, что “схема”, с математической точки зрения, даже более технический термин, который вполне можно так применить, но, конечно, это лишь случайное совпадение).

Данное расширение всего лишь перечисляет идентификаторы параметров, которые клиент готов использовать. Часть ключей – уже передана в составе key_share. Поэтому тут и присутствуют X25519Kyber768Draft00 и X25519. Однако сервер может не поддерживать ни X25519Kyber768Draft00, ни X25519. В таком случае предстоит выбрать что-то из оставшихся вариантов: Secp256r1 и Secp384r1, под которыми подразумевается протокол Диффи-Хеллмана (DH) на кривых P-256 и P-384. А GREASE – выбрать нельзя. Для перехода к другой криптосистеме сервер, в ответ на CH, отправляет сигнальное сообщение HRR (HelloRetryRequest), указывая в расширениях к нему предпочитаемую криптосистему. Пересогласование криптосистемы для DH поддерживается на тестовом сервере tls13.1d.pw – так что эффект нетрудно увидеть, понажимав Ctrl+F5 (Refresh) в браузере: при пересогласовании клиент пришлёт новое CH, уже с другим составом key_share.

Возникает резонный вопрос: поддержка Kyber768 на серверной стороне не очень-то распространена, нужно ли пересогласование при каждом CH от Chrome с Kyber768? Нет, в типовом случае, серверу не нужно ничего пересогласовывать – сервер может проигнорировать гибридный постквантовый набор и сразу использовать X25519 (поддержка есть практически повсеместно), потому что ключ этой криптосистемы указан в CH от Chrome (не гибридный, а отдельный). Если, конечно, сервер не поддерживает X25519, тогда пересогласовать криптосистему потребуется, но не из-за наличия Kyber768.

Следующее расширение – это фиктивное ECH (Encrypted Client Hello).

 Type: 65037 (0xFE0D); "ECH /DRAFT/"
  Type: 0x00 (Outer)
  HKDF: 0x0001 (HKDF-SHA256)
  AEAD: 0x0001 (AES-128-GCM)
  Config id: 0x04
  Encapsulated key (bytes):
   08FC1E6C6A441874D38689375F9C906827516F2F306BBD8B2376569F99CF0069
  Payload (dummy):
   ECADC2C291D6311FCD925306392EE88CD057D42178C0B60EF5B14814F2CF669E
   05230A0F3D6AABADA0A3EB78D240E22BE2DE5893A50B3AEC4056B77B5CACF7C9
   07F5E6EE853268C23595E22F59E9D190BE9ECCD05B76092CBA00FCCE1C072283
   7CBE371C871817540D8E9429CB10F4CCA3089AB36154D7AE2578FF5D12884F3D
   437AB7A97E0FDA19DCC4B423A4DFD2CF

ECH служит для доступа к скрытым сервисам. Базовое применение: сокрытие имени узла, с которым устанавливается TLS-соединение. Chrome включает фиктивное расширение в CH даже для узлов, которые ECH не объявляли. Это метод придания единообразия TLS-трафику. Расширение ECH устроено довольно сложно, содержит внутри дополнительную структуру и большое по объёму данных поле Payload, которое, в случае фиктивного расширения, имитирует полезные данные ECH (зашифрованное CH). ECH, в данном случае, добавляет ещё 182 байта.

 Type: 00 (0x0000); "server_name"
  00:00:0E:00:00:0B:74:6C:73:31:33:2E:31:64:2E:70:77
  hostname: tls13.1d.pw

Расширение SNI, содержащее имя узла, с которым устанавливается TLS-соединение. Именно данные этого расширения и должно скрывать ECH (в данном случае – ECH не поддерживается). Обычно, это расширение не очень большое по объёму (но зависит от используемого имени).

 Type: 45 (0x002D); "psk_key_exchange_modes"
  01:01
 Type: 17513 (0x4469); /non-TLS-1.3/
  00:03:02:68:32
 Type: 43 (0x002B); "supported_versions"
  0x8A8A (_undef_ (GREASE))
  0x0304 (TLS 1.3)
  0x0303 (TLS 1.2)
 Type: 05 (0x0005); "status_request"
  01:00:00:00:00
 Type: 13 (0x000D); "signature_algorithms"
  00:10:04:03:08:04:04:01:05:03:08:05:05:01:08:06
  06:01
 Type: 11 (0x000B); /non-TLS-1.3/
  01:00
 Type: 27 (0x001B); /non-TLS-1.3/
  02:00:02
 Type: 18 (0x0012); "signed_certificate_timestamp"
 Type: 10794 (0x2A2A); "_undef_ (GREASE)"
  00

Из оставшихся расширений в контексте этой записки интерес представляет только supported_versions (тип 43): в TLS 1.3 именно это расширение содержит настоящий список поддерживаемых клиентом версий TLS. Chrome, помимо очередного GREASE, передаёт здесь идентификаторы версий 1.3 и 1.2. Наличие supported_versions и делает это CH сообщением версии TLS 1.3.

А заканчивается набор расширений всё тем же GREASE.

Итак, на примере конкретного ClientHello хорошо видно, что ключ Kyber768, действительно, занимает основную часть сообщения. Обычный вариант CH, без “постквантовой стойкости”, будет отличаться только отсутствием ключа X25519Kyber768Draft00, всё остальные поля – применяются точно так же.

Адрес записки: https://dxdt.ru/2024/05/04/12962/