Использование пользовательских параметров DH для расшифровки TLS

Существует несколько способов расшифровки TLS, например. в корпоративной среде. Я не видел, чтобы где-то упоминалось использование «закрытых» параметров DH, хотя, насколько я понимаю, это должно работать в принципе: Как непростой модуль для Диффи-Хеллмана допускает лазейку?

Возможно ли, чтобы новый настольный процессор расшифровывал трафик (почти) в реальном времени? Это зависит от шифров или версии TLS? Есть ли преимущества/недостатки использования этого варианта? Я предполагаю, что кража пользовательских параметров аналогична краже приватных, и вы теряете PFS?

Возможно ли, чтобы новый настольный процессор расшифровывал трафик (почти) в реальном времени?

Если вы спрашиваете конкретно о бэкдоре DH-группах, ну, если вы используете версию TLS, которая позволяет серверу [1] предлагать нестандартную DH-группу (и клиент примет эту группу, а нормальные — нет) , то да, он может предложить чрезвычайно слабую группу (например, такую, для которой $p-1$ не имеет больших множителей), и это упростило бы восстановление общего секрета (и, следовательно, ключей трафика).

Такие «слабые группы DH» невозможны, если вы используете нормальную версию TLS (или клиент отказывается принимать некоторые довольно странные варианты); с другой стороны, если вы выполняете DH, вы можете просто заставить сервер использовать угадываемое частное значение DH (например, такое, которое является функцией файлов cookie приветствия сервера); злоумышленник может использовать это для прослушивания.

С третьей стороны, если вы контролируете сервер, то зачем беспокоиться? На сервере есть ключи трафика; если злоумышленник контролирует это, было бы еще проще, если бы сервер выдавал ключи сеанса тому, кто подслушивает.

[1]: я считать это сервер, который предлагает группу DH в TLS 1.2; если нет, просто поменяйте местами клиент и сервер в приведенном выше аргументе.

В протоколе TLS сервер выбирает группу для обмена ключами: группа Диффи-Хеллмана конечного поля или эллиптическая кривая. Сервер должен выбирать в рамках ограничений, заданных клиентом. В TLS 1.3 группы идентифицируются из небольшого списка стандартных групп. Более ранние версии протокола позволяют серверу описывать пользовательскую группу. Для эллиптических кривых это редко поддерживается: большинство программ поддерживает только именованные кривые. Но для конечного поля Диффи-Хеллмана клиент классически ограничивает только размер группы, а сервер отправляет числовое значение параметров. Хотя сегодня большинство программного обеспечения поддерживает расширение NamedGroup, большинство клиентов будут принимать числовые значения для обратной совместимости. Таким образом, клиент может быть обманут, чтобы принять параметры FFDH, которые скрыты.

Тем не менее, это в основном не имеет отношения к угрозе безопасности, потому что сервер подбирает параметры. Если сервер хочет скомпрометировать обмен ключами, он также может выполнить совершенно надежный обмен ключами, а затем где-нибудь зарегистрировать общий секрет. Таким образом, чтобы слабые параметры FFDH представляли угрозу безопасности, должна существовать крайне маловероятная модель безопасности:

• На сервере работает бэкдор-код (или он имеет бэкдор-конфигурацию), и вы не можете обнаружить, что бэкдор был вставлен.
• Закрытый код находится лишь в небольшой части стека TLS, и вы уверены, что в другом месте нет бэкдора, который мог бы, например, напрямую утечь открытый текст или общий секрет.

По сути, бэкдор FFDH в TLS может быть только сервером, стреляющим в собственную ногу. Это не имеет значения для прослушивания трафика между другими хостами. Либо сервер заблокирован, и он вам не нужен, либо сервер не заблокирован, и это не принесет вам никакой пользы.