SSL Certificates HOWTO | Capitoli SUCCESSIVI | |||
Come indicato nell'introduzione, questo documento è un semplice HOWTO: è necessario, quindi, consultare le pagine di manuale di
Dovreste anche leggere qualche libro sulla sicurezza, per capire come la vostra sicurezza potrebbe venire compromessa. I certificati ( digitali ) sono stati creati per aumentare la sicurezza nelle transazioni, ma è molto importante che voi comprendiate tutte le implicazioni connesse alle vostre azioni, in merito alla sicurezza, e quali aspetti della sicurezza non sono trattati da Il protocollo Secure Socket Layer ( SSL ) venne creato da Netscape, al fine di gestire transazioni sicure tra i browser ed i server. Il protocollo si server di un soggetto terzo, una Autorità di Certificazione ( CA: Certificate Authority ), per identificare uno o entrambi i soggetti della transazione. In breve, ecco come funziona:
Ci sono un bel po' di concetti da comprendere, qui.
La crittografia che utilizza un paio di chiavi, una pubblica e l'altra privata, assicura che la codifica dei dati venga eseguita con una chiave, mentre la decodifica possa avvenire solo utilizzando l'altra chiave. Sembra un po' difficile da comprendere, ma, credetemi: funziona. Le chiavi, sostanzialmente, condividono la stessa struttura e possono essere utilizzate alternativamente: quello che una chiave cripta, l'altra chiave decripta. La coppia di chiavi è costruita sui numeri primi e la loro lunghezza, in termini di numero di bit, assicura la difficoltà nella decodifica del messaggio, senza l'ausilio della coppia di chiavi. Il trucco, nell'uso delle coppie di chiavi, è di tenere segreta una delle due ( la chiave privata ) e distribuire, a chiunque, l'altra chiave ( la chiave pubblica ). Chiunque potrà inviarvi un messaggio criptato, mentre voi sarete il solo a poterlo decriptare. D'altronde, non siete forse voi il solo ad avere l'altra chiave della coppia ( la vostra chiave privata )? All'estremo opposto, voi potete certificare che un messaggio è stato inviato da voi, poichè siete stato voi a criptarlo, con la vostra chiave privata ( il solo possesso di una chiave privata dimostra già la vostra identità, come creatore di quella chiave ). Chiunque possieda la chiave pubblica associata potrà decriptarlo correttamente. Fate attenzione, però: in questo caso, il messaggio non è al sicuro, poichè chiunque ha la chiave pubblica. Voi lo avete semplicemente firmato. Ricordatelo. Uno dei problemi che abbiamo tralasciato è: come conoscere la chiave pubblica del vostro interlocutore. Normalmente, gli chiedereste di inviarvi un messaggio firmato, non riservato, che conterrà sia la sua chiave pubblica, che un certificato.
Gli algoritmi a chiave pubblica più noti sono: RSA ( dai cognomi dei ricercatori che lo hanno inventato: Ron Rivest, Adi Shamir, Leonard Adleman ), ElGamal ( Taher Elgamal ), Diffie-Hellman ( Whitfield Diffie e Martin Hellman ). ( Nota del traduttore ) Il problema: A vuole inviare a B un messaggio criptato. A chiede a B la sua chiave pubblica. B invia ad A la sua chiave pubblica. A cripta il messaggio da inviare a B, utilizzando la chiave pubblica di B. In questo modo, A è certo che B potrà decriptare il messaggio, usando la sua propria ( di B ) chiave privata. Se un intruso, diciamo C, conoscesse la chiave pubblica di B, cosa potrebbe fare? C potrebbe inviare ad A una sua propria ( di C ) chiave pubblica, facendo credere ad A che si tratti della chiave pubblica di B. A, a questo punto, cripterebbe il messaggio da inviare a B con la chiave pubblica di C. C intercetterebbe il messaggio di A, lo decodificherebbe e lo ricodificherebbe, utilizzando, questa volta, la vera chiave pubblica di B. C invierebbe, quindi, il messaggio ricodificato a B. In questo modo, B sarebbe in grado di decodificare correttamente il messaggio criptato di A. Ne A, ne B potrebbero mai sospettare che qualcun altro, C, abbia aperto e decodificato il messaggio originale. ( Nota del traduttore ) Come sapere se state trattando con la persona giusta o con il sito web giusto? Bene, qualcuno ha fatto ogni sforzo ( se è serio ) per assicurarvi che i proprietari di un sito web sono coloro che dichiarano di essere. Dovete fidarvi di questo qualcuno: avete il suo certificato installato nel vostro browser ( il root Certificate ). Un certificato riporta le informazioni relative: al proprietario del certificato stesso, come l'indirizzo e-mail ed il nome; all'uso del certificato; alla durata della sua validità; all'indicazione della risorsa, quale l'identificatore o Distinguished Name ( DN ), che include il Common Name ( CN ), quale l'indirizzo del sito web, oppure l'indirizzo e-mail, a seconda dell'uso; all'identificativo ( ID ) del certificato della persona che certifica ( firma ) queste informazioni. Un certificato contiene anche la chiave pubblica ed un hash ( firma digitale ) che assicura che il certificato non sia stato modificato. Visto che avete scelto di fidarvi del soggetto che firma ( certifica ) questo certificato, dovete anche fidarvi del certificato stesso. Questa è la struttura ad albero della affidabilità del certificato o il percorso del certificato. Normalmente, il vostro browser o la vostra applicazione ha già installato i cosiddetti "root certificate", i certificati di ben note Autorità di Certificazione ( Certification Authority, o CA ), chiamati anche "root CA Certificates" ( certificati delle CA di root ). Una CA mantiene una lista di tutti i certificati firmati ed una lista di tutti i certificati revocati. Un certificato non è sicuro fino a quando non viene firmato: solo un certificato firmato, infatti, non può essere modificato. E' possibile firmare un certificato, usando il certificato stesso: il cosiddetto "self signed certificate" ( autocertificato ). Tutti i certificati delle CA di root sono autocertificati.
Come potete notare, il certificato contiene le informazioni sull'ente che ha emesso il certificato ( issuer ), la chiave pubblica del proprietario di questo certificato, le date di validità del certificato, e la firma del certificato, per assicurare che questo certificato non è stato modificato. Il certificato non contiene alcuna chiave privata: una chiave privata non deve mai essere trasmessa, in alcuna forma. Questo certificato contiene tutti gli elementi per inviare un messaggio criptato al proprietario ( usando la chiave pubblica ) o per verificare il messaggio firmato dall'autore del certificato. Il meccanismo dei certificati è ben spiegato in Securing Communications with SSL/TLS, di Chris Pepper: come posso collegare una chiave pubblica ad un essere umano o ad un'azienda? SSL/TLS utilizza le autorità di certificazione affidabili ( trusted certificate authority ), dove una terza parte, di fiducia, garantisce per un determinato certificato. Ogni browser web include una serie di certificati di root ( radice ) affidabili ( trusted "root" SSL/TLS certificates ), e tutti i certificati autenticati ( firmati ) da uno di questi certificati di root viene considerato affidabile dal browser. Inoltre, le autorità di certificazione ( "certificate authority", o "CA" ) possono distribuire la loro "affidabilità" ad altre aziende, autenticando certificati "intermedi", i quali possono, a loro volta, autenticare altri certificati. Questa gerarchia di certificati viene definita "catena di certificati". ( Nota del traduttore ) Per quanto riguarda il formato dei certificati digitali, dobbiamo fare riferimento alla RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List ( CRL ) Profile, dedicata agli standard X.509 v3 ( ITU-T, ISO/IEC, ANSI X9 ), per i certificati, e ITU-T X.509 v2, per le liste dei certificati di revoca ( certificate revocation list, CRL ). Il certificato è una SEQUENZA di tre campi obbligatori:
dove:
Per quanto riguarda il certificato vero e proprio:
esso è stato generato da "subject", cioè dal soggetto che ha chiesto alla CA di autenticare i propri dati. Al momento della richiesta di un certificato digitale, infatti, la CA chiede a "subject" ( azienda, organizzazione, sito web richiedente ) di crearsi una propria coppia di chiavi, una pubblica ed una privata. Questo è il solo meccanismo che garantisca che la chiave privata di "subject" non lasci mai il computer in cui è stata generata, che è il computer ( o server ) che, in futuro, utilizzerà il certificato digitale. Una volta generata la propria coppia di chiavi, "subject" dovrà crearsi il proprio campo "Subject" del futuro certificato digitale ( nome, dominio, paese, località ), per poi criptare queste informazioni, utilizzando la propria chiave privata. Il risultato di queste operazioni è il cosiddetto Certificate Signing Request ( CSR ). L'azienda, l'organizzazione o il sito web richiedente dovranno inviare il CSR e la propria chiave pubblica alla CA. Un'Autorità di Certificazione ( CA ) utilizza proprio questo CSR per creare il certificato digitale SSL. Certo, gli algoritmi di codifica dei messaggi fondati sulla coppia di chiavi pubblica e privata sono grandi, ma non sono, normalmente, molto pratici. Si chiamano asimmetrici poichè è necessario avere l'altra chiave della coppia, per decriptare un messaggio. Non è possibile utilizzare la stessa chiave, per criptare e per decriptare. Di un algoritmo che utilizzi una sola chiave, sia per criptare che per decriptare un messaggio, si dice che abbia una chiave simmetrica. Un algoritmo a chiave simmetrica è molto più veloce, nella esecuzione, di un algoritmo a chiavi asimmetriche. Ma, una chiave simmetrica è, potenzialmente, molto poco sicura. Se un nemico viene in possesso della chiave, voi non avrete più informazioni segrete. E' necessario, quindi, trasmettere la chiave ad altri soggetti, senza che il nemico possa metterci le mani sopra. Come saprete, niente è sicuro, in Internet. La soluzione sta nell'incapsulare la chiave simmetrica in un messaggio, criptato con un algoritmo asimmetrico. Voi non avrete mai inviato la vostra chiave privata a chichessia. Quindi, il messaggio criptato con la chiave pubblica è sicuro ( relativamente sicuro, visto che nulla è certo, eccetto la morte e le tasse ). Anche la chiave simmetrica viene scelta a caso, in modo tale per cui, se anche venisse scoperta, non sarebbe la stessa usata nella transazione successiva.
Gli algoritmi a chiave simmetrica più noti sono: DES ( Data Encryption Standard ), Triple DES, IDEA, RC2, RC4. ( Nota del traduttore )
Esistono molti algoritmi di codifica dei messaggi, di cui alcuni utilizzano il metodo simmetrico, altri il metodo asimmetrico. Ciascun algoritmo, poi, utilizza chiavi di varia lunghezza. Normalmente, gli algoritmi non possono essere brevettati. Se Henri Poincare avesse brevettato i suoi algoritmi, avrebbe potuto citare in giudizio Albert Einstein ... Quindi, gli algoritmi non possono essere brevettati, eccetto, principalmente, negli USA. OpenSSL viene sviluppato in un paese in cui gli algoritmi non possono essere brevettati e dove la crittografia non è riservata alle agenzie statali, quali i servizi militari ed i servizi segreti. Nel corso della negoziazione tra il browser ed il server web, le applicazioni si scambiano una lista degli algoritmi supportati, in ordine di preferenza. L'algoritmo preferito comune ad entrambi gli interlocutori viene quindi scelto. OpenSSL può essere compilato con o senza alcuni algoritmi, in modo da poter essere utilizzato anche in molti paesi in cui esistono delle restrizioni. Un hash è un numero, restituito da una funzione di hash, eseguita su un messaggio. Si tratta di una funzione a senso unico: è impossibile risalire al messaggio originale, partendo dall'hash. Tuttavia, un hash cambia drasticamente anche per la più lieve modifica apportata al messaggio. E', quindi, estremamente difficile modificare un messaggio, mantenendo il suo hash originale. Un hash viene anche chiamato "digest" del messaggio ( sunto, compendio, riassunto ). Le funzioni di hash vengono usate nei meccanismi di password, nella certificazione dell'originalità delle applicazioni ( somma MD5 ) e, in genere, nella verifica che un qualsiasi messaggio non abbia subito modifiche. Sembra che la Internet Enginering Task Force ( IETF ) preferisca l'algoritmo SHA1 a MD5, per una serie di ragioni tecniche ( RFC2459 7.1.2 e 7.1.3 ). Firmare un messaggio significa garantire che voi stessi potete assicurare l'autenticità del messagio ( nella gran parte dei casi, questo significa che voi ne siete anche gli autori, ma non è necessario ). Il messaggio può essere un messaggio di testo, oppure il certificato di un altro. Per firmare un messaggio, dovete crearne l'hash, criptare, poi, l'hash con la vostra chiave privata, aggiungere, infine, l'hash criptato ed il vostro certificato autenticato al messaggio. Il destinatario dovrà ricreare l'hash del messaggio, decriptare l'hash criptato, usando la vostra chiave pubblica, memorizzata nel vostro certificato autenticato, verificare che i due hash siano identici e, in ultimo, verificare il certificato. L'altro vantaggio della firma del messaggio è che la vostra chiave pubblica ed il vostro certificato vengono inviati automaticamente a tutti i vostri destinatari. Esistono, normalmente, due modalità di firma: incapsulare il messaggio testuale nella firma ( usando dei delimitatori ), oppure codificare il messaggio insieme alla firma. Quest'ultima forma è una modalità di codifica molto semplice, visto che qualsiasi software potrà decifrare il messaggio, se sarà in grado di isolare la chiave pubblica. Il vantaggio del primo approccio è che il messaggio verrà trasmesso in chiaro, in modo che un qualsiasi programma non conforme potrà girare il messaggio, così com'è, all'utente, che sarà in grado di leggerlo, mentre, nel secondo approccio, non sarà nemmeno possibile leggere una parte del messaggio, nel caso fosse stato modificato. “Una passphrase è come una password, però è più lunga”. Agli albori dell'informatica, le password, sui sistemi Unix, potevano essere composte da un massimo di 8 caratteri. Da qui, il nome di "passphrase" per le password più lunghe. Più lunga è una password, più arduo diventa l'indovinarla. Oggi, i sistemi Unix utilizzano gli hash MD5, che non prevedono limitazioni sulla lunghezza delle password.
La Public Key Infrastructure ( PKI ) è il sistema software di gestione, comprensivo di database, che rende possibili l'autenticazione di un certificato, il mantenimento di liste di certificati revocati, la distribuzione delle chiavi pubbliche, etc. E' possibile, normalmente, accedervi via web e/o via server LDAP. Ci sarà pure qualcuno che vorrà verificare che voi siate chi siete ... Per mettere in sicurezza singole applicazioni, potrete usare un qualsiasi PKI commerciale ben conosciuto, visto che, molto probabilmente, il loro certificato sarà già presente nel vostro browser ( o nella vostra applicazione ). Il problema sarà mettere in sicurezza le e-mail, sia che riceviate un certificato generico, per la vostra e-mail, sia che paghiate circa 100 dollari all'anno per certificato o per indirizzo e-mail. In più, se, da qualcuno, non avete mai ricevuto una mail, contenente il suo certificato ( inclusa la chiave pubblica ), non c'è modo per riuscire a trovarne la chiave pubblica.
Anche se SSL venne sviluppato per i server web, può essere utilizzato per criptare qualsiasi protocollo. E' possibile incapsulare qualsiasi protocollo, con SSL: IMAP, POP, SMTP, ... Questi protocolli, nella loro versione "secure", utilizzeranno una porta differente, rispetto alle loro versioni "non secure". SSL può essere usato anche per criptare qualsiasi transazione: non è necessario essere in contatto diretto ( live ) con il destinatario. S/Mime è uno di questi protocolli: esso incapsula un messaggio criptato in una email standard. Il messaggio viene criptato utilizzando la chiave pubblica del destinatario. Se non siete online con il vostro destinatario, dovrete conoscere la sua chiave pubblica. O la scaricherete dal suo sito web, o da un archivio ( repository ), oppure dovrete chiedere al destinatario di inviarvi, via email, la sua chiave pubblica ed il suo certificato ( per assicurarvi di parlare con l'interlocutore giusto ). Al contrario, il browser può inviare il suo certificato autenticato ( firmato ) al server web, come mezzo di autenticazione. Ma, chiunque può ottenere il certificato del browser in un sito web di una CA ( Certification Authority ). E' vero, ma il certificato autenticato ( firmato ) è stato criptato utilizzando la chiave privata, e solo la chiave pubblica può decriptarlo.
|
||||
SSL Certificates HOWTO | Disclaimer: questo è un link a contenuti ospitati su server esterni. |