Проверка подлинности ключа 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

Вы находитесь в удаче, апач действительно обеспечивает такой доступ к их веб-сайту.

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

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

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

2. Украдите закрытый ключ сервера, отправляющего данные.

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

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

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

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

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

Вне https:

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

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

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

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

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

Что это все означает на практике? Ну, если Вы посреди geek-knows-geek мира, это, вероятно, дает Вам разумную защиту. Для остальной части мира это больше похоже на monstertruck без бензина.

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

• неправильное использование gpg и сеть доверия повреждают свою безопасность
• надлежащее использование его является трудными, сложными и бесплатными инструментами как gnupg, и это - frontends, являются косматыми
• если Вы или другая сторона не хорошо привязываетесь в сети доверия, проверка, что ключи почти невозможны
• цепочка доверия действительно означает, что необходимо доверять всем промежуточным людям. Чем дольше это становится, тем менее безопасным. Если говорят, что все Ваши ссылки на апачский ключ подписи проходят через тех же людей, которые могли бы настроить MITM-нападение, чем pgp только служит ложным чувством защищенности.
• Сеть Доверия помогает полномочиям нарисовать карту Вашей социальной сети точно так же, как Facebook.

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

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

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

См. также:

• Https везде плагин Firefox, который заставит Ваш браузер перенаправить Вас к https в ряде известных сайтов.
• Перспектива - плагин Firefox, который позволяет просить, чтобы компьютеры во всем мире проверили, что они получают тот же сертификат HTTPS для веб-сайта, как Вы делаете. Обратите внимание, что трафик между Вами и этими "нотариусами" подписывается, но не шифруется. Вы таким образом открыто уведомляете тех и потенциальных соглядатаев, к каким сайтам Вы просматриваете.
• Как развернуть HTTPS правильно
• Правоохранительное устройство ниспровергает SSL
• Certied находится: обнаружение и правительственные нападения перехвата нанесения поражения на SSL