Come vengono verificati i certificati SSL?

Qual è la serie di passaggi necessari per verificare in modo sicuro un certificato SSL? La mia (molto limitata) comprensione è 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 lo usa per contattare l’emittente e in qualche modo confronta certificati per validità.

  • Come è fatto esattamente?
  • E il processo lo rende immune agli attacchi man-in-the-middle?
  • Cosa impedisce a una persona casuale di impostare il proprio servizio di verifica da utilizzare in attacchi man-in-the-middle, quindi tutto “sembra” sicuro?

Ecco una spiegazione molto semplificata:

  1. Il tuo 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 tuo browser web viene installato 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 tuo browser web genera una chiave simmetrica condivisa che verrà utilizzata per crittografare il traffico HTTP su questa connessione; questo è molto più efficiente dell’uso della crittografia a chiave pubblica / privata per tutto. Il browser crittografa la chiave simmetrica con la chiave pubblica del server Web, quindi la rispedisce, assicurando che solo il server Web possa decodificarlo, poiché solo il server Web ha la sua chiave privata.

Si noti che l’autorità di certificazione (CA) è essenziale per prevenire attacchi man-in-the-middle. Tuttavia, anche un certificato non firmato impedisce 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 all’acquisto di un certificato (come menzionato sopra), puoi anche crearne uno gratis; questo è indicato come “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 ciò ha portato a un malinteso comune sul fatto che i certificati autofirmati siano intrinsecamente meno sicuri di quelli venduti da CA commerciali come GoDaddy e Verisign e che tu debba convivere con 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 falsi falsi. Ovviamente questo significa che è ansible solo se solo poche persone hanno bisogno di un accesso sicuro al tuo sito (ad esempio, app interne, blog personali, ecc.).

Nell’interesse di aumentare la consapevolezza e incoraggiare i colleghi blogger di piccole dimensioni come me a proteggersi, ho scritto un tutorial entry-level che spiega in modo più dettagliato i concetti dietro i certificati e su come creare e utilizzare in sicurezza un certificato autofirmato (completo di esempi di codice e schermate). Ecco un link nel caso in cui sia utile a chiunque altro in futuro: http://www.clintharris.net/2009/self-signed-certificates/ .

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 controllare 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 tale firma è sufficiente a dimostrare che il certificato è valido perché il cliente può assicurarsi, da solo e senza contattare il server dell’emittente, che tale certificato sia autentico. Questa è la bellezza della crittografia asimmetrica.

Si noti che 2. non può essere fatto senza 1.

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

(salta su “che cos’è una firma?” in basso)

macchia

Il client ha un archivio pre-inizializzato delle chiavi pubbliche delle autorità di certificazione SSL. Ci deve essere una catena di attendibilità dal certificato per il server attraverso le autorità intermedie fino a uno dei cosiddetti certificati “root” affinché il server sia considerato affidabile.

È ansible esaminare e / o modificare l’elenco delle autorità attendibili. Spesso lo fai per aggiungere un certificato per un’autorità locale di cui sai di avere fiducia, come la compagnia per cui lavori o la scuola frequentata o no.

L’elenco pre-seed può variare a seconda del client che si utilizza. I grandi fornitori di certificati SSL assicurano che i loro certificati di root sono in tutti i principali browser ($$$).

Gli attacchi Monkey-in-the-middle sono “impossibili” a meno che l’utente malintenzionato non abbia la chiave privata di un certificato radice attendibile. Poiché i certificati corrispondenti sono ampiamente utilizzati, l’esposizione di tale chiave privata avrebbe gravi implicazioni per la sicurezza dell’eCommerce in generale. Per questo motivo, quelle chiavi private sono molto, molto strettamente sorvegliate.

se sei più tecnico, questo sito è probabilmente quello che vuoi: http://www.zytrax.com/tech/survival/ssl.html

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