Можно ли скопировать сертификат сервера на сервер злоумышленников, чтобы использовать его не по назначению?

Я спрашиваю себя, можно ли скопировать сертификат сервера на другой сервер, чтобы использовать его не по назначению. Пример: Злоумышленник посещает https-сайт X и копирует сертификат X.509. Он поместил украденный сертификат X.509 на свой сервер и хотел бы, чтобы ему доверяли.

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

Сервер отвечает сертификатом X.509. Клиент получает сертификат и успешно проверяет его, используя сохраненные корневые сертификаты. Почему сервер не должен быть аутентифицирован? Только когда клиент отправляет зашифрованное сообщение с использованием открытого ключа, сервер не может расшифровать сообщение, потому что он не владеет закрытым ключом.

Это правильно до сих пор?


person Sven W.    schedule 19.12.2013    source источник
comment
Вы ошибаетесь, но близки к истине, и я призываю вас продолжать пыхтеть. Имейте в виду, что существует два основных класса наборов шифров, которые следует изучать отдельно: чистый RSA и эфемерный метод diffie-hellman. Изучите RFC, rfc 2246 и его преемники. Соединение SSL не аутентифицируется до тех пор, пока от партнера не будет получено проверенное сообщение FINISHED.   -  person President James K. Polk    schedule 20.12.2013


Ответы (3)


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

Серверу также нужен закрытый ключ для подписи сообщений, отправляемых клиенту.

Сам протокол рукопожатия SSL/TLS эффективно включает в себя такое аутентифицированное сообщение, отправляемое клиенту. Если закрытый ключ недоступен, этот шаг завершится ошибкой до того, как будет отправлено какое-либо «настоящее» полезное сообщение.

person bobince    schedule 20.12.2013

Почему сервер не должен быть аутентифицирован?

Сертификат привязан к доменному имени.

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

Вы, вероятно, привыкли видеть это в действии на плохих конфигурациях веб-сервера. Вы когда-нибудь видели сообщение об ошибке «Этот сертификат предназначен для www.example.com», когда вы пытались посетить «example.com»?

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

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

person B-Con    schedule 19.12.2013
comment
Подмена домена — это попытка убедить браузер в том, что ресурс пришел из домена, из которого он на самом деле не пришел. Это действительно может позволить использовать украденный сертификат. - person B-Con; 19.12.2013
comment
Даже после подмены домена злоумышленник не может использовать только открытый ключ, чтобы обмануть клиента. Если бы она могла, то SSL был бы бессмысленным. См. ответ @bobince. Для согласования сеанса SSL сервер должен иметь доступ к закрытому ключу. - person Rob Napier; 20.12.2013
comment
Закрытый ключ сервера, а не закрытый ключ ЦС. Чтобы уточнить: спуфинг домена позволит браузеру загрузить сертификат HTTPS и подтвердить, что он пришел из указанного домена, но не позволит полностью согласовать сеанс TLS. (Я не уверен, какую ошибку пользовательского интерфейса пользователь может увидеть в этом случае.) - person B-Con; 21.12.2013

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

person Jcs    schedule 25.12.2013