Комментарии 16
За "штуки посередине", которые разрывают соединение, если не могут понять, что там внутри, надо канделябром. И желательно побыстрее, пока ECH не смержили в openssl - и проблема не приняла лавинообразный характер.
У себя дома или в организации - можно и канделябром. А для критической инфры, вроде банкинга, госуслуг или медицины - наоборот, нехер неизвестный трафик пускать.
Канделябром надо тем, кто без стандартизации и поддержки другими вендорами пихает свои хотелки во внешний мир, особенно которые ломают вещи, которые сейчас просто работают.
Вы щас что-то на айтисековском сказали :)
Продолжая вашу метафору, Хром - у себя дома. Не нравится, что они там "пихают" - групповые политики в помощь, хоть один SSL 3.0 оставляйте или какие-нить православные шифры.
для критической инфры, вроде банкинга, госуслуг или медицины
Я думаю, для критической инфры, вроде банкинга, госуслуг или медицины, наоборот необходимо целиком и полностью соответствовать стандартам протоколов, с которыми они работают, а не пороть отсебятину типа "тут не поняличто написано, значит забьем, тут редкий случай, наврядли случится, его реализовывать не будем". Если в стандарте написано, что в хендшейке могут быть дополнительные данные вплоть до определенного размера, значит надо их пропускать.
А за софт который игнорирует штатным образом установленные на устройство MITM-сертификаты и штатным образом настроенные прокси?
К софту претензий нет, поскольку нет никакого "штатного образа". У джавы вон вообще отдельное хранилище корневых сертификатов - и ничего, люди как-то выживают.
Это я к тому, что спасение утопающих настройка ПО, которое не подтягивает какие-то настройки из ОС - не какая-то редкая ситуация, и у тех, кому это действительно нужно - есть задокументированные способы этого достичь.
Есть софт который не свои настройки имеет а намеренно ломает - ну там - лезет по 443-му порту с НЕ https'ом и при этом однозначно разобраться где у него сервер чтобы хоть туда доступ выдать(в ситуации когда пользователь не против дать исключение) не просто (прокси нормально тоже поддерживтаь не хочет). Ну да - конкретно этот софт - для защиты от блокировок так делает похоже и свой прокси под него завести все же можно.
Есть просто любители pinning'а
Основная проблема в том, что не все сервисы правильно обрабатывают фрагментированный ClientHello, а именно это и происходит при использовании Kyber, т.к. размер пакета получается больше размера стандартного MTU 1500.
Проблема не нова, встречается у разных сервисов и продуктов в том или ином виде по меньшей мере 7 лет, с момента начала разработки GoodbyeDPI. Часть сервисов её устранили после моих сообщений, часть — забили.
Ну и муть написана. Читаю и ахриневаю. Думаю капец моему серверу - надо опять всё переделывать. В голове сразу мысли - что и как они там собираются сохранять что бы потом расшифровывать.
И только из комментов узнаю что он про алгоритмы на элептических кривых.
Перевожу с журналистко-изнасиловского на человеческий.
Походу тупо убрали из поддерживаемых криптошрифтов для обмена ключей RSA алгоритм. А что есть ещё те кто его использует? И потом присматриваюсь к модно-зумерскому названию алгоритма X25519Kyber768. Ба да это же старый добрый Curve25519 И да там этих "курвав" туча и маленькая тележка. Конкретно эта - быстрая. Кстати из-за этого имеет чуть меньше криптостойкости по брутфорсу.
Поясняю - в RSA есть закрытый ключ. По идеи если сохранить сессию. Прийти в датацентр, ломиком достать сервер. Выковырять закрытый ключ. То можно будет восстановить сессию.
В элиптики для каждой сессии генерируется отдельный закрытый ключ. После сессии удаляется. И да - уже 100 лет все используют элиптику.
И при чём тут вообще квантовые компьютеры? Если исходить из того что они имеют бесконечные ресурсы по расчётам (а в реальности там всё намного хуже, реально можно только пару алгоритмов на них сделать да и всё) То можно брутфорсом взломать вообще всё и элиптику и что угодно.
И я тут сижу и думаю, блин походу что то против брутфорса придумали. Или каой гений-математик придумал как элиптику сломать. Придётся всё выкидывать и кодить новые алгоритмы.
Чем дальше читаю тем больше смеху. Kyber-768 — квантово-устойчивый метод инкапсуляции ключей. Да это уже 100 лет используемый пресловутый ECDH
Думаю, вам надо написать в Гугл, чтобы они поправили.
И только из комментов узнаю что он про алгоритмы на элептических кривых.
Kyber (он же ML-KEM) основан на решетках, не на эллиптических кривых. Он (и другие алгоритмы) придуманы для защиты от расшифровки данных в квантовую эпоху.
И потом присматриваюсь к модно-зумерскому названию алгоритма X25519Kyber768
Такое название у алгоритма потому, что он гибридный: генерирует общий ключ и на основе X25519, и на основе Kyber (ML-KEM) одновременно. Гибридный алгоритм нужен из-за того, что Kyber очень свежий метод, и если в нём обнаружится критическая проблема, все установленные соединения окажутся не защищены ни пост-квантово, ни пре-квантово. Такая конфигурация позволяет обеспечить надёжность шифрования, пока хотя бы один из компонентов остаётся невзламываемым.
Поясняю - в RSA есть закрытый ключ. По идеи если сохранить сессию. Прийти в датацентр, ломиком достать сервер. Выковырять закрытый ключ. То можно будет восстановить сессию.
В элиптики для каждой сессии генерируется отдельный закрытый ключ. После сессии удаляется. И да - уже 100 лет все используют элиптику.
RSA, эллиптические кривые и обмен ключами Диффи-Хеллмана — это не связанные вещи. Если сессия устанавливается с помощью DH, владение закрытым ключом RSA не даст вам возможности её расшифровать. И наоборот, сессия без DH на эллиптических кривых может быть расшифрована при владении ключом.
Пришлось отключать через флаги, иначе часть сайтов вообще не открывалась: сначала долго ждет ответа, потом вываливается с Connection Refused. На других браузерах (которые еще не успели на новое ядро хромиума перейти) проблем нет. Как отключил - сразу всё заработало без проблем.
А ни у кого из использующих Adguard Home + внешние DNS-серверы с DoT/DoH не появились последнее дни похожие симптомы (ошибка и потом через некоторое время нормально), при этом эффект похоже независимо от домена и успешный повтор запроса решает проблему на некоторое время?
Постквантовая криптография Google Chrome 124 может нарушить криптографию TLS