Sommario

1. Il contesto
2. Come funziona SSL?
3. SSL in pratica
1. Utilizzare un certificato server
1. Effettuare la richiesta di un certificato server
2. Utilizzare una CA locale per rilasciare il certificato server
3. Installare il certificato in IIS
4. Collegarsi al server tramite https
2. Utilizzare un certificato client
1. Importare il certificato della CA nel server web
2. Richiedere e installare un certificato per il proprio browser web
3. Configurare il server per richiedere il certificato al client
4. Effettuare un mapping tra il certificato client e un account utente

 

1. Il contesto

Quasi tutte le scuole italiane hanno e gestiscono oggi un proprio sito web. Nella maggior parte dei casi il sito viene tenuto in hosting presso un provider che offre spazio su disco, connettività, DNS ed altri servizi.

Un passo ulteriore verso la presenza sul web delle scuole è costituito dall'esigenza di pubblicare autonomamente un proprio server. Possono esservi servizi o applicazioni che hanno bisogno di configurazioni o permessi aggiuntivi, che devono essere richiesti - e pagati - ai provider (1). Oppure, supponiamo di voler consentire anche da casa ai docenti l'accesso al file server della rete didattica della scuola: su questo vi saranno naturalmente delle permission di accesso, che vorremmo fossero mantenute per le connessioni via web. O ancora, per fare un ultimo esempio, pensiamo alla pubblicazione su web di servizi relativi agli studenti come le comunicazioni delle assenze e delle entrate in ritardo (2), o delle valutazioni, che richiedono una interazione con dei database che risiedono su altri server della scuola, e, per ovvi motivi di privacy, una connessione criptata.

L'idea di mettere in Rete un proprio server web è oggi tecnicamente ed economicamente meno improponibile per una scuola di quanto lo fosse qualche anno fa. Infatti, è possibile che si disponga di una banda maggiore in uscita: sono più diffusi i collegamenti HDSL, che non potranno forse garantire l'alta disponibilità richiesta da un server web di e-commerce, ma potrebbero essere sufficiente per i limitati obiettivi di connettività di un sito scolastico. E macchine dai requisiti sufficienti a supportare i servizi web che possono essere utili ad una scuola si reperiscono con facilità e a costi relativamente contenuti. Oppure è facile noleggiare un server dedicato presso un provider, risolvendo contemporaneamente i problemi dell’hardware e della connettività.

Insomma, in certi casi è utile e, con un po' di buona volontà, possibile gestire un proprio server Web. Nel fare ciò, vi sono varie misure di sicurezza da adottare. In questo articolo intendo presentare i concetti e le procedure necessarie a gestire comunicazioni protette attraverso i certificati digitali

2. Come funziona SSL?

Tra le possibilità offerte da un server web, quella di implementare un canale protetto con Secure sockets layer realizza un buon livello di sicurezza nella trasmissione dei dati, e risponde a standard che lo rendono indipendente dalla piattaforma su cui sono eseguiti sia il server che il client.

Premesso che ne daremo qui una rappresentazione molto semplificata ed informale (3), vediamo quali sono i principi di funzionamento di SSL.

I principali obiettivi perseguiti da un sistema di crittografia sono:

1. riservatezza: i dati trasmessi non devono essere letti da soggetti che non ne sono destinatari
2. integrità: i dati trasmessi devono venire ricevuti senza aver subito alterazioni durante il percorso
3. autenticità: deve essere certa l’identità dell’interlocutore
4. non ripudio: chi ha inviato determinate informazioni, non può, in un secondo tempo, negare di esserne stato il mittente

Ora, se si potesse utilizzare con facilità un sistema di criptatura sufficientemente potente da renderne assai difficile la decifrazione in tempi ragionevoli, questi requisiti verrebbero soddisfatti facilmente: il soggetto che deve inviare un'informazione la cripta con la propria chiave; durante il tragitto il messaggio non può essere letto, in quanto è cifrato; il destinatario deve poterla decifrare usando la stessa chiave: se ci riesce, sarà garantita anche l'integrità del messaggio e l'identità del mittente, dal momento che solo quest'ultimo poteva cifrare il messaggio con quella chiave.

Questa è la tecnologia a chiave simmetrica condivisa: usa un algoritmo di cifratura e una chiave nota sia al mittente che al destinatario. Quanto più complessa è la chiave (quanto maggiore è il numero di bit che la compongono), tanto più forte è la crittografia.

Il difetto di questo sistema sta nella difficoltà di trasmettere in modo affidabile ed insieme efficiente la chiave di cifratura: è logico che non è opportuno usare lo stesso canale tramite il quale vengono trasferiti i dati, in quanto la chiave passerebbe attraverso il canale in forma non cifrata e potrebbe venire facilmente intercettata. Se la cifrassimo con un'altra chiave simmetrica avremmo semplicemente spostato il problema. E, ammesso di essere riusciti ad inviarla per la prima volta in modo sicuro (p. es. per posta cartacea, o mediante consegna a mano), come faremmo a rinnovarla periodicamente, necessità che sorge dal fatto che, più lungo è il tempo di esposizione di un sistema di cifratura, maggiori sono le probabilità che esso venga decifrato?

La ricerca volta a rendere più sicuri i metodi di crittografia ha portato all'elaborazione della tecnologia a chiave asimmetrica.

Questa applica algoritmi che necessitano di una coppia di chiavi: i dati che vengono cifrati con una delle due chiavi della coppia possono essere decifrati solo con l'altra, e viceversa. Una delle due chiavi è segreta, e dunque può essere utilizzata solo dal titolare; l'altra è pubblica, nel senso che è disponibile a tutti i corrispondenti del titolare.

Così, se p. es. l'obiettivo che si vuole conseguire è quello della riservatezza della comunicazione, basterà che il mittente ottenga la chiave pubblica del destinatario e con essa cripti i dati; solo il destinatario li potrà decriptare usando la corrispondente chiave privata.

Se si vuole realizzare l'autenticazione, l’integrità e il non ripudio del messaggio, sarà il mittente ad utilizzare la propria chiave privata, apponendo la propria firma digitale; il destinatario potrà decriptare i dati solo con la chiave pubblica del mittente, e ciò ne garantirà l'origine e l’autenticità.

Se si vogliono raggiungere i quattro obiettivi insieme, bisognerà usare sia la coppia di chiavi del mittente che quella del destinatario.

Un difetto di questa tecnologia è che, rispetto a quella a chiave simmetrica, è più lenta, e poco adatta per criptare grandi quantità di dati.

Nella tecnologia SSL i due metodi, quello a chiave asimmetrica e quello a chiave simmetrica, vengono combinati. La coppia di chiavi asimmetriche viene utilizzata per negoziare e scambiarsi una chiave simmetrica, detta chiave di sessione, che sarà usata per criptare i dati. La chiave di sessione ha una validità limitata, e non potrà essere riutilizzata in un momento diverso, o da un altro utente.

Vediamone un'esemplificazione.

Supponiamo che un client chieda ad un server di instaurare una connessione SSL, cosa che viene fatta utilizzando il protocollo HTTPS.

Il server invia la propria chiave pubblica al client

Il client utilizzerà la chiave pubblica per criptare una chiave di sessione da lui generata, che invierà al server

Il server, che detiene la chiave privata corrispondente alla chiave pubblica inviata al client, la utilizzerà per decifrare il messaggio del client e ricostruire la chiave di sessione

Da questo momento inizia la comunicazione protetta, criptata con la chiave simmetrica di sessione.

Alla fine della sessione, la chiave di sessione viene scartata.

Affinché questo scambio possa avvenire, sono necessari i certificati digitali. Questi sono documenti elettronici che contengono i dati identificativi del titolare e la sua chiave pubblica; inoltre sono firmati da un’autorità di certificazione, che ne garantisce l’autenticità.

Prima di poter stabilire una connessione protetta, i due host devono potersi identificare reciprocamente. Se la connessione viene stabilita, p. es., per concludere una transazione commerciale, l'utente deve essere certo dell'identità del server prima di mandargli, criptato, il proprio numero di carta di credito.

Nell'esempio di sopra, il server non invia al client solo la propria chiave pubblica, ma un proprio certificato digitale, contenente, oltre alla chiave pubblica, informazioni necessarie a consentire al client di identificarlo con sicurezza.

Naturalmente, come accade con i documenti cartacei, la attendibilità del certificato è proporzionale al grado di fiducia riposta nell'organizzazione che lo ha rilasciato. La funzione di rilasciare i certificati è demandata alle Autorità di certificazione (CA). Queste sono organizzazioni di fiducia di entrambe le parti, che hanno il compito di accertare l'identità del soggetto a cui rilasciano il certificato, ed attestarla ai suoi partner. Le CA appongono la propria firma digitale sui certificati da esse rilasciati. Il client controlla la firma comparandola con la chiave pubblica della CA; se questo controllo ha buon fine, il certificato sarà considerato valido, e sufficiente a comprovare l'identità dell’host a cui si sta cercando di collegare.

Ma come fa il client a possedere la chiave pubblica della CA, e ad essere sicuro che appartenga proprio a questa organizzazione? Alcune CA sono riconosciute a livello mondiale, e i loro certificati - cioè, i certificati che attestano l'identità dell'autorità di certificazione - sono già installati per default nei nostri browser:

In questo modo, quando ci collegheremo ad un server web tramite SSL, il browser comparerà la firma apposta sul certificato server con quella della CA, registrata sul certificato della CA già in suo possesso. Se la firma sarà considerata valida, altrettanto lo sarà il certificato del server, e la negoziazione della chiave di sessione potrà avere inizio.

Ovviamente, per chi gestisce il server web ottenere il rilascio di un certificato server da parte di una CA ha un costo, che varia in funzione del tipo di certificazione richiesto. D'altra parte, per molti scopi non è necessario disporre di un certificato valido su scala mondiale. Se il canale HTTPS deve essere stabilito tra un server e i client di una stessa organizzazione, è possibile implementare in proprio un'autorità di certificazione, che rilascerà i certificati necessari. Naturalmente, i client non avranno già a disposizione, nel proprio elenco delle fonti attendibili, il certificato della nostra CA; ma sarà possibile importarlo, come illustreremo più sotto.

 

3. SSL in pratica

Vediamo adesso in che modo possiamo implementare una connessione protetta con SSL (4).

SECONDA PARTE

3.1 Utilizzare un certificato server

Gli obiettivi che ci proponiamo qui sono l’autenticazione del server e la creazione di un canale protetto

3.1.1.Effettuare la richiesta di un certificato server

In IIS, accediamo alle proprietà del sito web per il quale vogliamo chiedere un certificato, selezioniamo la scheda Directory security e clicchiamo su Server certificate.

Dato che il nostro sito web non ha ancora un certificato, verrà avviata una wizard nella quale saremo guidati a richiederne uno. Selezioniamo Create a new certificate, e poi scegliamo di inviare la richiesta in seguito.

Saremo quindi inviati a scegliere la lunghezza per la chiave pubblica:

Questa è una scelta molto importante, poiché è uno dei principali fattori da cui dipende quanto sarà sicura la connessione SSL che i client potranno stabilire col server.

Andando avanti, inseriamo le altre informazioni, finché non ci verrà proposto il percorso nel quale verrà salvata la nostra richiesta del certificato, qui g:\certreq.txt

Completata la procedura guidata, abbiamo un file di testo, certreq.txt, che dovremo far pervenire alla CA per ottenere il rilascio del certificato.

3.1.2. Utilizzare una CA locale per rilasciare il certificato server

A questo punto dobbiamo rivolgerci a un’Autorità di certificazione. In base ai nostri scopi, al nostro budget e al tempo a disposizione possiamo far riferimento a una CA commerciale, oppure realizzarne una noi. In questo tutorial scegliamo quest’ultima strada. Ciò comporta alcuni vantaggi e svantaggi. Tra i vantaggi, il principale è che non devono essere sostenuti costi e tempi morti per il rilascio e il rinnovo dei certificati. Tra gli svantaggi, c’è quello di dover disporre di una macchina dedicata, con conseguenti costi per l’hardware, per il sistema operativo, per la sua messa in sicurezza fisica e di rete, e per la sua gestione (5).

Supponiamo dunque di aver configurato la nostra CA su una macchina come standalone root CA: il servizio certificati è un componente di Windows, che si installa come tutti gli altri da Pannello di Controllo.

Accediamo al servizio certificati via browser, da una qualunque macchina collegata in rete al server certificati. Se il nostro server dei certificati si chiama Server-CA, per accedere all'autorità di certificazione bisognerà digitare nella barra degli indirizzi del browser http://Server-CA/certsrv

Scegliamo di richiedere un nuovo certificato, e andiamo avanti. Per richiedere un certificato server, dovremo selezionare Advanced request:

Scegliamo di richiedere un certificato tramite un file (il nostro certreq.txt):

Facciamo copia e incolla del contenuto del file certreq.txt nel campo saved request, e inoltriamo la richiesta.

A questo punto, se stessimo cercando di ottenere un certificato da una CA esterna, dovremmo aspettare il tempo necessario perché la CA si accerti della nostra identità:

Dal momento però che, in questo caso specifico, la CA è gestita da noi, rilasciare il certificato sarà affare di un attimo.

Spostiamoci sul server sul quale abbiamo installato la CA, e apriamo lo snap-in Certification Authority. Nel ramo Pending requests troveremo la richiesta di certificato che abbiamo appena inoltrato:

Facciamo click destro sulla richiesta, e selezioniamo Issue. La richiesta verrà spostata nel ramo Issued Certificates. Se la esaminiamo, facendoci doppio click sopra, vedremo il certificato appena creato:

Tra le altre informazioni, contiene la nostra chiave pubblica, che in questo caso è a 1024 bit:

3.1.3. Installare il certificato in IIS

Adesso, recuperiamo il certificato rilasciato dalla CA. Accediamo di nuovo alla Home page della CA con lo stesso browser con il quale abbiamo prima inoltrato la richiesta. Stavolta scegliamo di verificare una richiesta in sospeso:

e quindi di scaricare il certificato:

Il file ottenuto si chiamerà certnew.cer

Torniamo al nostro server IIS, accediamo di nuovo alla scheda Directory security relativa al sito che vogliamo dotare di un certificato, e selezioniamo di nuovo Server Certificate. Stavolta la wizard avrà un aspetto diverso, in quanto un certificato per questo sito è stato già richiesto, ed è possibile installare un solo certificato per ciascun sito web:

Selezioniamo il percorso in cui abbiamo salvato il certificato:

E impostiamo la porta per la connessione SSL, che di default è 443:

Completata la wizard, avremo installato il certificato per il nostro sito web.

A questo punto, il browser del client potrà collegarsi sia con il protocollo HTTP (trasmissione in chiaro), sia con il protocollo HTTPS (trasmissione criptata e autenticazione del server). Per forzare il client a collegarsi in modalità protetta, sempre dalla scheda Directory security selezioniamo Edit, e mettiamo un segno di spunta accanto a Require secure channel:

 

3.1.4. Collegarsi al server tramite https

Colleghiamoci adesso al sito web da un computer client. Quando cercheremo di visualizzare la risorsa usando il protocollo HTTP, ci verrà detto che è richiesta una connessione SSL:

Cerchiamo allora di visualizzare la pagina inserendo nella barra degli indirizzi la stessa URL, formata però con HTTPS, invece che con HTTP. Dopo averci informati che stiamo per visualizzare le pagine su una connessione protetta, un altro avviso di protezione ci dirà che il server web ha presentato un certificato rilasciato da una CA non inclusa nell'elenco della CA riconosciute dal browser. Questo ce lo aspettavamo, in quanto la CA che ha rilasciato il certificato è "fatta in casa", e quindi non può essere elencata tra quelle i cui certificati vengono installati per default con IE. Cliccando su Sì riusciremo comunque ad accedere al sito.

In questo modo, tuttavia, gli utenti del sito avranno il fastidio di trovarsi ogni volta a dover rispondere a una domanda della quale non sono tenuti a comprendere il senso. Per ovviare a questo inconveniente, dovranno installare una tantum nel proprio browser il certificato della CA.

Perché possano fare ciò, dobbiamo esportare quest’ultimo certificato. Per farlo, sul server CA generiamo una nuova MMC con lo snap-in Certificati per il computer locale, e nel ramo Personal/Certificates esportiamo il certificato auto-rilasciato dalla CA, facendo attenzione a non esportare la chiave privata, ma solo la chiave pubblica:

 

Supponiamo di aver distribuito questo certificato della CA su un floppy. Ciò non crea problemi di sicurezza, perché il certificato contiene solo la chiave pubblica del server, e dunque è pubblico per definizione. L'utente, se usa Internet Explorer, dovrà accedere alla finestra di dialogo Opzioni, aprire la scheda Contenuti e cliccare su Certificati. Quindi cliccare su Importa e navigare fino alla locazione in cui ha salvato il certificato del server CA che gli è stato distribuito. Conclusa la wizard, il certificato sarà stato importato, e il nostro server CA risulterà nell'elenco delle fonti attendibili insieme a quelli più blasonati:

A questo punto, l'utente potrà accedere al nostro sito con HTTPS senza che gli venga presentato l’avviso di protezione. Dalla prossima volta che lo farà, non avrà ovviamente bisogno di ripetere la procedura di importazione del certificato.

 

3.2 Utilizzare un certificato client

Adesso vediamo in che modo si può richiedere, installare ed utilizzare un certificato per il proprio browser web. Gli scopi di questa procedura sono:

• Identificare il client tramite il certificato
• Autenticare l’utente tramite un’associazione tra il certificato client da lui utilizzato ed un account riconosciuto dal server web

 

3.2.1. Importare il certificato della CA nel server web

Preliminarmente, dobbiamo accertarci che il server web riconosca la CA. Ciò è necessario, in quanto solo in questo modo il certificato del client, rilasciato da quella CA, potrà essere ritenuto valido dal server.

Apriamo lo snap-in Certificates del server web, e visualizziamo il ramo Trusted Root Certification Authority/Certificates:

Se la nostra CA è tra quelle pubblicamente riconosciute, probabilmente la troveremo già elencata nel pannello a destra. Nel nostro caso, invece, dovremo importarne il certificato.

Per farlo, visitiamo di nuovo con il browser il sito della CA, e selezioniamo Retrieve the CA certificate:

e scarichiamo il certificato della CA.

Ora torniamo allo snap-in Certificates del server web, e nel ramo Trusted Root Certification Authority/Certificates scegliamo Import selezionando il certificato della CA appena scaricato.

La CA risulterà adesso tra quelle ritenute attendibili dal server web.

 

3.2.2. Richiedere e installare un certificato per il proprio browser web

Dalla macchina che utilizziamo come client, accediamo ancora una volta al servizio certificati:

Prima abbiamo richiesto un certificato per il server. Stavolta dobbiamo richiederne uno per il browser web:

Inseriamo le informazioni richieste:

Come nel caso del certificato server, appare il messaggio Certificate pending. Dal momento che, nel nostro esempio, l’autorità di certificazione siamo noi, sul server CA apriamo lo snap-in Certification Authority ed seguiamo la stessa procedura di prima per effettuare il rilascio del certificato, senza dimenticare che in una situazione reale questo è uno dei momenti più delicati dell’intera procedura, dovendo essere preceduto da un accertamento effettivo dell’identità del richiedente.

Torniamo quindi con il browser del client alla home page dell’autorità di certificazione, per verificare se il certificato ci è stato rilasciato.

In caso di risposta affermativa, clicchiamo su Install this certificate:

Leggiamo attentamente l’avviso, e se siamo sicuri di quello che stiamo facendo, selezioniamo OK. Un messaggio ci informerà che il certificato è stato installato nel nostro browser. Per verificarlo, apriamo la scheda Contenuto del menu Strumenti/Opzioni di IE, e clicchiamo su Certificati. Nell’area Personale vedremo elencato il certificato client che abbiamo appena installato:

Come si può vedere, lo scopo del certificato è l’autenticazione del client.

3.2.3. Configurare il server per richiedere il certificato al client

Adesso siamo quasi pronti per collegarci al sito web utilizzando un certificato per identificare anche il client. Prima, però, vediamo le impostazioni da dare al server.

Riapriamo la scheda Directory security del sito, directory o file per il quale vogliamo abilitare l’utilizzo dei certificati lato client, e apriamo la finestra di dialogo per la configurazione delle Secure communications:

Nella seconda area della finestra, Client certificates, selezioniamo l’opzione Require client certificates (opzione attivata solo se abbiamo in precedenza installato un certificato server). In questo modo il server consentirà la connessione alla risorsa solo a browser dotati di certificato client.

Quando, utilizzando il browser, cercheremo do collegarci al sito, ci verrà presentato da IE un elenco di certificati Personali installati, tra i quali dovremo scegliere quello appena installato:

Selezionato il certificato, potremo accedere alla risorsa protetta.

3.2.4. Effettuare un mapping tra il certificato client e un account utente

L’ultimo aspetto che prendiamo in considerazione è l’associazione tra un account utente e un certificato digitale. Con questa operazione sarà possibile, per il client, accedere a risorse sulle quali sono impostate permission per un determinato utente, senza inviare le credenziali di quell’utente in chiaro o in forma criptata.

Innanzitutto, bisogna rendere disponibile al server web il certificato del client. Esportiamo il certificato dal client, accedendo in IE al menu Strumenti/Opzioni Internet, e quindi selezionando le schede Contenuto/Certificati. Qui troveremo un elenco dei certificati client installati nel browser. Selezioniamo quello che ci interessa ed esportiamolo. Parte una wizard, nella quale viene data solo la possibilità di esportare la chiave pubblica dell’utente

Salviamo il certificate in una posizione accessibile al server web.

Sul server, in IIS, operiamo ancora nella scheda Secure communications del sito, directory o file su cui vogliamo impostare il mapping, selezioniamo Enable client certificate mapping e clicchiamo su Edit:

Nella finestra che appare (Account mappings / 1-to-1) clicchiamo su add:

e selezioniamo prima il file contenente il certificato precedentemente esportato dal browser del client, poi l’utente con il quale vogliamo associare quel certificato (qui: user1).

A questo punto, chi si collega al sito utilizzando il proprio certificato potrà accedere alle risorse pubblicate dal server con gli stessi diritti dell’utente al quale quel certificato è associato senza dover digitare né in alcun modo trasmettere le proprie credenziali di autenticazione.

________________________

10 ottobre 2004