Какова цель аргумента -nodes в openssl?

103

Какова цель -nodesаргумента в openssl?

openssl

Stack Overflow - это сайт для вопросов по программированию и разработке. Этот вопрос кажется не по теме, потому что он не о программировании или разработке. См. Какие темы можно задать здесь в Справочном центре. Возможно, лучше спросить Super User или Unix & Linux Stack Exchange .

— jww 01

@jww Я не согласен, openssl - это низкоуровневый инструментарий, и разработчикам все время приходится иметь с ним дело. Граница довольно расплывчата, и было бы большой потерей не разрешать здесь вопросы об openssl просто потому, что это интерфейс командной строки, а не C lib.

— gtd

@gtd - это частая жалоба, когда я их помечаю. Также см. Где я могу задать вопросы о Dev Ops? . (Но я думаю, что ошибся с этим - вопрос из 2011 года, и я считаю, что тогда он был по теме. Я не люблю наказывать за изменение политики).

— jww

@gtd - re: «openssl - это низкоуровневый инструментарий, и разработчикам постоянно приходится иметь с ним дело». - вот для чего нужны Super User или Unix & Linux Stack Exchange . «... было бы большой потерей не допускать вопросов openssl ...» - здесь всегда приветствуются вопросы программирования на C openssl. Мы не пропустим потерю вопросов, не связанных с программированием, потому что Stack Overflow - это сайт программирования и разработки. Есть и другие сайты, на которые можно пойти, если вы не знаете, как использовать команду.

— jww

Спасибо за ссылку, я опубликую там свой ответ, так как считаю это очень важным вопросом.

— gtd

Ответы:

124

Вариант -nodes- это не английское слово «узлы», а «no DES». Если указано в качестве аргумента, это означает, что OpenSSL не будет шифровать закрытый ключ в файле PKCS # 12 .

Чтобы зашифровать закрытый ключ, вы можете опустить, -nodesи ваш ключ будет зашифрован с помощью 3DES-CBC. Чтобы зашифровать ключ, OpenSSL запрашивает пароль и использует этот пароль для генерации ключа шифрования с помощью функции создания ключа EVP_BytesToKey .

В зависимости от вашей версии OpenSSL и скомпилированных опций вы можете предоставить эти опции вместо -nodes:

-des          encrypt private keys with DES
-des3         encrypt private keys with triple DES (default)
-idea         encrypt private keys with idea
-seed         encrypt private keys with seed
-aes128, -aes192, -aes256
              encrypt PEM output with cbc aes
-camellia128, -camellia192, -camellia256
              encrypt PEM output with cbc camellia

В конечном итоге на уровне библиотеки OpenSSL вызывает функцию PEM_write_bio_PrivateKey с выбранным вами алгоритмом шифрования (или его отсутствием).

— индив
источник

Вы имеете в виду шифрование с паролем?

— Flimm

@Flimm: Да, защищен паролем. Пароль генерирует ключ шифрования с использованием алгоритма получения ключа, и шифрование выполняется с помощью ключа, а не пароля. Единственный способ использовать зашифрованный ключ - сначала его расшифровать, для чего вам нужно знать пароль, которым он был зашифрован, чтобы сгенерировать тот же ключ.

— индив

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

— phil294

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

— indiv

edit: nginx v1.7.3 добавил директиву ssl_password_file, которая считывает парольные фразы из указанного файла, пытаясь каждую парольную фразу на encrypted-private.key контекста

indiv правильно, что -nodesаргумент означает, что OpenSSL создаст незашифрованный private.key ; в противном случае будет предложено ввести кодовую фразу для создания encrypted-private.key . см. req , pkcs12 , CA.pl

однако я считаю, что цель (для программистов) в том, что:

HTTP-серверы (например, Apache , Nginx ) не могут читать encrypted-private.key без парольной фразы →
- Вариант A - каждый раз при запуске HTTP-сервера необходимо указывать кодовую фразу для encrypted-private.key
- Вариант Б - указать ssl_password_file file.keys;в http { }или server { }контексте. [ ссылка ]
- Вариант C - использовать -nodesдля создания private.key без шифрования

полезно: заблокировать private.key

{добавить HTTP-сервер в группу ssl-cert }
sudo chown root:ssl-cert private.key- сп Ange собственного ЭВ private.key к корневому пользователю, SSL-CERT группы
sudo chmod 640 private.key- изменить права доступа private.key на владельца R / W, группу R
теперь HTTP-сервер должен иметь возможность запускаться и читать UNencrypted private.key

Вариант А

повышенная безопасность, но при перезапуске сервера необходимо вручную вводить парольную фразу для encrypted-private.key

Вариант Б

средний уровень безопасности и, вероятно, хороший баланс между кондиционером

Вариант C

более слабая безопасность, но НЕ запрашивается незашифрованная кодовая фраза private.key

— Джейк Бергер
источник

отличное объяснение

— rizidoro

Nginx может читать зашифрованные закрытые ключи, начиная с версии 1.7.3, см .: nginx.org/en/docs/http/…

— 5lava

С какой целью вывести на обсуждение nginx и его версии? Кроме того, (B) и (C) предлагают эквивалентную безопасность (а именно, списки ACL файловой системы). Проблема, которую вы описываете, - это проблема автоматического хранения ключей , и ее проблема не имеет решения. См. Книгу « Инженерная безопасность» Гутмана .

— jww 01

@jww спрашивает "какова цель ...". Я рассмотрел контекст вопроса (QnA для программистов), который я попытался указать с помощью «однако я чувствую, что цель (для программистов) заключается в том, что:». конкретно в отношении безопасности ... может быть обсуждение для security.stackexchange.com

— Джейк Бергер