In che modo Chrome e Firefox convalidano i certificati SSL?

I browser e / oi sistemi operativi tendono ad avere un elenco predefinito di certificati CA utilizzati come ancore di sicurezza per verificare i certificati dei server a cui si connettono. Sono tutti personalizzabili (eccetto per i certificati EV, per i quali i certificati di root sono hard-coded nel browser, sebbene sia possibile disabilitarli ... bug escluso).

Firefox utilizza la sua lista personale su tutte le piattaforme.

Internet Explorer e Chrome utilizzano il repository di certificati del sistema operativo su Windows. L'impostazione predefinita è disponibile tramite il programma di certificazione root di Microsoft

Apple ha anche il suo programma .

Affidandosi a un certificato del server sconosciuto a priori viene fatto costruendo un percorso di certificazione tra questo certificato e uno degli ancore di fiducia del browser. Questo viene fatto come definito in RFC 3280 / RFC 5280.

Inoltre, è possibile controllare anche la revoca dei certificati, tramite CRL o tramite OCSP.

So it's not possible to intercept communication between the browser and a CA to fake a valid certificate as the certificate is likely already in the browser's cache ?

Per riattivare il punto che ho fatto come commento alle risposte di Wug: il repository di trust ancore non è una cache . Una cache è un segnaposto dinamico che mira a mantenere di recente ciò a cui hai avuto accesso, in base al presupposto che ne avrai presto bisogno. Al contrario, il tuo elenco di certificati attendibili non deve mai essere aggiornato automaticamente sulla base di ciò che stai attualmente navigando. (Potrebbe essere aggiornato dagli aggiornamenti automatici della sicurezza, ma si tratta di un problema diverso.)

Il certificato del server verrà ottenuto ogni volta che viene stabilita una nuova sessione SSL / TLS e il browser deve verificarlo ogni volta. Non è memorizzato nella cache. (Si potrebbe avere del caching OCSP, ma questo è per migliorare le prestazioni e conservarlo solo per un breve periodo di tempo. Questo è solo per verificare lo stato di revoca, al momento dell'accesso.)

Contattare la CA è solo per la revoca dei certificati. In caso contrario, non contattare una CA. I certificati CA (i tuoi ancore fidati) sono un dato, un "salto di fiducia", in bundle per te dal tuo sistema operativo / browser (che puoi scegliere esplicitamente, ma è fissato per quanto riguarda una determinata connessione). Nella migliore delle ipotesi, è possibile impedire che il controllo della revoca dei certificati si verifichi (il che potrebbe causare il fallimento della convalida del browser, a seconda delle impostazioni).

Il server Web invierà l'intera catena di certificati al client su richiesta. Il browser (o altro validatore) può quindi controllare il certificato più alto della catena con certificati CA memorizzati localmente.

La maggior parte dei sistemi operativi conserva una cache di certificati autorevoli a cui i browser possono accedere per tali scopi, altrimenti il browser ne avrà il proprio set da qualche parte.

Un certificato può essere firmato da un altro certificato, formando una "catena di fiducia" che di solito termina con un certificato autoritativo autofirmato fornito da un'entità come GeoTrust, Verisign, Godaddy, ecc.

Questa sarebbe una domanda migliore per il sito di sicurezza SE

Google Chrome, in particolare, non sono sicuro al 100% che usi la cache del sistema operativo, ma puoi aggiungere un certificato autorevole tramite Wrench - > Impostazioni - > Mostra impostazioni avanzate - > HTTPS / SSL - > Gestisci certificati - > Autorità di certificazione radice affidabili e aggiunta di un certificato CA autorevole lì.

Come spiegato da Wug, la convalida avviene dal certificato del server al certificato più alto della catena. Il browser esaminerà le proprietà del certificato ed eseguirà una convalida di base, ad esempio assicurandosi che l'URL corrisponda al campo Issued to , il campo Issued By contenga un'autorità di certificazione attendibile, la data di scadenza sia buona nel campo Valid From , ecc.

Inoltre, ogni certificato contiene URL che puntano a Liste di revoca certificati ( CRL Distribution Points ), il client tenterà di scaricare l'elenco da tale URL e assicurarsi che il certificato in questione non sia stato revocato.

Per rispondere alla tua domanda

Are they requesting data from SSL Certification web site like GeoTrust to validate the certificate received from the web server ?

Sì , il browser eseguirà la convalida di base e quindi contatta il server di autorità CA (tramite i punti CRL) per assicurarsi che il certificato sia ancora valido.

Ecco la mia versione del certificato di vaildation. Supponendo che Web Certicate abbia il nome corretto, il browser tenta di trovare l'Autorità di certificazione che ha firmato il certificato del server Web per recuperare la chiave pubblica del firmatario. L'Autorità di certificazione della firma può far parte di una catena di CA

Con la chiave pubblica la firma sul certificato del sito Web può essere decifrata (questo garantisce che solo la CA potrebbe averlo firmato a meno che la chiave privata non sia stata compromessa) per rivelare un hash del certificato del server web. Il browser calcola anche l'hash del certificato del server Web e se i due hash corrispondono a quelli che dimostrano che l'autorità di certificazione ha firmato il certificato.

Se la chiave pubblica del firmatario non può essere trovata o gli hash non corrispondono, il certificato non è valido.

Il problema con questo sistema è che le autorità di certificazione non sono completamente affidabili.

Tieni presente che Google Chrome ha smesso di utilizzare gli elenchi CRL intorno al 7 febbraio 2012 per verificare se un certificato era valido. Sembra che costruiscano tutti i certificati validi nel browser e installino un nuovo set ogni volta che il browser viene aggiornato. Vedi URL: link .