Существует ли концепция доверия сертификату SSL / TLS для идентификации одного веб-сайта, но не для того, чтобы действовать в качестве CA для других сертификатов?

256
Ethan T

Я регулярно сталкиваюсь с плохими сертификатами в своей внутренней сети (или на временных серверах без надлежащим образом подписанного сертификата). Я не сталкивался с подходом, который позволяет мне сохранять сертификат одного веб-сайта (включая его CN) в браузере, не доверяя ему как удостоверяющему органу для других веб-сайтов. Возможно ли это концептуально или это выходит за рамки системы PKI?

Изменить, чтобы уточнить : допустим, я работаю на каком-то локальном сервере megaserver. Я получаю к нему доступ через https: // megaserver в браузере. Имеет самозаверяющий сертификат. Чтобы на данный момент получить безопасный доступ к этому серверу, я добавляю его сертификат в свое хранилище CA в своем браузере. Кто-то крадет этот сертификат, создает новый сертификат для https://www.google.com, подписывает его megaserverсертификатами и нападает на меня в стиле «человек посередине». Мой браузер принимает сертификат Google, потому что он подписан доверенным сертификатом CA в моей системе. Возможен ли этот гипотетический сценарий?

0
Это основная особенность всей экосистемы SSL. Если вы доверяете некоторому ЦС, то все, что было подписано этим ЦС, будет доверено вашему браузеру. В этом весь смысл использования CA в качестве проверенной сторонней системы проверки. Если временные сайты, о которых вы говорите, используют самозаверяющие сертификаты, то их CN должны соответствовать только этому конкретному CN. Сертификатам этого типа можно доверять индивидуально для каждого сайта. Alex 7 лет назад 0
@alex Я добавил пояснения. Ограничивает ли CN сертификата его способность подписывать другие сертификаты? Ethan T 7 лет назад 0
Нет. CA может быть, например, abcd.com, и они могут подписать xyz.net, qwert.com, но прежде чем они это сделают, они проверяют владельцев xyz.net или qwert.com либо простой проверкой по электронной почте, либо вплоть до запроса паспорт, телефонные счета и тд. Вот почему вы доверяете CA, потому что они проверили владельцев доменов и подписали свои сертификаты на успех. Существует 3 основных браузера и несколько операционных систем, которые управляют доверием ЦС и отправляют список ЦС со своими продуктами. Если ЦС отсутствует в таких списках доверенных ЦС, можно добавить ЦС вручную в хранилище сертификатов и доверять любым другим сертификатам, на которые они подписаны. Alex 7 лет назад 0

2 ответа на вопрос

2
garethTheRed

Да.

Из RFC 5280:

4.2.1.9. Основные ограничения

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

Затем он продолжает:

Если расширение базовых ограничений отсутствует в сертификате версии 3 или расширение присутствует, но логическое значение cA не указано, то сертифицированный открытый ключ НЕ ДОЛЖЕН использоваться для проверки подписей сертификатов.

эффективно проверять подписи сертификатов - значит действовать как CA.

Поэтому, если для вашего самозаверяющего сертификата не установлен CA Basic Constraint, установленный в значение true, его нельзя использовать для подписи подчиненных сертификатов.

Вы уверены, что все эти самозаверяющие сертификаты имеют этот флаг, установленный в true? Если это так, вам действительно нужно поговорить с тем, кто их генерирует, и направить их в сторону бесплатных онлайн-ресурсов для обучения PKI.


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

Лучший подход - убедиться, что вы управляете тем, кто входит в систему на устройствах, которые создают эти сертификаты. Системы, использующие OpenSSL, GnuTLS, Java и т. Д., Могут защитить паролем закрытый ключ. Windows шифрует закрытый ключ, но как только администратор вошел в систему на этом компьютере с Windows, закрытый ключ фактически доступен для взятия.

0
Alex

Q: Я добавляю его сертификат в мой CA-магазин в моем браузере. Кто-то крадет этот сертификат, создает новый сертификат для https://www.google.com

Вы добавляете в хранилище сертификатов Открытый ключ самостоятельно созданного локального ЦС. Единственный владелец закрытого ключа CA может подписать чей-либо сертификат (как вы сказали для https://www.google.com ), поэтому кража открытого ключа CA из вашего браузера бесполезна, поскольку он не является секретным и не может быть использован для подписания других сертификатов.

В: Мой браузер принимает сертификат Google, потому что он подписан доверенным сертификатом CA в моей системе. Возможен ли этот гипотетический сценарий?

Вы доверяете своему браузеру, который, в свою очередь, доверяет определенной области CA. Если вы добавили в свой браузер свой локальный центр сертификации в качестве доверенного для хранилища сертификатов, то вы автоматически доверяете всем сертификатам, подписанным этим локальным центром сертификации.

Таким образом, ИТ-отдел, который управляет вашим локальным центром сертификации, может выдать и подписать поддельный сертификат для google.com, и ваш браузер будет доверять ему, но ... Вот две технические детали, которые вам необходимо знать.

Когда вы подключаетесь к какому-либо httpsдомену напрямую, веб-сервер отвечает общедоступным сертификатом, который содержит информацию о том, кто подписал этот сертификат, и браузере, ищущем в своем хранилище сертификатов CA, который подписал сертификат этого веб-сервера, так что вы можете подумать, что это будет тяжелой работой для ребята, которые пытаются подделать google.com, которым следует настроить поддельную копию google.com в качестве своего собственного веб-сервера и переопределить запись DNS, которая будет указывать на поддельный веб-сайт, притворяющийся google.com

Но на самом деле это можно сделать относительно легко. Хотя это звучит как невозможно (или трудно сделать это), я должен сообщить вам, что делать это нетрудно, и на самом деле это обычная практика для многих компаний по отслеживанию / перехвату httpsтрафика по различным причинам (фильтрация, мониторинг и регистрация) используя прозрачный (или с авторизацией) http Proxy.

Если вы добавили локальный ЦС в хранилище сертификатов, то, если ваша компания использует прокси-сервер http, этот прокси-сервер может на лету создавать поддельные сертификаты для любых httpsподключений и передавать их в ваш браузер, и ваш браузер будет доверять (как я описывал ранее) таким поддельным сертификатам, Прокси-сервер со своей стороны может дешифровать такие соединения, поскольку его собственные закрытые ключи для всех выданных сертификатов с целью фильтрации, мониторинга, ведения журнала и в случае, если соединение обошло фильтр прокси-сервера, прокси-сервер запросит целевой реальный сайт как клиента, а затем повторно зашифрует ответьте и вернитесь к исходному месту назначения (или он может решить воспроизвести фальшивое тайм-аут соединение, если некоторые правила требуют этого).

Что я могу посоветовать вам, если вы не хотите подвергаться httpsфильтрации - настройте какую-нибудь виртуальную машину (например, VirtualBox) с ОС, в которой вам удобно, и добавьте туда свой локальный ЦС, сохраняя хост-компьютер не зараженным локальным ЦС.
Другое решение - вы можете использовать разные профили в вашем браузере (Firefox хорош в этом), один для работы, которая будет содержать ваш сертификат локального CA, и другой частный профиль, который не включает локальный CA. Таким образом, вы (на самом деле браузер) можете быстро обнаружить события, если ваш httpsтрафик фильтруется через прокси.

Похожие вопросы