Вопросы относительно передачи ключей по 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' ?
комментариев: 11558 документов: 1036 редакций: 4118
Протокол HKP — всего лишь сильной урезанный HTTP. HKPS — то же самое с дополнительным канальным SSL-шифрованием (в общем, аналог HTTPS).
Зависит от модели угрозы. Сервер в любом случае знает, какие ключи Вы запрашиваете.
Раз загружаете его с HTTPS, то доверие к нему будет на уровне SSL-сертификата веб-сервера (при условии, если сертификаты различаются).
Это штатный функционал, он ничем не опасен. В любом случае, он не может ухудшить ситуацию по сравнению с доступом к серверу по открытому HKP.
Что пакет ключа сформирован сервером SKS (SubKeys Server) версии 1.1.0.
комментариев: 9796 документов: 488 редакций: 5664
Этот вопрос навеян этим?
© Mike Perry.
Да, но только отчасти.
Дальнейшие чтения матчасти на данную тему порождают еще кучу вопросов по устройству gnupg.
Однако простыми и очевидными для новичка являются следующие тезисы (из статьи):
Это же очевидно. Почему тогда задаются этими вопросами?
Кстати, а нет ли готовых рекомендуемых примеров gpg.conf? Чтобы посмотреть, кто как изощрается с настройками gnupg?
Вообще по поводу этого конфига – является ли он тайной за 7-ю печатями? Можно ли держать его, например, в git репозитории,
чтобы управлять историей его версий (в случае, если настройки будут совсем уже заморочными или будет много изменений) да и просто иметь его удаленно для новых машин?
Или это будет совсем уж неразумно?
Непонятно, что хотел сказать автор. TLS-сертификаты некоторых серверов ключей зашиты в исходники GnuPG? Или он просто хочет сказать, что сверка сертификатов имеет смысл, потому что они не зашиваются в исодники GnuPG?
Да, внутренности GnuPG — не простая и очень хреново задокументированная вещь, здесь их описания раскиданы по множеству веток (в основном старых).
Очевидно, но люди об этом не задумываются точно так же, как при платежах своими кредитками они не думают о том, что добавляют информацию о своём местоположении, покупках, вкусах, предпочитаемых магазинах и прочем в перманентную базу данных, из которой эти записи уже не исчезнут никогда. Это тот тонкий случай, когда случайные и ничего не значащие факты незаметно превращаются во вполне значимую статистику.
Что-то было, но разбросано по всему фруму. Например, тут что-то проскакивало. Если гуглить по showpref site:pgpru.com, то много старых топиков находится, где обсуждали эти настройки. Опции no-emit-version и throw-keyids — тоже кандидаты на попадание в конфиг, особенно первая (вторая может вызвать side-эффекты).
Строго говоря, нет, если только там не будут указаны какие-то умолчальные получатели ваших сообщений (их ключи), которых вы бы сильно хотели скрыть. Большую часть ваших настроек и так видно из списков предпочтей вашего публичного ключа. Есть, конечно, особые нюансы, когда у вас имеется как анонимный ключ, так и неанонимный, и вы боитесь, что противник их сопоставит, т.к. настройки в обоих случаях будут одними и теми же.
комментариев: 11558 документов: 1036 редакций: 4118
Слишком велик риск напортачить. Я бы в подобном случае держал уникальные настройки под разными пользователями.