Как проверяются ssl-сертификаты?

У клиента есть предварительно заполненное хранилище открытых ключей центров сертификации SSL. Чтобы серверу можно было доверять, должна существовать цепочка доверия от сертификата для сервера через промежуточные органы до одного из так называемых «корневых» сертификатов.

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

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

Атаки «обезьяна в середине» «невозможны», если у злоумышленника нет закрытого ключа доверенного корневого сертификата. Поскольку соответствующие сертификаты широко используются, раскрытие такого закрытого ключа может иметь серьезные последствия для безопасности электронной коммерции в целом. Из-за этого эти закрытые ключи очень и очень тщательно охраняются.

Вот очень упрощенное объяснение:

1. Ваш веб-браузер загружает сертификат веб-сервера, который содержит открытый ключ веб-сервера. Этот сертификат подписан закрытым ключом доверенного центра сертификации.

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

3. Сертификат содержит доменное имя и / или IP-адрес веб-сервера. Ваш веб-браузер подтверждает в центре сертификации, что адрес, указанный в сертификате, является тем адресом, к которому он имеет открытое соединение.

4. Ваш веб-браузер генерирует общий симметричный ключ, который будет использоваться для шифрования HTTP-трафика в этом соединении; это намного эффективнее, чем использование шифрования с открытым / закрытым ключом для всего. Ваш браузер шифрует симметричный ключ с помощью открытого ключа веб-сервера, а затем отправляет его обратно, таким образом гарантируя, что только веб-сервер может его расшифровать, поскольку только веб-сервер имеет свой закрытый ключ.

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

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

К сожалению, это привело к распространенному заблуждению о том, что самозаверяющие сертификаты по своей сути менее безопасны, чем сертификаты, продаваемые коммерческими центрами сертификации, такими как GoDaddy и Verisign, и что вы должны жить с предупреждениями / исключениями браузера, если вы их используете; это неверно.

Если вы безопасно распространяете самозаверяющий сертификат (или сертификат CA, как предлагал bobince) и устанавливаете его в браузерах, которые будут использовать ваш сайт, он так же безопасен, как купленный, и не уязвим для атак типа «злоумышленник в середине» и подделки сертификатов. Очевидно, это означает, что это возможно только в том случае, если только нескольким людям нужен безопасный доступ к вашему сайту (например, внутренние приложения, личные блоги и т. д.).

Вы сказали, что

the browser gets the certificate's issuer information from that certificate, then uses that to contact the issuerer, and somehow compares certificates for validity.

Клиенту не нужно уточнять у эмитента, потому что две вещи:

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

Обратите внимание, что 2. невозможно обойтись без 1.

Это лучше объясняется в большая диаграмма, который я сделал некоторое время назад.

(перейдите к "что за подпись?" внизу)

если вы более технически подкованы, возможно, вам нужен этот сайт: http://www.zytrax.com/tech/survival/ssl.html

предупреждение: кроличья нора уходит глубоко :).

Я ЗНАЮ, ЧТО НИЖЕ ДЛИННО, НО ЭТО ПОДРОБНО, ЕЩЕ ДОСТАТОЧНО УПРОЩЕННО. ВНИМАТЕЛЬНО ПРОЧИТАЙТЕ, И Я ГАРАНТИРУЮ, что ВЫ НАЧНЕТЕ НАЙТИ, ЭТА ТЕМА НЕ ВСЕ СЛОЖНАЯ.

Во-первых, любой может создать 2 ключа. Один для шифрования данных, а другой для дешифрования данных. Первый может быть закрытым ключом, а второй - открытым ключом AND VICERZA.

Во-вторых, проще говоря, центр сертификации (CA) предлагает услугу создания сертификата для вас. Как? Они используют определенные значения (имя эмитента ЦС, открытый ключ вашего сервера, название компании, домен и т. д.), А также свой закрытый ключ SUPER DUPER ULTRA SECURE SECRET и шифруют эти данные. Результатом этих зашифрованных данных является ПОДПИСЬ.

Итак, теперь центр сертификации возвращает вам сертификат. Сертификат - это в основном файл, содержащий ранее упомянутые значения (имя эмитента CA, название компании, домен, открытый ключ вашего сервера и т. д.), ВКЛЮЧАЯ подпись (т. Е. Зашифрованную версию последних значений).

Теперь, учитывая все вышесказанное, запомните часть ДЕЙСТВИТЕЛЬНО ВАЖНО: ваше устройство / ОС (Windows, Android и т. д.) В значительной степени хранит список всех основных / доверенных центров сертификации и их ОБЩЕСТВЕННЫЕ КЛЮЧИ (если вы думаете, что эти открытые ключи используются для расшифровки подписей внутри сертификатов, ТЫ ПРАВ!).

Хорошо, если вы прочитаете вышеизложенное, этот последовательный пример теперь будет проще простого:

1. Компания Example-Company просит Example-CA создать для них сертификат.
2. Example-CA использует свой супер закрытый ключ для подписи этого сертификата и выдает сертификат Example-Company.
3. Завтра интернет-пользователь Боб использует Chrome / Firefox и т. д. перейти к https://example-company.com. Большинство, если не все, браузеры в настоящее время ожидают возврата сертификата от сервера.
4. Браузер получает сертификат с example-company.com. В сертификате указано, что он был выдан Example-CA. Так уж получилось, что ОС Боба уже имеет Example-CA в своем списке доверенных CA, поэтому браузер получает открытый ключ Example-CA. Помните: все это происходит на компьютере / мобильном телефоне Боба и т. д., А не по сети.
5. Итак, теперь браузер расшифровывает подпись в сертификате. НАКОНЕЦ, браузер сравнивает расшифрованные значения с содержимым самого сертификата. ЕСЛИ СОДЕРЖАНИЕ СООТВЕТСТВУЕТ, ЭТО ДЕЙСТВИТЕЛЬНАЯ ПОДПИСЬ!

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

Как насчет атаки человека посередине?

Это одна из основных причин (если не основная причина) создания вышеуказанного стандарта.

Допустим, хакер-Джейн перехватывает запрос интернет-пользователя-Боба и отвечает своим сертификатом. Тем не менее, hacker-Jane по-прежнему достаточно осторожен, чтобы указать в сертификате, что эмитент был Example-CA. Наконец, хакер-Джейн вспоминает, что она должна поставить подпись на сертификате. Но какой ключ использует Джейн для подписи (т.е. создания зашифрованного значения основного содержимого сертификата) сертификата ?????

Так что даже если хакер-Джейн подписала сертификат своим собственным ключом, вы увидите, что будет дальше. Браузер скажет: «Хорошо, этот сертификат выпущен Example-CA, давайте расшифруем подпись открытым ключом Example-CA». После расшифровки браузер замечает, что содержимое сертификата вообще не совпадает. Следовательно, браузер дает пользователю очень четкое предупреждение и говорит, что не доверяет соединению.