id: Гость   вход   регистрация
текущее время 14:24 29/05/2024
Автор темы: Гость, тема открыта 05/11/2013 14:47 Печать
Категории: софт, gnupg, openpgp, спецификации, стандарты
https://www.pgpru.com/Форум/РаботаСGnuPG/ВопросыОтносительноПередачиКлючейПоHkps
создать
просмотр
ссылки

Вопросы относительно передачи ключей по hkps


При установке gnupg в линукс в дефолтном конфиге указан следующий сервер:
keyserver hkp://keys.gnupg.net


Однако, в ходе чтения различных руководств в интернете было выяснено, что подобный способ обновления и передачи ключей не самый лучший, т.к. эта информация передается открытым способом. И тот, кто наблюдает за траффиком, видит данные обновляемых при gpg —refresh-keys ключей. И поэтому рекомендуется использовать hkps сервера.
А именно предлагается сделать следующие изменения в конфиге gnupg:



где sks-keyservers.netCA.pem – есть сертификат, загружаемый с
https://sks-keyservers.net/sks-keyservers.netCA.pem


Хотелось бы разобраться с hkps поподробнее.


1. Используете ли вы hkps вместо дефолтного hkp? Оправдано ли это?
2. В каких случаях лучше оставить дефолтный keyserver без изменений?
3. Что это за сертификат такой (sks-keyservers.netCA.pem) и можно ли ему доверять?
4. Допустимо ли вообще сделать такую модификацию строки с кейсервером, которая приведена выше? Не опасно ли это?
5. И еще отдельный вопрос:
если посмотреть в браузере публичные ключи на сервере ключей, то там присутствует следующая надпись:


BEGIN PGP PUBLIC KEY BLOCK


Version: SKS 1.1.0

Что означает 'Version: SKS 1.1.0' ?


 
Комментарии
— SATtva (05/11/2013 15:21)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Хотелось бы разобраться с hkps поподробнее.

Протокол HKP — всего лишь сильной урезанный HTTP. HKPS — то же самое с дополнительным канальным SSL-шифрованием (в общем, аналог HTTPS).

Используете ли вы hkps вместо дефолтного hkp? Оправдано ли это?

Зависит от модели угрозы. Сервер в любом случае знает, какие ключи Вы запрашиваете.

Что это за сертификат такой (sks-keyservers.netCA.pem) и можно ли ему доверять?

Раз загружаете его с HTTPS, то доверие к нему будет на уровне SSL-сертификата веб-сервера (при условии, если сертификаты различаются).

Допустимо ли вообще сделать такую модификацию строки с кейсервером, которая приведена выше? Не опасно ли это?

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

Что означает 'Version: SKS 1.1.0' ?

Что пакет ключа сформирован сервером SKS (SubKeys Server) версии 1.1.0.
— unknown (05/11/2013 15:56, исправлен 05/11/2013 15:57)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Этот вопрос навеян этим?


После загрузки ключа я проверяю, что связь между данным ключом и адресом электронной почты не поменялась на множестве серверов ключей, TLS-сертификаты которых заверены независимо и не зашиты непосредственно в исходники самого пакета GPG (многопутевая криптографическая аутентификация в стиле Perspectives/Notary).

© Mike Perry.

— teta_tester (05/11/2013 16:54)   <#>
Этот вопрос навеян этим?

Да, но только отчасти.
Дальнейшие чтения матчасти на данную тему порождают еще кучу вопросов по устройству gnupg.

Однако простыми и очевидными для новичка являются следующие тезисы (из статьи):

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

Это же очевидно. Почему тогда задаются этими вопросами?

Кстати, а нет ли готовых рекомендуемых примеров gpg.conf? Чтобы посмотреть, кто как изощрается с настройками gnupg?
Вообще по поводу этого конфига – является ли он тайной за 7-ю печатями? Можно ли держать его, например, в git репозитории,
чтобы управлять историей его версий (в случае, если настройки будут совсем уже заморочными или будет много изменений) да и просто иметь его удаленно для новых машин?
Или это будет совсем уж неразумно?
— Гость (05/11/2013 17:47)   <#>

Непонятно, что хотел сказать автор. TLS-сертификаты некоторых серверов ключей зашиты в исходники GnuPG? Или он просто хочет сказать, что сверка сертификатов имеет смысл, потому что они не зашиваются в исодники GnuPG?


Да, внутренности GnuPG — не простая и очень хреново задокументированная вещь, здесь их описания раскиданы по множеству веток (в основном старых).


Очевидно, но люди об этом не задумываются точно так же, как при платежах своими кредитками они не думают о том, что добавляют информацию о своём местоположении, покупках, вкусах, предпочитаемых магазинах и прочем в перманентную базу данных, из которой эти записи уже не исчезнут никогда. Это тот тонкий случай, когда случайные и ничего не значащие факты незаметно превращаются во вполне значимую статистику.


Что-то было, но разбросано по всему фруму. Например, тут что-то проскакивало. Если гуглить по showpref site:pgpru.com, то много старых топиков находится, где обсуждали эти настройки. Опции no-emit-version и throw-keyids — тоже кандидаты на попадание в конфиг, особенно первая (вторая может вызвать side-эффекты).


Строго говоря, нет, если только там не будут указаны какие-то умолчальные получатели ваших сообщений (их ключи), которых вы бы сильно хотели скрыть. Большую часть ваших настроек и так видно из списков предпочтей вашего публичного ключа. Есть, конечно, особые нюансы, когда у вас имеется как анонимный ключ, так и неанонимный, и вы боитесь, что противник их сопоставит, т.к. настройки в обоих случаях будут одними и теми же.
— SATtva (05/11/2013 19:41)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Есть, конечно, особые нюансы, когда у вас имеется как анонимный ключ, так и неанонимный, и вы боитесь, что противник их сопоставит, т.к. настройки в обоих случаях будут одними и теми же.

Слишком велик риск напортачить. Я бы в подобном случае держал уникальные настройки под разными пользователями.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3