Распространение SSL-сертификата и закрытого ключа представляет собой риск безопасности?

Я обнаружил, что некоторые приложения включают SSL-сертификат и соответствующий закрытый ключ, подписанный публичным ЦС для доменного имени, указывающего на 127.0.0.1, вероятно, чтобы обойти предупреждение о сертификате/смешанном контенте на своем локальном сервере. Пример

Я также нашел такие сервисы, как https://get.localhost.direct/, которые предоставляют сертификат для *.localhost.direct, который указывает на 127.0.0.1.

Кроме нарушения соглашения с подписчиком сертификата (которое обычно требует хранить закрытые ключи в тайне), несет ли публичное распространение сертификатов и связанных с ними закрытых ключей дополнительные риски безопасности, кроме того, что злоумышленник сможет подделать доменное имя?

Это не практический риск.

Распространяя закрытый ключ, они явно нарушают основополагающий принцип никогда не передавать закрытые ключи. Тот факт, что вы как конечный пользователь можете получить доступ к закрытому ключу, также означает, что любой злоумышленник может получить к нему доступ. Вполне возможно, что закрытый ключ уже активно распространяется в сети.

Следовательно, существует определенный риск атак человека посередине. Однако подключения будут происходить только локально. Сайты, такие как localhost.direct, не разрешаются в 127.0.0.1, а скорее инструктируют вас добавить его в файл hosts. Таким образом, шанс того, что злоумышленник сможет фактически занять позицию человека посередине, крайне мал.

Короче говоря: это выглядит хуже, чем есть, и любой сценарий, в котором это может быть использовано, крайне маловероятен.

Да, это опасно (и, откровенно говоря, глупо).

Очевидно, что это катастрофически небезопасно, если приложение содержит сертификат ЦС с закрытым ключом. Это даст злоумышленнику полную возможность подделки TLS на любом клиенте, который доверяет сертификату ЦС.

Если сертификат только для конкретного домена, это менее разрушительно, но все равно опасно. Злоумышленник может ударить только по этому конкретному домену – вероятно, только одно приложение, которое его использует – но это все равно может быть очень плохо. В зависимости от разрешений приложения и того, как используется домен, злоумышленник мог бы получить контроль над приложением и выполнять произвольный код от имени пользователя.

Даже для приложения, которое предназначено только для подключения через обратный адрес, существует две угрозы.

• По сети: Если приложение не изменяет файл HOSTS (нет, говорить пользователю сделать это за вас не считается; программное обеспечение не должно создавать огромную брешь в безопасности и затем говорить вам редактировать какой-то странный файл, чтобы исправить это), тогда разрешение имени вернется к DNS, который (обычно) легко подделать.
• Локальный злоумышленник: Даже если приложение успешно гарантирует, что будут использоваться только обратные адреса, использование общедоступного закрытого ключа означает, что непривилегированный злоумышленник на той же машине мог бы фактически подделать сервер (или клиент, как это ни странно), чтобы атаковать другого пользователя (возможно, с большими привилегиями, определенно с другими теми). Существуют способы, которыми приложение может обнаружить такое вмешательство (например, пытаясь сначала запустить сервер и не продолжая, если он не может привязать порт), но есть способы, которыми злоумышленник может это обойти (например, найдя сообщение, которое вызывает сбой сервера, и отправив его, как только сервер запускается, а затем запустив свой собственный вместо этого). Люди, как правило, забывают о локальных атаках повышения привилегий, но не должны; даже если вы единственный пользователь своей машины, локальные атаки повышения привилегий могут быть использованы для выхода из песочниц для ненадежных или высокорисковых приложений (браузеров, магазинных приложений и т. д.).

Дело в том, что никогда не бывает хорошей причины делать это. Для большинства межпроцессного взаимодействия вам следует использовать почти все кроме сетевых сокетов, защищенных TLS или нет. Именованные каналы, отображенная память, локальные (доменные Unix) сокеты, любые из многих специфичных для платформы вариантов… выбор не ограничен, и они быстрее, надежнее, способны и БОЛЕЕ безопасны.

Единственное исключение – если вы используете веб-просмотрщик в локальном приложении по какой-то причине и нужно указать конкретно на HTTPS-сервер. В этом случае вам следует сделать то же самое, что следует делать каждый раз, когда вам нужно доверять локальному TLS-серверу: сгенерировать сертификат ЦС + закрытый ключ локально, установить сертификат ЦС локально (обычно только для текущего пользователя!) и затем сгенерировать закрытый ключ + сертификат, подписанный закрытым ключом вашего локально сгенерированного ЦС. Это даже не требует повышенных привилегий (в отличие от изменения файла HOSTS), ни две установки не будут использовать один и тот же закрытый ключ, ни другие пользователи на машине не имеют доступа к какому-либо закрытому ключу (на самом деле, как только ключ ЦС используется для подписания сертификата для специфического домена, его можно удалить полностью), и вы не подвергаетесь риску того, что ваш ЦС отзовет ваш сертификат за грубое злоупотребление своим закрытым ключом!