Introduzione
HTTPS (tramite SSL /TLS) utilizza crittografia a chiave pubblica per proteggere le comunicazioni del browser dalla lettura o modifica in transito su Internet. I server forniscono ai browser in visita una chiave pubblica utilizzata per stabilire una connessione crittografata per tutti gli scambi di dati successivi.
Tuttavia, sto solo ricevendo un lavoro la chiave pubblica da sola non garantisce che (e per estensione il server) sia effettivamente di proprietà del telecomando corretto soggetto (ad es. persona, società o organizzazione). Man-in-the-middle gli aggressori possono manipolare le reti per servire le proprie chiavi, compromettendo in tal modo qualsiasi comunicazione.
I browser lo impediscono entro autenticazione Server HTTPS che utilizzano certificato, che sono documenti digitali che legare una chiave pubblica per un singolo soggetto. L'associazione è affermata avendo un attendibile Autorità di certificazione (CA) come SSL.com verificare l'identità dei potenziali proprietari di certificati, tramite controlli automatici e manuali su database qualificati.
Questa relazione di fiducia significa che la sicurezza degli utenti web non è assoluta; piuttosto, richiede agli utenti di fidarsi dei browser e delle CA per proteggere la propria sicurezza. Pertanto, riteniamo che sia nell'interesse di ogni utente avere una conoscenza di base del funzionamento della convalida del certificato.
Si noti che il processo di convalida del certificato (descritto in dettaglio nel documento standard RFC 5280) è piuttosto contorto. In questo articolo proveremo a guidarti lungo un percorso (un browser che convalida il SSL /TLS certificato) e navigare attraverso dettagli complessi che non hanno importanza per la maggior parte degli utenti.
Certificati e formato X.509
I certificati sono file digitali sotto ogni aspetto, il che significa che devono seguire un formato file per archiviare informazioni (ad es. Firme, chiavi, emittenti, ecc.). Mentre privato PKI le configurazioni possono implementare qualsiasi formato per i loro certificati, pubblicamente attendibili PKIs (ovvero quelli considerati affidabili dai browser) devono essere conformi a RFC 5280, che richiede l'uso di X.509v3 formato.
X.509 v3 consente ai certificati di includere dati aggiuntivi, come vincoli di utilizzo o informazioni sui criteri, come estensioni, con ciascuna estensione sia critico or non critico. I browser possono ignorare le estensioni non critiche non valide o non riconosciute, ma sono necessarie per elaborare e convalidare tutte quelle critiche.
Percorsi di certificazione ed elaborazione dei percorsi
Le autorità di certificazione utilizzano una chiave privata per firmare in modo crittografico tutti i certificati emessi. Tali firme possono provare irrevocabilmente che un certificato è stato emesso da una specifica CA e che non è stato modificato dopo la sua firma.
Le autorità di certificazione stabiliscono la proprietà della loro chiave di firma in possesso di un certificato emesso da sé (chiamato radice) per la chiave pubblica corrispondente. Le autorità di certificazione devono osservare procedure rigorosamente controllate e controllate per creare, gestire e utilizzare una radice e per ridurre al minimo l'esposizione utilizzerà normalmente una radice per emettere intermedio certificati. Questi intermedi possono quindi essere utilizzati per emettere i certificati dei propri clienti.
I browser vengono forniti con un elenco integrato di root attendibili. (Si tratta di root di CA che hanno superato i rigorosi criteri di inclusione del browser.) Per verificare un certificato, un browser otterrà una sequenza di certificati, ognuno dei quali ha firmato il certificato successivo nella sequenza, collegando la radice della CA firmataria a quella del server certificato.
Questa sequenza di certificati si chiama a percorso di certificazione. La radice del percorso è chiamata a ancora di fiducia e il certificato del server è chiamato foglia or entità finale certificato.
Costruzione del percorso
Spesso i browser devono considerare più percorsi di certificazione fino a quando non riescono a trovarne uno valido per un determinato certificato. Anche se un percorso può contenere certificati che "concatenano" insieme correttamente a un ancoraggio noto, il percorso stesso può essere rifiutato a causa di limitazioni sulla lunghezza del percorso, sul nome di dominio, sull'utilizzo del certificato o sulla politica.
Costruire e valutare tutti i possibili percorsi è un processo costoso eseguito per ogni nuovo certificato che incontra un browser. I browser hanno implementato varie ottimizzazioni per ridurre al minimo il numero di percorsi dei candidati rifiutati, ma approfondire tali dettagli va ben oltre lo scopo di questo articolo.
Convalida del percorso
Dopo aver creato un percorso di certificazione candidato, i browser lo convalidano utilizzando le informazioni contenute nei certificati. Un percorso è valido se i browser possono dimostrare crittograficamente che, a partire da un certificato firmato direttamente da un trust anchor, la chiave privata corrispondente di ogni certificato è stata utilizzata per emettere la successiva nel percorso, fino al certificato foglia.
Algoritmo di convalida del percorso di certificazione
RFC 5280 descrive a algoritmo standard seguiti dai browser per convalidare un percorso di certificazione di certificati X.509.
Fondamentalmente, i browser iterano attraverso tutti i certificati nel percorso iniziando con il trust anchor (cioè il certificato radice), convalidando le informazioni di base di ogni certificato e le estensioni critiche.
Se la procedura si conclude con l'ultimo certificato nel percorso senza errori, il percorso viene accettato come valido. Se vengono generati errori, il percorso è contrassegnato come non valido.
Elaborazione del certificato di base
Indipendentemente da eventuali estensioni, i browser devono sempre verificare le informazioni di base sul certificato come la firma o l'emittente. Le seguenti sezioni mostrano la sequenza dei controlli eseguiti dai browser.
1. Il browser verifica l'integrità del certificato
I firma sul certificato può essere verificato utilizzando la normale crittografia a chiave pubblica. Se la firma non è valida, il certificato viene considerato modificato dopo la sua emissione e pertanto viene respinto.
2. Il browser verifica la validità del certificato
Un certificato periodo di validità è l'intervallo di tempo durante il quale la CA firmataria garantisce che manterrà le informazioni sul suo stato. I browser rifiutano qualsiasi certificato con un periodo di validità che termina prima o che inizia dopo la data e l'ora del controllo di convalida.
3. Il browser controlla lo stato di revoca del certificato
Quando viene rilasciato un certificato, è previsto che sia in uso per l'intero periodo di validità. Naturalmente, varie circostanze possono rendere non valido un certificato prima che scada naturalmente.
Tali circostanze potrebbero includere un soggetto che cambia il proprio nome o una sospetta compromissione della propria chiave privata. In casi come questo, una CA deve revocare il certificato corrispondente e gli utenti si affidano anche a una CA per notificare ai browser lo stato di revoca dei certificati.
RFC 5280 raccomanda alle autorità di certificazione di utilizzare gli elenchi di revoca a tale scopo.
Elenchi di revoche di certificati (CRL)
Le autorità di certificazione emettono periodicamente un elenco firmato e timestamp di certificati revocati chiamato a elenco di revoche di certificati (CRL). I CRL vengono distribuiti in archivi disponibili pubblicamente ei browser possono acquisire e consultare l'ultimo CRL della CA durante la convalida di un certificato.
Un difetto di questo metodo è che la granularità temporale della revoca è limitata al periodo di emissione della CRL. Un browser riceverà una notifica di revoca solo dopo che è stato pianificato l'aggiornamento di tutti i CRL attualmente emessi. A seconda della politica della CA firmataria, l'operazione potrebbe richiedere un'ora, un giorno o anche una settimana.
Protocollo di stato del certificato online (OCSP)
Esistono altri metodi alternativi per acquisire informazioni sullo stato di revoca, tra cui il più popolare è Protocollo di stato del certificato online (OCSP).
Descritto nel documento standard RFC6960, OCSP consente a un browser di richiedere lo stato di revoca di un certificato specifico da un server OCSP in linea (chiamato anche file risponditore). Se configurato correttamente, OCSP è molto più immediato ed evita il problema di latenza di aggiornamento CRL menzionato sopra. Inoltre, Pinzatura OCSP migliora le prestazioni e la velocità.
4. Il browser verifica l'emittente
I certificati sono normalmente associati a due entità:
- I emittente, che è l'entità proprietaria della chiave di firma e
- I soggetto, che fa riferimento al proprietario della chiave pubblica autenticata dal certificato.
I browser controllano che sia presente un certificato emittente campo è uguale al campo soggetto campo del certificato precedente nel percorso. Per una maggiore sicurezza, la maggior parte PKI le implementazioni verificano anche che la chiave dell'emittente sia la stessa della chiave che ha firmato il certificato corrente. (Si noti che questo non è vero per l'ancora di fiducia, poiché le radici sono autoprodotte, ovvero hanno lo stesso emittente e soggetto.)
Elaborazione dei vincoli
Il formato X.509 v3 consente a un'autorità di certificazione di definire vincoli o restrizioni su come ogni certificato viene convalidato e utilizzato come estensioni critiche. Ogni certificato nel percorso può imporre ulteriori vincoli a cui devono obbedire tutti i certificati successivi.
I vincoli dei certificati raramente influenzano l'utente medio di Internet, sebbene siano abbastanza comuni nelle soluzioni SSL aziendali. I vincoli funzionali possono servire a diversi scopi operativi, ma il loro utilizzo più significativo è mitigare i problemi di sicurezza noti.
5. Il browser verifica i vincoli del nome
Una CA intermedia di proprietà privata (ma pubblicamente attendibile) con l'appropriato vincoli di nome può fornire a un'organizzazione un controllo dettagliato sulla gestione e l'emissione dei certificati. I certificati possono essere limitati a un dominio specifico oa un albero di domini (ad esempio, inclusi i sottodomini) per il nome di dominio di una società o organizzazione. I vincoli di nome vengono spesso utilizzati per i certificati CA intermedi acquistati da una CA pubblicamente attendibile per impedire alla CA intermedia di emettere certificati perfettamente validi per domini di terze parti (ad es. google.com).
6. Il browser verifica i vincoli dei criteri
Una politica di certificazione è un documento legale pubblicato da un'autorità di certificazione, che specifica in dettaglio le procedure che seguono per emettere e gestire i propri certificati. Le autorità di certificazione potrebbero emettere un certificato in base a uno o più criteri e i collegamenti a questi sono inclusi in ciascun certificato emesso in modo che le parti facenti affidamento possano valutare tali criteri prima di decidere di fidarsi di quel certificato.
Per motivi legali e operativi, i certificati possono imporre restrizioni a quali politiche possono essere soggetti. Se un certificato contiene vincoli di criteri critici, i browser devono convalidarli prima di procedere. (Tuttavia, i vincoli politici critici si incontrano raramente nel mondo reale e quindi verranno ignorati per il resto di questo articolo.)
7. Il browser verifica i vincoli di base (ovvero la lunghezza del percorso)
Il formato X.509 v3 consente agli emittenti di definire la lunghezza massima del percorso che un certificato può supportare. Ciò fornisce il controllo su quanto ogni certificato può essere inserito in un percorso di certificazione. Questo è effettivamente importante: i browser ignoravano la lunghezza del percorso di certificazione fino a quando un ricercatore non ha dimostrato, in un 2009 presentazione, come ha utilizzato il certificato foglia del suo sito web per creare un certificato valido per un grande sito web di e-commerce.
8. Il browser verifica l'utilizzo dei tasti
L'estensione "utilizzo chiave" indica lo scopo della chiave contenuta nel certificato. Esempi di tali scopi includono crittografia, firme, firma di certificati e così via. I browser rifiutano i certificati che violano i loro vincoli di utilizzo delle chiavi, come l'incontro con un certificato del server con una chiave destinata solo alla firma CRL.
9. Il browser continua a elaborare tutte le rimanenti estensioni critiche
Dopo aver elaborato le estensioni sopra menzionate, i browser procedono alla convalida di tutte le estensioni rimanenti che il certificato corrente designa come critiche, prima di passare a quella successiva. Se un browser raggiunge il certificato foglia di un percorso senza errori, il percorso viene accettato come valido. Se vengono prodotti errori, il percorso viene contrassegnato come non valido e non viene stabilita una connessione sicura.
Conclusione
Il World Wide Web è un sistema complesso di parti mobili interconnesse e in continua evoluzione. La sicurezza del browser non è quindi un problema risolto e speriamo che questo articolo abbia fornito alcune informazioni sulla complessità anche di un solo componente che abbiamo esaminato qui. La fiducia gioca un ruolo importante nel mantenerti al sicuro online e per questo motivo ti invitiamo a chiedere maggiori informazioni sulla politica dei certificati della tua CA. (Sentiti libero di recensire Le politiche di SSL.com qui, infatti.)
Grazie per aver scelto SSL.com, dove crediamo a più sicuro Internet è un better Internet.
