Qual è lo scopo dell'argomento -nodes in openssl?

103

Qual è lo scopo -nodesdell'argomento in openssl?

openssl

— user624409
fonte

Stack Overflow è un sito per domande di programmazione e sviluppo. Questa domanda sembra essere fuori tema perché non si tratta di programmazione o sviluppo. Vedi Quali argomenti posso chiedere qui nel Centro assistenza. Forse Super User o Unix e Linux Stack Exchange sarebbero un posto migliore per chiedere.

— jww

@jww Non sono d'accordo, openssl è un toolkit di basso livello e gli sviluppatori devono affrontarlo tutto il tempo. La linea è abbastanza sfocata, e sarebbe una grande perdita non consentire domande openssl qui semplicemente perché sembra essere una CLI piuttosto che la C lib.

— gtd

@gtd - questo è un reclamo frequente quando li contrassegno. Vedi anche Dove posso pubblicare domande su Dev Ops? . (Ma penso di aver commesso un errore su questo - la domanda è del 2011, e credo che fosse in tema allora. Non mi piace penalizzare per il cambio di politica).

— jww

@gtd - re: "openssl è un toolkit di basso livello e gli sviluppatori devono affrontarlo tutto il tempo." - ecco a cosa servono Super User o Unix e Linux Stack Exchange . "... sarebbe una grande perdita non consentire le domande openssl ..." - le domande sulla programmazione openssl C sono sempre benvenute qui. La perdita delle domande di non programmazione non sarà persa perché Stack Overflow è un sito di programmazione e sviluppo. Ci sono altri siti a cui andare quando non sai come usare un comando.

— jww

Grazie per il collegamento, posterò la mia risposta lì poiché penso che questo sia un problema molto importante.

— gtd

Risposte:

123

L'opzione -nodesnon è la parola inglese "nodes", ma piuttosto "no DES". Quando viene fornito come argomento, significa che OpenSSL non crittograferà la chiave privata in un file PKCS # 12 .

Per crittografare la chiave privata, puoi ometterla -nodese la tua chiave verrà crittografata con 3DES-CBC. Per crittografare la chiave, OpenSSL richiede una password e utilizza quella password per generare una chiave di crittografia utilizzando la funzione di derivazione della chiave EVP_BytesToKey .

A seconda della versione di OpenSSL e delle opzioni compilate, tu potrebbe essere in grado di fornire queste opzioni al posto di -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

In definitiva a livello di libreria OpenSSL chiama la funzione PEM_write_bio_PrivateKey con l'algoritmo di crittografia (o la sua mancanza) scelto.

— indiv
fonte

Per crittografia, intendi con una password?

— Flimm

@Flimm: protetto con una password, sì. La password genera una chiave di crittografia utilizzando un algoritmo di derivazione della chiave e la crittografia viene eseguita con la chiave, non con la password. L'unico modo per utilizzare la chiave crittografata è decrittografarla prima, per cui è necessario conoscere la password con cui è stata crittografata per generare la stessa chiave.

— indiv

perché dovrei crittografare il file della mia chiave privata? quelli non sono pubblicati a nessuno, da cui il nome. O mi sbaglio?

— phil294

@ Blauhirn: Cripteresti il tuo file della chiave privata per lo stesso motivo per cui cripteresti qualsiasi file: non vuoi che qualcuno che ottiene una copia sia in grado di leggerlo o usarlo. La necessità di crittografare la chiave privata dipende dall'importanza della chiave e dal modello di minaccia.

— indiv

modifica: nginx v1.7.3 ha aggiunto una direttiva ssl_password_file che legge le passphrase da un file specificato provando ciascuna passphrase sulla crittografia-private.key del contesto

indiv è vero che i -nodesmezzi argomento che OpenSSL creerà non cifrato private.key ; in caso contrario, ci sarà una richiesta di passphrase per creare encrypted-private.key . vedere req , pkcs12 , CA.pl

tuttavia, credo che lo scopo (per i programmatori) sia perché:

I server HTTP (ad esempio Apache , Nginx ) non possono leggere encrypted-private.key senza passphrase →
- Opzione A: ogni volta che il server HTTP viene avviato, deve fornire la passphrase per encrypted-private.key
- Opzione B: specificare ssl_password_file file.keys;in http { }o server { }contesto. [ rif ]
- Opzione C: utilizzare -nodesper creare private.key senza crittografia

utile: blocca private.key

{aggiungi il server HTTP al gruppo ssl-cert }
sudo chown root:ssl-cert private.key- ch ange proprio er di private.key a radice utente, ssl-cert gruppo
sudo chmod 640 private.key- cambia i permessi di accesso di private.key al proprietario R / W, gruppo R
ora, server HTTP dovrebbe essere in grado di avviare e leggere non criptati private.key

Opzione A

maggiore sicurezza, ma al riavvio del server, è necessario digitare manualmente la passphrase per encrypted-private.key

Opzione B

sicurezza media e probabilmente un buon equilibrio tra A / C

Opzione C

più debole della sicurezza, ma non viene richiesta non criptati private.key passphrase

— Jake Berger
fonte

ottima spiegazione

— rizidoro

Nginx può leggere chiavi private crittografate dalla versione 1.7.3, vedere: nginx.org/en/docs/http/…

— 5lava

Qual è lo scopo di portare nginx e le sue versioni nella discussione? Inoltre, (B) e (C) offrono una sicurezza equivalente (ovvero, ACL del file system). Il problema che stai descrivendo è il problema dell'archiviazione automatica delle chiavi , ed è un problema senza soluzione. Vedere il libro Engineering Security di Gutmann .

— jww

@ jww la domanda chiede "qual è lo scopo ...". Ho considerato il contesto della domanda (QnA per i programmatori), che ho cercato di indicare tramite "tuttavia, credo che lo scopo (per i programmatori) sia perché:". in particolare per quanto riguarda la sicurezza .. potrebbe essere una discussione per security.stackexchange.com

— Jake Berger