Come vengono verificati i certificati SSL?

Qual è la serie di passaggi necessari per verificare in modo sicuro un certificato SSL? La mia comprensione (molto limitata) è che quando visiti un sito https, il server invia un certificato al client (il browser) e il browser ottiene le informazioni sull'emittente del certificato da quel certificato, quindi le utilizza per contattare l'emittente e in qualche modo confronta certificati di validità.

• Come si fa esattamente?
• Che dire del processo che lo rende immune agli attacchi man-in-the-middle?
• Cosa impedisce a una persona a caso di impostare il proprio servizio di verifica da utilizzare negli attacchi man-in-the-middle, quindi tutto "sembra" sicuro?

Ecco una spiegazione molto semplificata:

1. Il browser Web scarica il certificato del server Web, che contiene la chiave pubblica del server Web. Questo certificato è firmato con la chiave privata di un'autorità di certificazione attendibile.

2. Il browser Web viene fornito con le chiavi pubbliche di tutte le principali autorità di certificazione. Utilizza questa chiave pubblica per verificare che il certificato del server Web sia stato effettivamente firmato dall'autorità di certificazione attendibile.

3. Il certificato contiene il nome di dominio e / o l'indirizzo IP del server web. Il tuo browser web conferma con l'autorità di certificazione che l'indirizzo elencato nel certificato è quello a cui ha una connessione aperta.

4. Il browser Web genera una chiave simmetrica condivisa che verrà utilizzata per crittografare il traffico HTTP su questa connessione; questo è molto più efficiente rispetto all'utilizzo della crittografia a chiave pubblica / privata per tutto. Il tuo browser crittografa la chiave simmetrica con la chiave pubblica del server web, quindi la invia indietro, assicurando così che solo il server web possa decrittarla, poiché solo il server web ha la sua chiave privata.

Tieni presente che l'autorità di certificazione (CA) è essenziale per prevenire attacchi man-in-the-middle. Tuttavia, anche un certificato non firmato impedirà a qualcuno di ascoltare passivamente il tuo traffico crittografato, poiché non ha modo di accedere alla tua chiave simmetrica condivisa.

Vale la pena notare che oltre ad acquistare un certificato (come detto sopra), puoi anche crearne uno tuo gratuitamente; questo è denominato "certificato autofirmato". La differenza tra un certificato autofirmato e uno acquistato è semplice: quello acquistato è stato firmato da un'autorità di certificazione che il tuo browser già conosce. In altre parole, il tuo browser può facilmente convalidare l'autenticità di un certificato acquistato.

Sfortunatamente questo ha portato a un malinteso comune che i certificati autofirmati siano intrinsecamente meno sicuri di quelli venduti da CA commerciali come GoDaddy e Verisign e che devi convivere con gli avvisi / eccezioni del browser se li usi; questo non è corretto .

Se distribuisci in modo sicuro un certificato autofirmato (o certificato CA, come suggerito da bobince) e lo installi nei browser che utilizzeranno il tuo sito , è altrettanto sicuro di quello acquistato e non è vulnerabile a man-in-the-middle attacchi e falsificazione di certificati. Ovviamente questo significa che è fattibile solo se solo poche persone hanno bisogno di un accesso sicuro al tuo sito (ad esempio, app interne, blog personali, ecc.).

L'hai detto tu

il browser ottiene le informazioni sull'emittente del certificato da quel certificato, quindi le utilizza per contattare l'emittente e in qualche modo confronta i certificati per la validità.

Il cliente non deve verificare con l'emittente perché due cose:

1. tutti i browser hanno un elenco preinstallato di tutte le principali chiavi pubbliche delle CA
2. il certificato è firmato e quella stessa firma è una prova sufficiente che il certificato è valido perché il client può assicurarsi, da solo e senza contattare il server dell'emittente, che quel certificato sia autentico. Questa è la bellezza della crittografia asimmetrica.

Notare che 2. non si può fare senza 1.

Questo è spiegato meglio in questo grande diagramma che ho fatto qualche tempo fa

(passa a "che cos'è una firma?" in fondo)

Il client dispone di un archivio preimpostato delle chiavi pubbliche delle autorità di certificazione SSL. Affinché il server sia affidabile, deve esserci una catena di fiducia dal certificato per il server fino alle autorità intermedie fino a uno dei cosiddetti certificati "root".

È possibile esaminare e / o modificare l'elenco delle autorità attendibili. Spesso lo fai per aggiungere un certificato per un'autorità locale di cui sai di fidarti, come l'azienda per cui lavori o la scuola che frequenti o cosa no.

L'elenco preimpostato può variare a seconda del client utilizzato. I grandi fornitori di certificati SSL assicurano che i loro certificati root siano presenti in tutti i principali browser ($$$).

Gli attacchi Monkey-in-the-middle sono "impossibili" a meno che l'attaccante non disponga della chiave privata di un certificato radice attendibile. Poiché i certificati corrispondenti sono ampiamente distribuiti, l'esposizione di una tale chiave privata avrebbe gravi implicazioni per la sicurezza dell'e-commerce in generale. Per questo motivo, quelle chiavi private sono custodite molto, molto attentamente.

se hai una mentalità più tecnica, questo sito è probabilmente quello che vuoi: http://www.zytrax.com/tech/survival/ssl.html

avvertimento: la tana del coniglio va in profondità :).

SO CHE QUELLO SOTTO È LUNGO, MA È DETTAGLIATO, MA ABBASTANZA SEMPLIFICATO. LEGGI ATTENTAMENTE E TI GARANTISCO CHE INIZIERAI A TROVARE QUESTO ARGOMENTO NON E 'COSI' COMPLICATO.

Prima di tutto, chiunque può creare 2 chiavi. Uno per crittografare i dati e un altro per decrittografare i dati. La prima può essere una chiave privata e la seconda una chiave pubblica, AND VICERZA.

In secondo luogo, in termini più semplici, un'autorità di certificazione (CA) offre il servizio di creare un certificato per te. Come? Usano determinati valori (il nome dell'emittente della CA, la chiave pubblica del tuo server, il nome dell'azienda, il dominio, ecc.) E usano la loro chiave privata SUPER DUPER ULTRA SECURE SECRET e crittografano questi dati. Il risultato di questi dati crittografati è una FIRMA.

Quindi ora la CA ti restituisce un certificato. Il certificato è fondamentalmente un file contenente i valori precedentemente menzionati (nome dell'emittente della CA, nome dell'azienda, dominio, chiave pubblica del server, ecc.), INCLUSA la firma (ovvero una versione crittografata di questi ultimi valori).

Ora, con tutto ciò che viene detto, ecco una parte VERAMENTE IMPORTANTE da ricordare: il tuo dispositivo / sistema operativo (Windows, Android, ecc.) Mantiene praticamente un elenco di tutte le principali CA / attendibili e le loro CHIAVI PUBBLICHE (se stai pensando che queste chiavi pubbliche siano usate per decrittare le firme all'interno dei certificati, SEI CORRETTO! ).

Ok, se leggi quanto sopra, questo esempio sequenziale sarà un gioco da ragazzi ora:

1. Example-Company chiede a Example-CA di creare per loro un certificato.
2. La CA di esempio utilizza la propria chiave super privata per firmare questo certificato e fornisce il certificato alla società di esempio.
3. Domani, l'utente di Internet-Bob utilizza Chrome / Firefox / ecc. per navigare su https://example-company.com . La maggior parte, se non tutti, i browser oggigiorno si aspetteranno un certificato dal server.
4. Il browser ottiene il certificato da example-company.com. Il certificato dice che è stato emesso da Example-CA. È solo che il sistema operativo di Bob ha già CA di esempio nell'elenco delle CA affidabili, quindi il browser ottiene la chiave pubblica di CA di esempio. Ricorda: tutto questo sta accadendo nel computer / cellulare / ecc. Di Bob, non via cavo.
5. Quindi ora il browser decrittografa la firma nel certificato. INFINE, il browser confronta i valori decrittografati con il contenuto del certificato stesso. SE IL CONTENUTO CORRISPONDE, SIGNIFICA CHE LA FIRMA È VALIDA!

Perché? Pensaci, solo questa chiave pubblica può decrittografare la firma in modo tale che i contenuti appaiano come prima che la chiave privata li crittografasse.

Che ne dici degli attacchi man in the middle?

Questo è uno dei motivi principali (se non il motivo principale) per cui è stato creato lo standard di cui sopra.

Diciamo che l'hacker Jane intercetta la richiesta dell'utente di Internet Bob e risponde con il proprio certificato. Tuttavia, l'hacker-Jane è ancora abbastanza attenta da dichiarare nel certificato che l'emittente era Example-CA. Infine, l'hacker-Jane ricorda che deve includere una firma sul certificato. Ma quale chiave usa Jane per firmare (ovvero creare un valore crittografato del contenuto principale del certificato) il certificato ?????

Quindi, anche se l'hacker-Jane ha firmato il certificato con la sua chiave, vedi cosa succederà dopo. Il browser dirà: "ok, questo certificato è emesso da Example-CA, decifriamo la firma con la chiave pubblica di Example-CA". Dopo la decrittografia, il browser rileva che i contenuti del certificato non corrispondono affatto. Quindi, il browser fornisce un avviso molto chiaro all'utente e dice che non si fida della connessione.