Блог

Какая последовательность шагов необходима для безопасной проверки ssl-сертификата? Мое (очень ограниченное) понимание заключается в том, что при посещении сайта https сервер отправляет сертификат клиенту (браузеру), и браузер получает информацию об издателе сертификата из этого сертификата, затем использует ее для связи с эмитентом и каким-то образом сравнивает сертификаты на действительность.

• Как именно это делается?
• Что в этом процессе делает его невосприимчивым к атакам типа «человек посередине»?
• Что мешает какому-то случайному человеку настроить свою собственную службу проверки для использования в атаках типа «человек посередине», чтобы все «выглядело» безопасным?

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

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

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

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

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

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

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

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

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

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

Обратите внимание, что 2. не может быть выполнено без 1.

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

(переходим к «что такое подпись?» внизу)

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

Прежде всего, любой может создать 2 ключа. Один для шифрования данных, а другой для расшифровки данных. Первый может быть закрытым ключом, а второй — открытым ключом и НАОБОРОТ.

Во-вторых, проще говоря, центр сертификации (CA) предлагает услугу создания сертификата для вас. Как? Они используют определенные значения (имя эмитента CA, открытый ключ вашего сервера, название компании, домен и т. Д.), И они используют свой СУПЕР-ПУПЕР-СВЕРХЗАЩИЩЕННЫЙ СЕКРЕТНЫЙ закрытый ключ и шифруют эти данные. Результатом этих зашифрованных данных является ПОДПИСЬ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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