it-swarm-eu.dev

SSL / TLS - Distinzione tra certificato autofirmato e CA autofirmata e altre domande?

Ho un piccolo sito web personale che desidero servire in modo sicuro tramite HTTPS. Al momento non desidero utilizzare una CA di terze parti per firmare i miei certificati. Stavo leggendo questo documento su generando un certificato autofirmato .

Ho tre domande.

  • Il documento mostra due modi: (1A) Generazione del proprio certificato autofirmato. e (1B) generare il proprio certificato/CA e quindi utilizzare la CA per firmare il proprio certificato.

    Non capisco quale sia la differenza tra i due. Qual è lo scopo di generare la propria CA se nessuno dei browser si fida di essa (a differenza dei certificati firmati da Verisign)? (1B) è usato per prevenire gli attacchi MITM? In tal caso, dovrei usare (1B) su (1A)?

    Oltre a gestire/revocare più certificati (se li utilizzo), una CA autofirmata sembra inutile?

  • Ho notato che il documento usa la cifra des3. Sarebbe possibile usare la crittografia aes-256 invece a meno che non ci sia una buona ragione per usare des3? (Anche come posso fare questo?)

  • Questo thread ha fatto una distinzione tra l'uso di chiavi a 2048 bit e chiavi a 256 bit. Capisco cosa dice la risposta in una certa misura (che le chiavi pubbliche (2048 bit) vengono utilizzate per crittografare le chiavi simmetriche (256 bit) al fine di scambiare le chiavi tra server e client). Ma non capisco come questo sia applicato nel contesto del documento. Nel documento, vedo questa riga:

    openssl genrsa -des3 -out server.key 4096

    Questa riga significa che sta generando una chiave simmetrica (des3) e quindi generando una chiave pubblica (RSA 4096 bit)?

18
user1812844

A certificato CA è un certificato di proprietà di una CA e contrassegnato come idoneo all'uso come CA; vale a dire che contiene un Basic Constraints estensione con il flag "cA" impostato su TRUE.

Un certificato autofirmato è un certificato che è firmato con la chiave privata corrispondente alla chiave pubblica che si trova nel certificato stesso. Ciò significa che il certificato è stato emesso dal proprietario del certificato stesso, non da qualcun altro.

Un certificato CA può essere rilasciato autonomamente; questo è il caso normale di un CA principale. Una CA principale è una CA che esiste da sola e deve essere considerata attendibile a priori (inclusa manualmente in un browser Web o in un archivio certificati del sistema operativo) e non in virtù dell'emissione da parte di un'altra CA fidata.

La creazione di una CA autofirmata e l'utilizzo per firmare il certificato del server effettivo (opzione 1B) è utile se si prevede di emettere diversi certificati (probabilmente molti) per molti server. Con la tua CA radice (che significa l'opzione 1B), dovresti solo inserire un certificato manualmente in tutti i client (la tua radice autofirmata CIRCA). Se hai un solo certificato server da produrre e prevedi che le cose rimarranno così, allora l'opzione 1A è buona come 1B, probabilmente migliore poiché è più semplice.


L'opzione - des è per la crittografia simmetrica della chiave CA. Non è male. Non c'è abbastanza potenza di calcolo (o, per questo, potenza pura) sulla Terra per interrompere la crittografia 3DES correttamente eseguita. Andare su AES-256 sarebbe inutile e potrebbe rivelarsi difficile perché lo strumento da riga di comando OpenSSL non lo supporta immediatamente (OpenSSL, la libreria, include un'implementazione AES-256, ma la riga di comando gli strumenti non hanno un facile accesso ad esso quando si tratta di crittografia simmetrica della chiave privata).


Le firme digitali (quelle applicate ai certificati) utilizzano, per definizione, chiavi asimmetriche. Le chiavi asimmetriche richiedono molta struttura matematica interna e tale struttura può essere utilizzata per indebolirle, quindi devono essere molto più grandi delle chiavi simmetriche per raggiungere un livello decente di sicurezza. Ecco perché una buona chiave RSA dovrà arrivare a circa 2048 bit, mentre una chiave simmetrica a 128 bit è già solida. La linea:

openssl genrsa -des3 -out server.key 4096

genera una nuova coppia di chiavi RSA asimmetrica di dimensioni 4096 bit e la memorizza nel file server.key. Tale memoria è inoltre protetta (crittografata) con 3DES, utilizzando una chiave simmetrica derivata dalla password digitata in quel punto.

La chiave privata include una copia della chiave pubblica. La chiave pubblica (ma, ovviamente, non la chiave privata) farà anche parte del certificato : viene prima copiata in un richiesta di certificato (il file ".csr") e quindi nel certificato stesso.

12
Tom Leek

CA vs. certificato autofirmato

In qualsiasi installazione PKI, il certificato autofirmato (CA o entità finale - ad esempio un server) deve essere distribuito a tutte le parti affidanti. Per l'utente medio, i sistemi CA pubblici noti e altamente affidabili vengono distribuiti automaticamente. Per le infrastrutture più piccole, come gli ambienti aziendali interni, un certificato CA interno può essere impacchettato automaticamente in browser, server e altre distribuzioni. In tutti i casi, se il certificato è autofirmato, deve essere esplicitamente considerato attendibile.

Le grandi differenze sono:

  • certificato di entità finale autofirmato: se si crea più di un certificato, OGNI certificato creato deve essere esplicitamente considerato attendibile in ogni punto finale. Se un certificato è compromesso, la fiducia deve essere rimossa da ogni punto finale. Può essere fatto con script automatici, ma richiede molto lavoro.

  • cA autofirmata -> entità finale firmata - è necessario affidarsi esplicitamente alla CA, quindi ogni entità finale verrà automaticamente considerata attendibile. Se si prevede di creare più server certs in un arco di tempo, ciò ridurrà il carico di lavoro. Il trucco è che è necessario un modo per verificare la revoca in caso di possibilità di compromissione del certificato del server (che esiste sempre). È qui che entra in gioco la complessità: i CRL o OCSP sono i modi standard per comunicare un compromesso, ma ciò significa fare più lavoro, non meno, per mettere in scena e distribuire CRL e (facoltativamente) mettere in scena ed eseguire un server OCSP. Inoltre, i browser devono essere configurati per verificare ciò, che non è un'impostazione predefinita.

Ha molto a che fare con i rischi nel vostro sistema e ciò che pensate sarà il ciclo di vita della vostra emissione e revoca dei certificati.

DES3 contro AES-256

Da documentazione openSSL , le opzioni con il comando che hai citato sono:

  • DES
  • DES3
  • IDEA

Consiglierei IDEA come algoritmo più recente e best practice, ma non se nessuno dei tuoi sistemi non è compatibile. Questo può essere un vero dolore - provare a diagnosticare perché non puoi usare un dato certificato e chiave privata può essere estremamente frustrante e le risposte fornite dalla maggior parte dei sistemi sono poco chiare e difficili da capire.

Secondo questa documentazione:

Queste opzioni crittografano la chiave privata con DES, triple DES o IDEA rispettivamente prima di emetterla. Se nessuna di queste opzioni è specificata, non viene utilizzata la crittografia. Se la crittografia viene utilizzata una passphrase viene richiesto se non viene fornito tramite l'argomento -passout.

Ecco come viene memorizzata e protetta la chiave privata nel file server.key. Non ha nulla a che fare con il modo in cui il certificato consente al server di comunicare con altri sistemi.

In un normale sistema CA (OpenSSL può essere un po 'primitivo), esiste un modo per specificare come utilizzare la chiave per la crittografia, che può includere impostazioni SSL valide, come consentire o applicare una chiave di sessione a 256 bit.

Questo non è un fattore della chiave del certificato (nel tuo esempio, è una chiave asimmetrica RSA a 4096 bit) - è un fattore di ciò che la coppia di chiavi rappresentata può eseguire in base alla CA e ai relativi criteri di sicurezza. Questo in genere controlla come è impostata una sessione SSL.

Per essere chiari non vengono create chiavi di sessione SSL nella creazione di un certificato . Le chiavi di sessione vengono create e negoziate nel momento in cui un client comunica con un server, molto tempo dopo la creazione, la firma e l'installazione del certificato.

11
bethlakshmi
  1. Se un'azienda desidera generare la propria CA, può includerla nei computer del proprio personale, ad esempio per fidarsi di siti Web o proxy interni (in caso di ispezione delle connessioni SSL).
  2. 3 DES non è rotto, ma AES-Offre una sicurezza maggiore di DES ed è computazionalmente più efficiente di 3DES. AES offre tre diversi punti di forza chiave: 128-, Chiavi a 192 e 256 bit. 3DES è essenzialmente DES crittografato 3 volte.
  3. RSA è un algoritmo costoso e non è davvero adatto per crittografare ogni connessione. quindi quello che succede è che invece di trasmettere tutto crittografato con RSA, il server crea una chiave casuale composta da 256 bit (puoi vedere questa chiave come una password, solo un mucchio di caratteri casuali, 256 bit di lunghezza) e la crittografa con la chiave RSA e la invia all'altra estremità. Da qui entrambi usano un algoritmo di crittografia simmetrica come AES (che è molto più veloce di RSA per crittografare e decrittografare i dati) per trasmettere i dati in modo sicuro.
5
Lucas Kauffman

In ordine:

Il documento mostra due modi: (1A) Generazione del proprio certificato autofirmato. e (1B) generare il proprio certificato/CA e quindi utilizzare la CA per firmare il proprio certificato.

Non capisco quale sia la differenza tra i due. Qual è lo scopo di generare la propria CA se nessuno dei browser si fida di essa (a differenza dei certificati firmati da Verisign)?

Anche se il certificato non è firmato da una CA ritenuta attendibile da un browser, può essere utilizzato per crittografare il traffico tra client e server. Ciò significa che otterrai la segretezza che desideri grazie alla crittografia. Quello che non otterrai è quel piccolo lucchetto verde nei browser dei tuoi visitatori che dice loro che la proprietà del tuo dominio è stata controllata da un'autorità di certificazione. Quindi non saranno in grado di verificare l'autenticità del tuo sito (possibile MITM) ma la comunicazione sarà crittografata.

Un certificato autofirmato è la radice della fiducia in tutte le gerarchie di certificati. Verisign ha un certificato autofirmato che è la radice della fiducia per tutti i certificati che firmano (ed è probabilmente in un bunker da qualche parte). Se vuoi essere in grado di giocare con l'autorità di certificazione (ovvero creare più di un certificato e averli tutti parte della stessa catena di fiducia), devi creare un certificato autofirmato e usarlo per firmare gli altri certificati (vedi openssl req e openssl x509).

(1B) è usato per prevenire gli attacchi MITM?

No. Il tuo (1B) ha lo scopo di consentire la creazione di più certificati che sono tutti legati alla stessa CA proprio come l'autore afferma nel primo paragrafo. Fondamentalmente questo è un esercizio che mostra in modo efficace cos'è una gerarchia di certificati.

In tal caso, dovrei usare (1B) su (1A)?

Per un singolo sito Web puoi cavartela con 1A, anche se fare 1B è un buon esercizio.

Ho notato che il documento usa la cifra des3. Sarebbe possibile usare la crittografia aes-256 invece a meno che non ci sia una buona ragione per usare des3? (Anche come posso fare questo?)

Parte della documentazione di openssl nelle distro Linux manca ma è possibile sostituire -aes256 al posto di -des3 per utilizzare invece l'AES a 256 bit. Allo stesso modo sono disponibili anche le varianti a 192 e 128 bit. Controlla l'output di openssl genrsa --help per l'elenco degli algoritmi supportati. Per quanto riguarda la corretta selezione dell'algoritmo: fino a quando l'algoritmo non è noto per essere rotto c'è poca differenza. Sia AES256 che tripple-DES (des3) sono molto potenti. In genere preferisco AES perché è più efficiente.

openssl genrsa -des3 -out server.key 4096 Questa riga indica che sta generando una chiave simmetrica (des3) e quindi una chiave pubblica (RSA 4096 bit)?

No. Questo comando fa sì che openssl crei una chiave privata RSA a 4096 bit crittografata con tripple-DES. Ti verrà richiesta una passphrase e prima di poter utilizzare questa chiave per qualsiasi scopo, dovrai decodificarla utilizzando la stessa passphrase. Questo ha lo scopo di impedire l'uso della chiave in caso di smarrimento/furto.

5
flihp

Dal momento che sembra che tu stia cercando informazioni generali qui, terrò la mia risposta breve ma sentiti libero di leggere la documentazione di openssl

  1. Un'autorità di certificazione (CA) viene utilizzata per firmare altri certificati per creare una rete di fiducia. Ad esempio: se dovessi ottenere un certificato di terze parti, riceveresti un certificato firmato da qualcun altro (thwat, verisign, koomodo, ecc.). Si tratta di "autorità di certificazione" che l'archivio chiavi di un browser dell'utente sarà in grado di verificare. Il browser esamina il tuo certificato per YYY.com e se è firmato da un agente di fiducia e non viene revocato, lo accetta come un buono (blocco verde). Se non esiste un'autorità di certificazione attendibile nella catena di firma, non è possibile sapere se il certificato può essere considerato attendibile.

  2. Dovresti essere capace di. provare openssl genrsa -aes256 -out server.key 4096

  3. Dovrai scavare un po 'più a fondo per capire davvero questo argomento, ma a un livello molto alto la chiave privata viene utilizzata per generare la tua coppia di chiavi asimmetrica. Nell'articolo a cui fai riferimento, la sezione "GENERAZIONE DELLA CHIAVE DSA" mostra come creare la tua chiave privata e "CREA CERTIFICATO SELF-SIGNED DA UNA RICHIESTA DI FIRMA DI CERTIFICATO" mostra l'utilizzo di quella chiave per firmare un csr in modo che il certificato risultante venga considerato attendibile dalla tua CA.

Questa è una recensione REALE veloce e sporca dei concetti SSL (mi aspetto di essere fiammata :) quindi ti consiglio vivamente di scavare più a fondo se vuoi davvero approfondire SSL. C'è una piccola panoramica di SSL su gavaghan.org che dovrebbe aiutarti a capire meglio la tecnologia. Un rapido google di 'tutorial SSL' o simili dovrebbe anche dare buoni risultati.

3
grauwulf