Come vengono verificati i certificati SSL?


231

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?


ho trovato questo video molto utile per comprendere il flusso youtube.com/watch?v=T4Df5_cojAs
Krishna

Risposte:


320

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.


4
Intorno al passaggio 1.5 il server "firma" anche qualcosa con la chiave privata associata al suo certificato. Questo si combina con il controllo del nome / IP per garantire che sia presentato solo dal sito proprietario del certificato.
Darron

69
Per vedere un esempio funzionante completo di questo processo utilizzando Firefox che si connette ad amazon.com , vedere moserware.com/2009/06/first-few-milliseconds-of-https.html
Jeff Moser,

11
Non sapevo che il mio browser viene fornito con le chiavi pubbliche di tutte le principali autorità di certificazione. Ora so come vengono verificati i miei certificati SSL senza il rischio di MITM :). Grazie!
OneChillDude

5
il server deve richiedere il certificato da CAuthority, quindi invia la richiesta ad esso. Come può CA essere sicura che il server sia valido?
voipp

4
@voipp: ottima domanda! Storicamente ci sono stati alcuni approcci, come "inviare un messaggio di posta elettronica da webmaster@<domain-being-verified>o" Posizionare questo file nel tuo dominio per dimostrare che lo possiedi ". proprio - notoriamente qualcuno è riuscito a ottenere una losca CA per rilasciare loro un certificato per gmail.com!
Eli Courtwright

59

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.).


1
In effetti, distribuire in modo sicuro il proprio certificato è un modo per scuoiare il gatto, ma molto più semplice è rivolgersi a una qualsiasi delle numerose CA cosiddette "aperte". CACert.org è il mio preferito. Finché ti fidi dei passaggi che intraprendono per salvaguardare l'emissione di certificati, l'importazione del certificato di origine è sicuro.
nsayer

6
Adoro questo commento - purtroppo mette in evidenza una debolezza molto importante con le CA. Supponiamo che importi un certificato CA da Bob Smith: beh Bob Smith può firmare un certificato per qualsiasi dominio (inclusi google.com e chase.com). Questo è in realtà il motivo per cui GoDaddy / Verisign pagano un sacco di soldi per essere inclusi nel sistema operativo: sono controllati da un'agenzia di sicurezza per assicurarsi di avere controlli in atto per assicurarsi che non firmino un certificato per una persona maligna. Penso che dovresti essere in grado di dire "questa CA può firmare certificati solo per mysite.com".
Natalie Adams

Il certificato autofirmato non è più sicuro, poiché le CA là fuori potrebbero essere pagate per firmare qualcosa che non dovrebbero avere. Se puoi distribuire in sicurezza i certificati CA agli endpoint, utilizza sempre certificati autofirmati.
javaPhobic

Esistono CA gratuite e verificate nella maggior parte dei browser principali? Sto cercando un certificato di base solo per verificare che possiedo un'e-mail e un nome di dominio. Tuttavia, quelli che ho trovato non sono nella maggior parte dei browser principali.
Alex Kwitny

@NathanAdams In teoria le grandi CA dovrebbero esaminare le richieste di evitare di emettere certificati fasulli come descrivi ... ma leggi questa storia: stripe.ian.sh
nsayer

47

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)

blob


10
Questa avrebbe dovuto essere la risposta accettata. La risposta di @Eli Courtwright è un modo in breve di capire come funzionano i certificati.
Felix Crazzolara

Leggerlo una volta potrebbe non essere sufficiente, ma se hai già familiarità con bit e pezzi di SSL, questo riunisce davvero tutto. Bel lavoro!
Cameron Gagnon

2
Immagine fantastica. Finalmente qualcosa che spiega le mie domande. Ovunque vada per andare in profondità ho appena detto "il browser verifica che il certificato sia corretto". MA COME LO FA ?. Questo dà una risposta.
ori6151

1
Risposta gloriosa grazie mille !!!! non mi interessa nemmeno se tralascia alcuni dettagli, per quanto ne so cattura completamente tutti i passaggi importanti.
Muhammad Umer,

9

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.



6

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.


buona sintesi. Ho ancora una domanda. "Infine, l'hacker-Jane ricorda che deve includere una firma nel certificato." => Anche la firma non è disponibile pubblicamente nel certificato inviato dal server?
SRIDHARAN

1
@SRIDHARAN Mi piace che il tuo hacker pensi: -) Potresti copiare / incollare la firma dal certificato originale. Tuttavia, Jane deve decrittografare il traffico web. L'unico modo è che Jane inserisce la sua chiave pubblica nel certificato. Quindi il browser utilizza quella chiave per crittografare le richieste. Jane utilizza la sua chiave privata per decrittografare il traffico. Cosa succede se Jane copia / incolla la firma: 1. Il browser di Bob utilizza la chiave pubblica di Example-CA per decrittografare la firma 2. Il browser confronta il contenuto della firma decrittografata con il contenuto del certificato. 3. Il browser nota che le chiavi pubbliche non corrispondono 4. Il browser dice a Bob che la connessione non è sicura.
Francisco Vilches

Grazie per aver risposto. Stavo affrontando questi argomenti. Adesso ho una buona comprensione. Mi sono anche confuso con lo spoofing DNS. Per cui ho trovato la risposta perfetta qui. security.stackexchange.com/a/94335 .
SRIDHARAN
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.