Nota: ho scritto la mia risposta originale molto in fretta, ma da allora, questa è diventata una domanda / risposta abbastanza popolare, quindi l'ho ampliata un po 'e l'ho resa più precisa.
Funzionalità TLS
"SSL" è il nome più spesso usato per fare riferimento a questo protocollo, ma SSL si riferisce specificamente al protocollo proprietario progettato da Netscape a metà degli anni '90. "TLS" è uno standard IETF basato su SSL, quindi userò TLS nella mia risposta. In questi giorni, le probabilità sono che quasi tutte le tue connessioni sicure sul web utilizzano davvero TLS, non SSL.
TLS ha diverse funzionalità:
- Crittografa i dati del livello dell'applicazione. (Nel tuo caso, il protocollo del livello applicazione è HTTP.)
- Autenticare il server sul client.
- Autenticare il client sul server.
# 1 e # 2 sono molto comuni. # 3 è meno comune. Sembra che tu ti stia concentrando sul secondo, quindi ti spiego quella parte.
Autenticazione
Un server si autentica su un client usando un certificato. Un certificato è un blocco di dati [1] che contiene informazioni su un sito Web:
- Nome del dominio
- Chiave pubblica
- La società che lo possiede
- Quando è stato rilasciato
- Quando scade
- Chi l'ha rilasciato
- Eccetera.
È possibile ottenere la riservatezza (n. 1 sopra) utilizzando la chiave pubblica inclusa nel certificato per crittografare i messaggi che possono essere decrittografati solo dalla chiave privata corrispondente, che deve essere archiviata in modo sicuro su quel server. [2] Chiamiamo questa coppia di chiavi KP1, in modo da non confonderci in seguito. Puoi anche verificare che il nome di dominio sul certificato corrisponda al sito che stai visitando (n. 2 sopra).
E se un avversario potesse modificare i pacchetti inviati da e verso il server, e se quell'avversario avesse modificato il certificato che ti veniva presentato e inserito la propria chiave pubblica o cambiato altri dettagli importanti? In tal caso, l'avversario potrebbe intercettare e modificare qualsiasi messaggio che ritieni fosse crittografato in modo sicuro.
Per evitare questo attacco, il certificato è crittografato in modo crittografico dalla chiave privata di qualcun altro in modo tale che la firma possa essere verificata da chiunque disponga della chiave pubblica corrispondente. Chiamiamo questa coppia di chiavi KP2, per chiarire che queste non sono le stesse chiavi utilizzate dal server.
Autorità di certificazione
Quindi chi ha creato KP2? Chi ha firmato il certificato?
Semplificando un po ', un'autorità di certificazione crea KP2 e vendono il servizio di utilizzo della propria chiave privata per firmare certificati per altre organizzazioni. Ad esempio, creo un certificato e pago un'azienda come Verisign per firmarlo con la propria chiave privata. [3] Poiché nessuno tranne Verisign ha accesso a questa chiave privata, nessuno di noi può falsificare questa firma.
E come potrei ottenere personalmente la chiave pubblica in KP2 per verificare quella firma?
Bene, abbiamo già visto che un certificato può contenere una chiave pubblica - e gli informatici amano la ricorsione - quindi perché non inserire la chiave pubblica KP2 in un certificato e distribuirla in quel modo? All'inizio sembra un po 'folle, ma in effetti è esattamente così che funziona. Continuando con l'esempio di Verisign, Verisign produce un certificato che include informazioni su chi sono, quali tipi di cose sono autorizzati a firmare (altri certificati) e la loro chiave pubblica.
Ora, se ho una copia di quel certificato Verisign, posso usarlo per convalidare la firma sul certificato del server per il sito Web che voglio visitare. Facile vero ?!
Beh, non così in fretta. Ho dovuto ottenere il certificato Verisign da qualche parte . Cosa succede se qualcuno falsifica il certificato Verisign e inserisce la propria chiave pubblica? Quindi possono falsificare la firma sul certificato del server e siamo tornati da dove siamo partiti: un attacco man-in-the-middle.
Catene di certificazione
Continuando a pensare in modo ricorsivo, potremmo ovviamente introdurre un terzo certificato e una terza coppia di chiavi (KP3) e utilizzarlo per firmare il certificato Verisign. Questa viene definita catena di certificati: ogni certificato nella catena viene utilizzato per verificare il certificato successivo. Spero che tu possa già vedere che questo approccio ricorsivo è solo tartarughe / certificati fino in fondo. Dove si ferma?
Dal momento che non siamo in grado di creare un numero infinito di certificati, la catena di certificati ha ovviamente di fermarsi da qualche parte , e che ha fatto includendo un certificato della catena che è auto-firmato .
Mi fermerò un attimo mentre raccogli i pezzi di materia cerebrale dalla tua testa che esplode. Self-Signed ?!
Sì, alla fine della catena di certificati (nota anche come "radice"), ci sarà un certificato che utilizza la propria coppia di chiavi per firmare se stesso. Ciò elimina il problema della ricorsione infinita, ma non risolve il problema di autenticazione. Chiunque può creare un certificato autofirmato che dice qualcosa su di esso, proprio come posso creare un falso diploma di Princeton che dice che mi triplico in politica, fisica teorica, e applico calci e poi firmo il mio nome in fondo.
La soluzione [alquanto poco entusiasmante] a questo problema è solo quella di scegliere una serie di certificati autofirmati di cui ti fidi esplicitamente. Ad esempio, potrei dire "Mi fido di questo certificato autofirmato Verisign".
Con quella fiducia esplicita in atto, ora posso convalidare l'intera catena di certificati. Indipendentemente dal numero di certificati presenti nella catena, posso convalidare ogni firma fino alla radice. Quando arrivo alla radice, posso verificare se quel certificato radice è uno di cui mi fido esplicitamente. Se è così, allora posso fidarmi dell'intera catena.
Fiducia conferita
L'autenticazione in TLS utilizza un sistema di attendibilità conferita . Se voglio assumere un meccanico, potrei non fidarmi di alcun meccanico casuale che trovo. Ma forse il mio amico garantisce un meccanico in particolare. Dal momento che mi fido del mio amico, allora posso fidarmi di quel meccanico.
Quando acquisti un computer o scarichi un browser, viene fornito con alcune centinaia di certificati radice di cui si fida esplicitamente. [4] Le società che possiedono e gestiscono tali certificati possono conferire tale fiducia ad altre organizzazioni firmando i loro certificati.
Questo è ben lungi dall'essere un sistema perfetto. Alcune volte un'autorità di certificazione può emettere un certificato erroneamente. In questi casi, potrebbe essere necessario revocare il certificato. La revoca è complicata poiché il certificato rilasciato sarà sempre crittograficamente corretto; è necessario un protocollo fuori banda per scoprire quali certificati precedentemente validi sono stati revocati. In pratica, alcuni di questi protocolli non sono molto sicuri e molti browser non li controllano comunque.
A volte un'intera CA è compromessa. Ad esempio, se dovessi entrare in Verisign e rubare la loro chiave di firma radice, potresti falsificare qualsiasi certificato al mondo. Nota che ciò non riguarda solo i clienti di Verisign: anche se il mio certificato è firmato da Thawte (un concorrente di Verisign), non importa. Il mio certificato può ancora essere contraffatto utilizzando la chiave di firma compromessa di Verisign.
Questo non è solo teorico. È successo in natura. DigiNotar è stato notoriamente violato e successivamente fallito. Anche Comodo è stato violato , ma inspiegabilmente rimangono in attività fino ad oggi.
Anche quando le CA non sono direttamente compromesse, ci sono altre minacce in questo sistema. Ad esempio, un governo usa la coercizione legale per costringere una CA a firmare un certificato contraffatto. Il datore di lavoro può installare il proprio certificato CA sul computer dei dipendenti. In questi vari casi, il traffico che si prevede sia "sicuro" è in realtà completamente visibile / modificabile per l'organizzazione che controlla tale certificato.
Sono state suggerite alcune sostituzioni, tra cui Convergence , TACK e DANE .
Note finali
[1] I dati del certificato TLS sono formattati secondo lo standard X.509 . X.509 si basa su ASN.1 ( "Abstract Syntax Notation # 1"), il che significa che è non è un formato di dati binari. Pertanto, X.509 deve essere codificato in un formato binario. DER e PEM sono le due codifiche più comuni che io conosca.
[2] In pratica, il protocollo passa effettivamente a una cifra simmetrica, ma questo è un dettaglio che non è rilevante per la tua domanda.
[3] Presumibilmente, la CA convalida effettivamente chi sei prima di firmare il certificato. Se non lo facessero, allora potrei semplicemente creare un certificato per google.com e chiedere a una CA di firmarlo. Con quel certificato, potrei essere nel mezzo di qualsiasi connessione "sicura" a google.com. Pertanto, la fase di convalida è un fattore molto importante nel funzionamento di una CA. Sfortunatamente, non è molto chiaro quanto sia rigoroso questo processo di convalida presso le centinaia di CA in tutto il mondo.
[4] Consulta l' elenco di CA affidabili di Mozilla .
