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

Un certificato CA è un certificato che è di proprietà di una CA e contrassegnato come idoneo per l'utilizzo come CA; vale a dire che contiene un'estensione Basic Constraints 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 auto-emesso; questo è il caso normale per una CA principale . Una CA radice è una CA che esiste di per sé e deve essere considerata a priori (inclusa manualmente in un browser Web o in un archivio di certificati OS) e non in virtù dell'emissione da parte di un'altra CA di fiducia .

Creare una CA autofirmata e utilizzarla per firmare il certificato del server effettivo (opzione 1B) è utile se si prevede di emettere diversi certificati (possibilmente molti) per molti server. Con la tua CA radice (che è l'opzione 1B significa), devi solo inserire manualmente un certificato in tutti i client (la tua CA principale autofirmata). Se hai solo un certificato server singolo da produrre e prevedi che le cose rimarranno tali, allora l'opzione 1A vale 1B, probabilmente meglio perché è più semplice.

L'opzione -des3 è per la crittografia simmetrica della chiave CA. Non è male. Non c'è abbastanza potenza di calcolo (o, per quella materia, potenza pura) sulla Terra per rompere correttamente la crittografia 3DES. Passare a AES-256 sarebbe inutile, e potrebbe rivelarsi difficile perché lo strumento da riga di comando di 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 al fine di ottenere un livello di sicurezza accettabile. Ecco perché una buona chiave RSA dovrà andare a 2048 bit circa, 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 dimensione 4096 bit e la memorizza nel file server.key . Quell'archiviazione è inoltre protetta (crittografata) con 3DES, utilizzando una chiave simmetrica derivata dalla password che digiti 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 una richiesta di certificato (il file ".csr" file) e quindi nel certificato stesso.

CA vs. certificato autografato

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

Le grandi diferenze sono:

• Certificato di entità finale autofirmato: se crei più di un certificato, OGNI certificato che crei deve essere esplicitamente attendibile in ogni punto finale. Se un certificato è compromesso, il trust deve essere rimosso da ogni punto finale. Può essere fatto con script automatici, ma è molto lavoro.

• CA autofirmato - > entità finale firmata: è necessario affidarsi esplicitamente alla CA, quindi tutte le entità finali verranno automaticamente considerate attendibili. Se si prevede di creare più certificati server in qualsiasi arco di tempo, questo ridurrà il carico di lavoro. Il trucco è che hai bisogno di un modo per verificare la revoca se c'è qualche possibilità di compromettere il certificato del server (che c'è sempre). È qui che entra in gioco la complessità: CRL o OCSP sono i modi standard per comunicare su un compromesso, ma ciò significa fare più lavoro, non meno, per mettere in scena e distribuire CRL e (opzionalmente) stage 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 tuo sistema e ciò che pensi che sarà il ciclo di vita della tua emissione e revoca di certificati.

DES3 vs. AES-256

Dalla documentazione di openSS , le tue opzioni con il comando che hai citato sono:

• DES
• DES3
• IDEA

Raccomando IDEA come il nuovo algoritmo e le migliori pratiche, ma non se nessuno dei tuoi sistemi non è compatibile. Questo può essere un vero problema: provare a diagnosticare perché non è possibile utilizzare un determinato certificato e la chiave privata può essere estremamente frustrante e le risposte fornite dalla maggior parte dei sistemi non sono chiare e difficili da comprendere.

Secondo questa documentazione:

These options encrypt the private key with the DES, triple DES, or the IDEA ciphers respectively before outputting it. If none of these options is specified no encryption is used. If encryption is used a pass phrase is prompted for if it is not supplied via the -passout argument.

Ecco come la chiave privata è archiviata e protetta all'interno del 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), c'è un modo per specificare come la chiave può essere usata per la crittografia - che può includere impostazioni SSL valide, come consentire o imporre una chiave di sessione a 256 bit.

Questo non è un fattore chiave del certificato (nel tuo esempio, questa è una chiave assimmetrica RSA 4096 bit) - è un fattore di ciò che la coppia di chiavi rappresentata è autorizzata a fare secondo la CA e la sua politica di sicurezza associata . Questo in genere controlla come viene impostata una sessione SSL.

Per essere chiari nessuna chiave di sessione SSL viene creata 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 che il certificato è stato creato, firmato e installato.

1. Se una società desidera generare la propria CA, può includerla nei propri computer personali, ad esempio per fidarsi dei siti Web interni o dei proxy (in caso di ispezione delle connessioni SSL).
2. 3 DES non è rotto, ma AES: fornisce una maggiore sicurezza rispetto a DES ed è computazionalmente più efficiente di 3DES. AES offre tre diversi punti di forza: 128, 192 e 256 bit chiavi. 3DES è essenzialmente DES crittografato 3 volte.
3. RSA è un algoritmo costoso e non è veramente adatto per crittografare ogni connessione con. quindi, 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 gruppo di caratteri casuali, 256 bit di lunghezza) e la crittografa con la chiave RSA e la invia all'altra estremità. Da qui entrambi utilizzano un algoritmo di crittografia simmetrica come AES (che è molto più veloce di RSA per crittografare e decodificare i dati) per trasmettere i dati in modo sicuro.

Nell'ordine:

The document shows two ways: (1A) Generating your own self-signed cert. and (1B) Generating your own cert/CA and then using the CA to sign your cert.

I don't understand what the difference between the two is. What is the point of generating your own CA if none of the browsers trusts it (unlike certs signed by Verisign)?

Anche se il certificato non è firmato da una CA che è 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 otterrete è quel piccolo lucchetto verde nei browser dei visitatori che indica loro che la proprietà del 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 verrà 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 si desidera essere in grado di riprodurre l'autorità di certificazione (ovvero creare più di un certificato e averli tutti parte della stessa catena di fiducia), è necessario creare un certificato autofirmato e utilizzarlo per firmare gli altri certificati (vedere openssl req e openssl x509 ).

Is (1B) used to prevent MITM attacks?

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

If so, should I use (1B) over (1A)?

Per un singolo sito web puoi fare a meno di 1A, anche se fare 1B è un buon esercizio.

I noticed that the doc uses des3 cipher. Would it be possible to use aes-256 cipher instead unless there is a good reason to use des3? (Also how do I do this?)

Manca una parte della documentazione di openssl nelle distribuzioni Linux ma puoi sostituire -aes256 al posto di -des3 per utilizzare invece AES a 256 bit. Allo stesso modo sono disponibili anche le varianti 192 e 128 bit. Verifica l'output di openssl genrsa --help per l'elenco degli algoritmi supportati. Per quanto riguarda la corretta selezione dell'algoritmo: finché non si sa che l'algoritmo non funziona, c'è poca differenza. Sia AES256 che tripple-DES (des3) sono molto forti. Generalmente preferisco AES in quanto è più efficiente.

openssl genrsa -des3 -out server.key 4096 Does this line mean that it's generating a symmetric key (des3), and then generating a public key (RSA 4096 bit)?

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

Dal momento che sembra che tu stia cercando informazioni generali qui ho intenzione di mantenere la mia risposta breve ma non esitare a leggere attraverso l'openssl documention

1. Un'autorità di certificazione (CA) viene utilizzata per firmare altri certificati per creare una rete di fiducia. Ad esempio: se si dovesse ottenere un certificato di terze parti, si riceverà un certificato firmato da qualcun altro (thwat, verisign, koomodo, ecc.). Si tratta di "CA attendibili" a cui è possibile verificare lo store di chiavi del browser di un utente. Il browser guarda il tuo certificato per YYY.com e se è firmato da un agente fidato e non viene revocato, lo accetta come buono (blocco verde). Se non c'è una CA affidabile nella catena di firma, non c'è modo di sapere se il certificato può essere considerato attendibile.

2. Dovresti essere in grado di. prova openssl genrsa -aes256 -out server.key 4096

3. Dovrai scavare un po 'più a fondo per capire veramente questo argomento, ma ad un livello molto alto la chiave privata viene utilizzata per generare la coppia di chiavi asimmetriche. Nell'articolo si fa riferimento alla sezione 'GENERATION DSA KEY' mostra la creazione della chiave privata e 'CREATE CERTIFICATO AUTENTICATO DA UNA RICHIESTA DI CERTIFICAZIONE FIRMATA' mostra l'utilizzo di tale chiave per firmare un csr in modo che il certificato risultante sarà considerato affidabile per la CA.

Questa è una vera e rapida revisione dei concetti SSL (mi aspetto di essere fiammeggiato :) quindi consiglio vivamente di scavare più a fondo se si vuole veramente avere a che fare con SSL. C'è una bella panoramica di SSL su gavaghan.org che dovrebbe aiutare a darti una comprensione più completa della tecnologia. Anche un rapido google di 'SSL tutorial' o simili dovrebbe dare buoni risultati.