Как проверяются сертификаты ssl?
Какова последовательность шагов, необходимых для надежной проверки сертификата ssl? Мое (очень ограниченное) понимание заключается в том, что при посещении сайта https сервер отправляет сертификат клиенту (браузеру), а браузер получает информацию об эмитенте сертификата из этого сертификата, а затем использует его для связи с эмитентом и каким-то образом сравнивает сертификаты на срок действия.
- Как именно это делается?
- Как насчет этого процесса делает его невосприимчивым к атакам «человек-в-середине»?
- Что мешает случайному человеку создать собственную службу проверки для использования в атаках «человек в середине», поэтому все «выглядит» безопасным?
- Вставка сертификата (с закрытым ключом) в корне, хранилище сертификатов LocalMachine не выполняется в .NET 4
- Не удалось создать путь PKIX: не удалось найти допустимый путь сертификации для запрошенной цели
- Как предоставить ASP.NET доступ к закрытому ключу в сертификате в хранилище сертификатов?
- Получение Chrome для принятия самоподписанного локального сертификата
- Как преобразовать файл .pfx в хранилище ключей с помощью закрытого ключа?
- Как создать самозаверяющий сертификат с помощью C #?
- iOS получить профили конфигурации, которые установлены
- Как проверить, подписана ли APK или «отладить сборку»?
- Проверьте цепочку сертификатов с помощью проверки openssl
- Преобразование традиционного частного ключа PEM в закрытый ключ PKCS8
- Как решить «Не удалось установить доверительные отношения для безопасного канала SSL / TLS с полномочиями»
- Как продлить сертификат разработки iPhone?
- Получить список сертификатов из хранилища сертификатов в C #
Вот очень упрощенное объяснение:
-
Ваш веб-браузер загружает сертификат веб-сервера, содержащий открытый ключ веб-сервера. Этот сертификат подписан с закрытым ключом доверенного центра сертификации.
-
Ваш веб-браузер устанавливается с открытыми ключами всех основных органов сертификации. Он использует этот открытый ключ, чтобы убедиться, что сертификат веб-сервера действительно подписан доверенным центром сертификации.
-
Сертификат содержит имя домена и / или IP-адрес веб-сервера. Ваш веб-браузер подтверждает с помощью центра сертификации, что адрес, указанный в сертификате, является тем, к которому у него открытое соединение.
-
Ваш веб-браузер генерирует общий симметричный ключ, который будет использоваться для шифрования HTTP-трафика в этом соединении; это намного эффективнее, чем использование шифрования с открытым / закрытым ключом для всего. Ваш браузер шифрует симметричный ключ открытым ключом веб-сервера и отправляет его обратно, тем самым гарантируя, что только веб-сервер может его расшифровать, поскольку только веб-сервер имеет свой закрытый ключ.
Обратите внимание, что центр сертификации (CA) необходим для предотвращения атак типа «человек-в-середине». Однако даже неподписанный сертификат не позволит кому-либо проходить пассивно прослушивание вашего зашифрованного трафика, поскольку у них нет возможности получить доступ к вашему симметричному символу.
Стоит отметить, что помимо покупки сертификата (как упоминалось выше) вы также можете создавать свои собственные бесплатно; это называется «самозаверяющим сертификатом». Разница между самозаверяющим сертификатом и приобретенным является простой: купленный подписывается центром сертификации, о котором ваш браузер уже знает. Другими словами, ваш браузер может легко проверить подлинность приобретенного сертификата.
К сожалению, это привело к распространенному заблуждению, что самозаверяющие сертификаты по своей сути менее безопасны, чем те, что продаются коммерческими ЦА, такими как GoDaddy и Verisign, и что вы должны жить с предупреждениями / исключениями браузера, если вы их используете; это неверно .
Если вы надежно распространяете самозаверяющий сертификат (или сертификат CA, как предлагалось bobince) и устанавливаете его в браузерах, которые будут использовать ваш сайт , он будет настолько же безопасен, как тот, который был приобретен и не уязвим для человека в середине атаки и подделка сертификатов. Очевидно, это означает, что это возможно только в том случае, если только нескольким людям необходим безопасный доступ к вашему сайту (например, внутренние приложения, личные блоги и т. Д.).
В интересах повышения осведомленности и поощрения таких малоподобных блоггеров, как я, чтобы защитить себя, я написал учебник начального уровня, в котором более подробно объясняются концепции сертификатов и способы безопасного создания и использования самозаверяющего сертификата (в комплекте с образцами кода и скриншотами). Вот ссылка, если она будет полезной для кого-либо еще в будущем: http://www.clintharris.net/2009/self-signed-certificates/ .
Вы сказали, что
браузер получает информацию об эмитенте сертификата из этого сертификата, а затем использует это для связи с эмитентом и как-то сравнивает сертификаты на достоверность.
Клиент не должен проверять с эмитентом, потому что две вещи:
- все браузеры имеют предварительно установленный список всех основных ключей CA
- сертификат подписан, и эта подпись сама по себе является достаточным доказательством того, что сертификат действителен, потому что клиент может самостоятельно убедиться и не связаться с сервером эмитента, чтобы этот сертификат был подлинным. Это красота асимметричного шифрования.
Обратите внимание, что 2. не может быть выполнено без 1.
Это лучше объясняется в этой большой диаграмме, которую я сделал некоторое время назад
(перейдите к «что такое подпись?» внизу)
Клиент имеет открытые ключи открытых сертификатов SSL-сертификатов. Для получения доверия к серверу должна быть цепочка доверия от сертификата для сервера до промежуточных полномочий до одного из так называемых «корневых» сертификатов.
Вы можете проверить и / или изменить список доверенных органов. Часто вы делаете это, чтобы добавить сертификат для местного органа власти, который, как вы знаете, вы доверяете, например, компанию, на которую вы работаете, или школу, в которой вы участвуете, или что нет.
Список предварительно посещенных может варьироваться в зависимости от того, какой клиент вы используете. Крупные поставщики сертификатов SSL гарантируют, что их корневые сертификаты находятся во всех основных браузерах ($$$).
Атаки «обезьяна-в-середине» «невозможны», если у злоумышленника нет закрытого ключа доверенного корневого сертификата. Поскольку соответствующие сертификаты широко используются, воздействие такого частного ключа будет иметь серьезные последствия для безопасности электронной коммерции в целом. Из-за этого эти секретные ключи очень, очень тщательно охраняются.
если вы более технически настроены, этот сайт, вероятно, вы хотите: http://www.zytrax.com/tech/survival/ssl.html
Предупреждение: отверстие кролика идет глубоко :).