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 трафик фильтруется через прокси.
