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

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

Поскольку «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 публичный ключ должен быть для А.com only
  • Клиент должен иметь открытый ключ для Trustwave, установленный в хранилище сертификатов своего браузера. 99,9% всех современных браузеров (1998+) включают корневой сертификат Trustwave. Если клиент Trustwave доверенный открытый ключ, то они могут доверять, что они на самом деле общение с XYZ, Inc.

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

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

Answer 2

А обычно конфигурируется с набором доверенных ЦС, которые отображают открытый ключ С в доверенных сущностях. В этом случае Б. Вы не ответили на свой вопрос в первом абзаце, или я что-то упустил?

Answer 3

Все, что может сделать сертификат, это обеспечить, чтобы связь между A и C была зашифрована таким образом, что C (или что-то еще, что установлено сертификатом) является единственным, способным его расшифровать.

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

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

В качестве дополнительной заметки есть hugesecurityissues с разрешением DNS.

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

Answer 4

Таким образом, клиент A должен знать, является ли сертификат C подлинным. Чья задача проверить это? Анс: Браузер. Как это проверить? Ans: Браузер проверяет, кто подписал сертификат. Кто подписал сертификат? Ans: C.A (Центр сертификации) под названием AweCerts.Inc Означает ли браузер этот ЦС. И доверяет ли броузеру СА? Анс: Да. Если броузер не доверяет, то A не может продолжить. И не только босс доверяет AweCerts, но и ее/ее друзьям (целая цепь). Как браузер знает, что этот сертификат был подписан AweCerts.Inc? Ans: Браузер имел соглашение с AweCerts. Microsoft делает это в IE's case.
Если браузер может разблокировать сообщение (внешнее покрытие) открытым ключом AweCerts, то он уверен, что он был «зашифрован с помощью AveCerts private key» или подписан Awecerts.

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

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