Вопрос SSL: как ROOT CA проверяет подпись

Question

Говорить при использовании https браузер делает запрос на сервер, а сервер возвращает свой сертификат, включая открытый ключ и подпись ЦС.

В этот момент браузер попросит свой ЦС проверить, действительно ли данный открытый ключ принадлежит серверу или нет?

Как эта проверка выполняется корневым сертификатом в браузере?

Чтобы привести пример: Скажем serverX получил сертификат от CA "rootCA". Браузер имеет копию локального хранилища rootCA. Когда браузер ping serverX и он отвечает своим открытым ключом + сигнатурой. Теперь корневой ЦС будет использовать свой закрытый ключ для дешифрования подписи и убедиться, что он действительно serverX?

Как это работает?

Answer 1

У вашего сервера есть сертификат, состоящий из частного и открытого ключа. Конечно, сервер никогда не выдаёт закрытый ключ, но каждый может получить открытый ключ. Открытый ключ встроен в формат контейнера сертификата. Этот формат содержит IP-адрес или доменное имя сервера, владельца этого IP-адреса/доменного имени, адрес электронной почты владельца и т. Д.

Все это подписывается доверенным органом. У доверенного органа, также известного как центр сертификации (CA), также есть пара частного/открытого ключа. Вы даете им свой сертификат, они проверяют правильность информации в контейнере и подписывают ее своим личным ключом, к которому они имеют доступ.

Открытый ключ ЦС по умолчанию установлен в пользовательской системе, наиболее известные ЦС включены уже в стандартную установку вашей любимой ОС или браузера.

Когда пользователь подключается к вашему серверу, ваш сервер использует закрытый ключ для подписи некоторых данных, пакетов, которые подписали данные вместе с открытым ключом и отправляет все клиенту.

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

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

Последнее, но не менее важное: оно проверяет информацию в контейнере открытого ключа. Действительно ли IP-адрес или доменное имя соответствует IP-адресу или доменному имени сервера, с которым в данный момент разговаривает клиент? Если нет, то что-то подозрительное!

Люди могут спросить: что мешает хакеру просто создавать свою собственную пару ключей и просто помещать ваше доменное имя или IP-адрес в сертификат? Легко: если он это сделает, ни один СА не подпишет свой ключ. Чтобы получить подпись ЦС, вы должны доказать, что вы действительно являетесь владельцем этого IP-адреса или имени домена. Хакер - нет, он не может этого доказать, он не получит подпись. Так что это не сработает.

Хорошо, как насчет того, чтобы хакер регистрировал свой домен, создавал для этого сертификат и подписывал его ЦС? Это работает, он получит его CA подписан, это его домен, не проблема. Однако он не может использовать это при взломе вашего соединения. Если он использует этот сертификат, браузер сразу увидит, что подписанный открытый ключ предназначен для домена example.net, но в настоящее время он разговаривает с example.com, а не с одним и тем же доменом, поэтому что-то снова подозрительно.

Answer 2

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

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

CACert.org имеет эту же проблему, имеет действующие сертификаты, но поскольку браузеры не имеют своих корневых сертификатов в своем списке, их сертификаты генерируют предупреждения до тех пор, пока пользователи не загрузят корневые ЦС и не добавят их в свой браузер.

Answer 3

Сертификаты основаны на использовании асимметричного шифрования, такого как RSA. У вас есть два ключа, обычно называемые частными и открытыми ключами. Что-то вы encrypt с закрытым ключом можно дешифровать только с помощью открытого ключа. (И, фактически, наоборот.)

Вы можете думать о сертификате как о паспортной или водительской лицензии: это удостоверение, в котором говорится: «Это я есть, вы можете доверять ему, потому что это было дано мне кем-то (например, Verisign) вы доверяете ». Это делается с помощью «подписи», которая может быть рассчитана с использованием открытого ключа центра сертификации. Если данные - это то, что первоначально получил ЦС, вы можете проверить сертификат.

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

Answer 4

Сертификат сервера подписан с закрытым ключом ЦС. Браузер использует открытый ключ CA для проверки подписи. Прямой связи между браузером и ЦС нет.

Важным моментом является то, что браузер поставляется с открытым ключом CA. В Firefox см. Инструменты-> Параметры-> Дополнительно-> Шифрование-> ПросмотрСертификаты-> Органы власти. Поэтому браузер знает заранее все CA, которым он может доверять.

Если вы этого не понимаете, изучите основы асимметричной криптографии и цифровых подписей.