Ключевой перехват сертификата

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

0
задан 18 February 2015 в 09:20
2 ответа

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

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

Так как такая строгая проверка часто обременительна или неосуществима, PGP также предусматривает что-то позвонившее сеть доверия. Вкратце: Люди подписывают ключи, которым они сильно верят, чтобы быть подлинными (надо надеяться, лично проверив их, как ранее описано), и они распределяют те ключи повсюду. Затем если я получаю ключ, который был подписан кем-то, кому я доверяю (т.е. кем-то в моей сети доверия), я могу быть уверен, что ключ является подлинным.

Если с другой стороны, я получаю ключевой сертификат без доверяемых подписей, и это трудно или невозможно для меня лично проверить сертификат со своим владельцем, то я нахожусь в неопределенном положении. Я должен доверять этому ключу или нет? Ответ будет зависеть от ряда факторов, включая: где я получил ключ от, и для чего я использую ключ. Решение не может быть легким. Например, я просмотрел бы с некоторым подозрением любой веб-сайт, который обеспечивает и подпись и сертификат, должен был проверить ту же самую подпись, так как та пара файлов, возможно, была помещена там любым. У меня было бы немного больше уверенности в подписи и сертификате, если бы я получил их из двух отдельных, независимых мест (как с веб-сайта и общественности keyserver, соответственно).

В системах с Центрами сертификации (CA), действующими как доверенные третьи стороны (как та, используемая в сети для аутентификации сертификаты хоста SSL/TLS), независимый второй канал, используемый для проверки, является хранилищем сертификатов открытого ключа CA на локальном ПК. Предполагается, что локальная база ключей CA Вашего ПК инициализируется и обновляется только доверяемыми средствами, так, чтобы у Вас был (надо надеяться), высокий уровень уверенности, что АВАРИЯ и ключи там являются подлинными. (Обратите внимание, что Вы также доверчивы, что все они АВАРИЯ в Вашей базе ключей на самом деле защищены. Основана ли та уверенность хорошо, обсуждение в течение другого дня.)

Когда веб-сайт представляет свой сертификат хоста Вашему браузеру во время установки SSL/соединения TLS, проверок браузера, был ли сертификат подписан CA в локальном хранилище CA Вашего ПК. [Для простоты я игнорирую объединение в цепочку сертификата, которое ничего не добавляет к этому discusson.], Чтобы MITM успешно имитировал аутентифицируемый в SSL веб-сайт к Вашему браузеру, он должен был бы добраться, его поддельный сертификат хоста подписался одной из АВАРИИ в Вашем локальном хранилище CA. Существует несколько путей, которые могли произойти. Если некоторое вредоносное программное обеспечение влезло в Ваше локальное хранилище CA, то Ваш браузер мог быть обманут поддельным сертификатом, подписанным фальшивкой Приблизительно. С другой стороны, если законный CA (как Verisign или Thawte) будет обманут в подписание поддельного сертификата, то Ваш браузер примет его как реальный, и нет очень, можно делать с этим. Вы могли попытаться удалить из своего хранилища CA все они АВАРИЯ, которые, как известно, подписали плохие сертификаты, но затем Ваш браузер начал бы отклонять все абсолютно действительные сертификаты, подписанные теми АВАРИЯ.Не очень.

Таким образом, MITM может успешно выполниться, только если процесс проверки ключа/сертификата ниспровергается. К сожалению, часто любой слишком трудно строго проверить сертификат (в случае PGP/GnuPG), или процесс может быть отравлен различными средствами (в случае систем доверенной третьей стороны).

2
ответ дан 4 December 2019 в 13:00
  • 1
    BTW, (связанные браузеры) локальное хранилище CA заполнено при установке браузера (т.е. в исполняемом файле это загружается с веб-сайта), правильно? Если так, мы вернулись к проблеме :) –  Dor 29 November 2010 в 21:43

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

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

1
ответ дан 4 December 2019 в 13:00
  • 1
    +1. Хороший для упоминания подписывающих ключ сессий :) –  Dor 29 November 2010 в 21:19

Теги

Похожие вопросы