Что-то запутанное в цифровых сертификатах

Question

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

a) Предположим, клиент A хочет установить соединение с сервером B, расположенным по адресу www.some_domain.com. При установлении соединения с B, A может получить с другого конца сертификат X.509 C и открытый ключ, принадлежащий владельцу сертификата C.

Но как клиент может узнать, что владелец C на самом деле является сервером B, а не каким-либо другим объектом, который захватил (если это правильный термин) соединение и отправил свой собственный сертификат и открытый ключ на A ?

Единственный способ узнать, может ли клиент знать, действительно ли владелец C B, - это если поле C's Subject также указывает домен, для которого этот сертификат действителен, или если оно указывает организацию, для которой этот сертификат сертификат принадлежит (но это помогает, только если клиент знает, к какой организации принадлежит www.some_domain.com) ?!

спасибо

Answer 1

Все, что может сделать сертификат, это убедиться, что связь между A и C зашифрована таким образом, что C (или любой другой объект, на котором установлен сертификат) является единственным, кто может его расшифровать.в отношении того, кому принадлежит С.Некоторые центры сертификации попытаются установить, что данный субъект является тем, кем, по его словам, он является до выдачи сертификата.Однако, откровенно говоря, все это может быть дублировано, и большинство сайтов все равно не платят за этот уровень исследований (так называемая расширенная проверка).

Теперь, если какой-то мошенник украл сертификат с сервера C инастроить свой собственный сервер (с тем же полностью определенным доменным именем), тогда да, они могут выдать себя за другого.Однако для этого потребуется дополнительный шаг отравления разрешения DNS, чтобы запросы к www.some_domain.com отправлялись на сервер хакера, а не на оригинал.Как правило, гораздо проще просто взломать исходный сервер и установить собственное программное обеспечение для сбора данных.

В качестве примечания: огромный безопасность проблемы с разрешением DNS.

Еще одно замечание: недавно червь stuxnet использовал сертификат для подписи украденного кода, чтобы преодолеть некоторые средства защиты установки Windows.

Answer 2

A обычно настроен с набором доверенных CA, которые отображают открытый ключ C на доверенные объекты, в данном случае B. Вы не ответили на свой вопрос в первом абзаце или я что-то упустил?

Answer 3

Поскольку «C» подписан центром сертификации CA, который уже находится в вашей системе.Вот почему схема может быть нарушена правительствами, которые контролируют ЦС.

Если вы посмотрите на сертификат в своем браузере, то сможете увидеть, кто его подписал.Например, gmail подписан Thawte, который подписан Verisign.Поле CN помечено www.google.com, поэтому оно будет действительным только для этого домена.

Возможно, вы говорите о человеке посередине: http://en.wikipedia.org/wiki/Man-in-the-middle_attack

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

Таким образом, в вашем сценарии будет обманута только одна сторона.Проверьте шаг 2 ниже:

https://ssl.trustwave.com/support/support-how-ssl-works.php

• Шаг 1. Клиент устанавливает соединение с xyz.com через порт SSL, обычно 443. Это соединение обозначается через httpsвместо http.

• Шаг 2: xyz.com отправляет свой открытый ключ клиенту.Как только клиент получит его, его / ее браузер решит, можно ли продолжить.

  • Открытый ключ xyz.com НЕ ДОЛЖЕН истекать
  • Открытый ключ xyz.com должен бытьтолько для xyz.com
  • У клиента должен быть открытый ключ для Trustwave, установленный в хранилище сертификатов браузера.99,9% всех современных браузеров (1998+) включают корневой сертификат Trustwave.Если у клиента есть доверенный открытый ключ Trustwave, он может доверять тому, что он действительно общается с XYZ, Inc.

• Шаг 3. Если клиент решает доверять сертификату,Затем клиент будет отправлен на xyz.com его / ее открытый ключ.-Шаг 4: xyz.com затем создаст уникальный хеш и зашифрует его, используя как открытый ключ клиента, так и закрытый ключ xyz.com, и отправит его обратно клиенту.

• Шаг 5: КлиентБраузер расшифрует хеш.Этот процесс показывает, что xyz.com отправил хэш, и только клиент может прочитать его.
• Шаг 6. Клиент и веб-сайт теперь могут безопасно обмениваться информацией.

Answer 4

Таким образом, клиент A должен знать, является ли сертификат C подлинным. Чья задача это проверить? Ответ: браузер. Как это проверят? Ответ: Браузер проверяет, кто подписал сертификат. Кто подписал сертификат? Ответ: C.A (центр сертификации) с именем AweCerts.Inc Знает ли браузер этот CA. И доверяет ли брату CA? Ответ: да. Если брат не доверяет, то А не может продолжать дальше. И не только брат доверяет AweCerts, но и своим друзьям (всей цепочке). Как браузер узнает, что этот сертификат был подписан AweCerts.Inc? Ответ: Браузер заключил соглашение с AweCerts. Microsoft делает это в случае IE .
Если браузер может разблокировать сообщение (внешнее покрытие) с помощью открытого ключа AweCerts, то он уверен, что оно было «зашифровано с помощью закрытого ключа AweCerts» или подписано Awecerts.

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

Здесь есть интересный блог http://the -blueclouds.blogspot.nl / 2011/11 / public-key-private-key-hashing-blah.html