Назад | Перейти на главную страницу

Проверка подлинности подписи ключа GPG

Я пытаюсь подтвердить целостность моих httpd-2.2.17.tar.gz образ.
Я выполнил шаги, описанные на следующих страницах:

Но я получил:

ВНИМАНИЕ: этот ключ не сертифицирован доверенной подписью!
gpg: нет никаких указаний на то, что подпись принадлежит владельцу.

Что мне нужно сделать, чтобы проверить подлинность ключа?

Существует две различные цели проверки файлов:

  1. A. для защиты от случайного повреждения во время загрузки

  2. для защиты от MITM-атака, или даже компрометация веб-сервера, если закрытый ключ pgp не был скомпрометирован.

Для A хеш-функция вроде SHA-1, MD5, ... более чем удовлетворительна. Однако не помешает использовать более современный хеш, который все еще считается криптографический.

Для B все становится намного сложнее. Для начала вы должны осуществлять все коммуникации правильно сертифицированный HTTPS (SSL):

https://httpd.apache.org/download.cgi#verify
https://httpd.apache.org/dev/verification.html#Validating
https://www.apache.org/dist/httpd/KEYS

Вам повезло, apache предоставляет такой доступ к своему сайту.

Теперь давайте оценим, какие риски остались и какие риски были снижены. Простая MITM-атака больше невозможна. Однако, чтобы выполнить MITM-атаку, злоумышленник может:

  1. Получите сертификат для этого веб-сайта от Центр сертификации по:

    • обманом заставить их поверить в то, что они владеют этим сайтом, и заплатить им.
    • обманывая браузеры, принимая их как ЦС (обратите внимание, что несколько правительств включены в браузеры как CAи что существующие центры сертификации могут делегировать полученное доверие третьим сторонам без какого-либо уведомления, см. инцидент с этисалатомЕсли после этого выяснится, что этот субПД делает какую-то дерьмо, и ЦС отказывается отозвать этот субПД, то все еще есть все веб-сайты, которые законно сертифицированы ЦС, что заставляет браузеры продолжать доверять ЦС.
    • путем взлома и кражи закрытого ключа CA
    • заставив их по закону сделать такое свидетельство (повестка в суд)
  2. Украсть закрытый ключ сервера, отправляющего данные.

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

Кроме того, если злоумышленник может просто скомпрометировать сервер веб-сайта, он может просто изменить файл, а также md5, sha1 или другие хэши, а также ключи pgp, которые он обслуживает, и, следовательно, ему не придется выполнять MITM- атака. Этот последний вариант является наиболее предпочтительным, поскольку зачастую проще попасть на сервер, чем получить сертификат.

Обратите внимание, что иногда хэши и загруженные файлы не обслуживаются из одного и того же места. Само по себе это хорошо. Это усложнило бы работу злоумышленнику. Допустим, у меня есть https-сертифицированный веб-сайт, и вы предлагаете несколько файлов для загрузки. Я мог бы предложить разместить хеши этих файлов на своем веб-сайте, чтобы помочь вам. Или, в случае apache, фактические загрузки выполняются на зеркалах, не имеющих https.

Теперь хеши являются решающим звеном в проверке. Обратите внимание, что MD5 был сломан и это SHA1 уже в пути. Это плохо со стороны apache - все еще предоставлять их в целях безопасности. Если ничего не помогает и оба они доступны, проверьте их оба. Насколько мне известно, коллизионная атака для получения одинаковых значений md5 и sha1 для двух файлов еще не обнаружена.

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

За пределами https:

Если https не удовлетворяет ваши потребности в безопасности (и на самом деле этого не должно быть) или https не был доступен для веб-сайта, что вы можете сделать?

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

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

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

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

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

Для обычных людей pgp и сеть доверия имеют серьезные проблемы:

  • ненадлежащее использование gpg и сети доверия нарушает его безопасность
  • правильное использование этого сложного, сложного и бесплатного инструмента, такого как gnupg, и его интерфейсы лохматые
  • если вы или другая сторона недостаточно хорошо закреплены в сети доверия, проверка ключей практически невозможна
  • цепочка доверия на самом деле означает, что вы должны доверять всем людям между ними. Чем дольше это становится, тем менее безопасно. Если, скажем, все ваши ссылки на ключ подписи apache проходят через одних и тех же лиц, которые могут организовать MITM-атаку, то pgp служит лишь ложным чувством безопасности.
  • Web of Trust помогает властям нарисовать карту вашей социальной сети точно так же, как facebook.

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

В заключение важно понять, что HTTPS и PGP не исключают друг друга. Никто не мешает вам попытаться использовать и то, и другое в меру своих возможностей. Следует понимать, что любые цепи безопасности настолько сильны, насколько сильны их самые слабые звенья. Скажем, ключ pgp, загруженный через https, имеет недостатки pgp и недостатки https. Каждое звено в цепочке добавляет к результату свои слабые места.

Я буду добавлять интересные ссылки к этому ответу по мере их обнаружения.

Смотрите также:

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

После того, как вы убедились в подлинности ключа, вам следует подписать этот открытый ключ своим личным ключом. После того, как вы подписали ключ, вы больше не будете получать эти ПРЕДУПРЕЖДЕНИЯ, потому что, подписав его, вы указали, что считаете ключ подлинным.