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

Пишут, что поддержка постквантовой криптосистемы X25519Kyber768 в Chrome свежей версии ломает TLS в каких-то серверных реализациях или на промежуточных узлах-фильтрах, а происходит это из-за того, что начальное сообщение ClientHello получается слишком длинным.

Вообще, X25519Kyber768 добавляет 1216 байтов, что, действительно, сравнимо с размером типичного ClientHello (без “постквантовых” данных, но с разными расширениями). Скажем, даже длинный FFDHE3072 (“мультипликативный” вариант Диффи-Хеллмана в TLS 1.3) использует только 384 байта. Chrome, надо сказать, FFDHE3072 не поддерживает, но зато дописывает фиктивное ECH-расширение (это не связано с постквантовой криптосистемой).

То есть, вовсе не трудно поверить, что в каких-то, – не самых качественных, – реализациях TLS, “постквантовое” ClientHello может читаться лишь частично, потому что оно не влезло в один ответ функции чтения TCP-сокета. Такое нередко приключается в системах инспекции трафика, разных “корпоративных” сетевых экранах (как бы, stateful), да и в прочих инструментах. С другой стороны, пытаться читать TLS-сообщения только по данным TCP-пакетов, игнорируя заголовки самих TLS-записей, в которых указана полная длина, – не самый лучший способ реализации TLS. Особенно, если речь про некоторый “продвинутый” механизм “обеспечения безопасности”, типа брандмауэра.

Адрес записки: https://dxdt.blog/2024/04/28/12919/