Realizzazione di Web services per l’autenticazione Single ... · 10 Introduzione Questo lavoro di...
143
UNIVERSITÀ DEGLI STUDI DELLA CALABRIA Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Orientamento Elettronica e Telecomunicazioni Realizzazione di Web services per l’autenticazione "Single Sign On" su infrastruttura PKI/LDAP Relatori: Prof. Nicola FREGA Prof. Antonio VOLPENTESTA Tesi di Laurea di Salvatore IACOMETTA Matr. 25728 Anno Accademico 2003/2004
Transcript of Realizzazione di Web services per l’autenticazione Single ... · 10 Introduzione Questo lavoro di...
UNIVERSITÀ DEGLI STUDI DELLA CALABRIA
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Orientamento Elettronica e Telecomunicazioni
Realizzazione di Web services per l’autenticazione "Single
Sign On" su infrastruttura PKI/LDAP
Relatori:
Prof. Nicola FREGA
Prof. Antonio VOLPENTESTA
Tesi di Laurea di
Salvatore IACOMETTA
Matr. 25728
Anno Accademico 2003/2004
3
4
A papà che, ora che è sempre al mio fianco, gioisce insieme a me
per questo traguardo raggiunto
5
Sommario
INTRODUZIONE ..................................................................................................................... 10
CAPITOLO 1: LA SICUREZZA ............................................................................................ 11
1.1 INTRODUZIONE .................................................................................................................... 121.1.1. LA FIDUCIA NELLA “TERZA-PARTE” ................................................................................. 131.1.2. FIDUCIA SENZA INTERMEDIAZIONI .................................................................................. 141.1.3. VALIDITÀ DEI CERTIFICATI ............................................................................................... 141.1.4. CERTIFICATION AUTHORITY............................................................................................ 161.2. LA SICUREZZA..................................................................................................................... 181.2.1. CONCETTI BASE DI UN SERVIZIO DI SICUREZZA ............................................................. 191.2.2. TECNICHE CRITTOGRAFICHE .......................................................................................... 211.2.2.1. La crittografia simmetrica.......................................................................................... 221.2.2.2. La crittografia asimmetrica ....................................................................................... 231.2.2.3. L’utilizzo pratico della crittografia............................................................................. 241.2.3. LA FIRMA DIGITALE .......................................................................................................... 251.2.4. DISTRIBUZIONE SICURA DI CERTIFICATI DIGITALI ........................................................... 281.2.5. RICHIESTA DI UN CERTIFICATO DIGITALE ....................................................................... 301.2.6. IL “LATO” UTENTE ............................................................................................................ 321.3. SSL 3.0 ................................................................................................................................ 331.3.1. SEQUENZA DI HANDSHAKE.............................................................................................. 33
CAPITOLO 2: PKI ................................................................................................................... 35
2.1 PUBLIC KEY INFRASTRUCTURE.......................................................................................... 362.2 FUNZIONI ASSOLTE DA UNA PKI......................................................................................... 362.3 TIPI DI PKI ........................................................................................................................... 40
CAPITOLO 3: LDAP ............................................................................................................... 43
3.1 LDAP INTRODUZIONE......................................................................................................... 443.2 LDAP IN DETTAGLIO........................................................................................................... 473.2.1 COSA È UNA DIRECTORY .................................................................................................. 473.2.2 DIFFERENZE TRA LDAP E DATABASE RELAZIONALI ........................................................ 473.2.3 DIFFERENZE TRA LDAP E X.500 ...................................................................................... 483.2.4 LA RADICE DELL'ALBERO .................................................................................................. 483.2.5 ORGANIZATIONAL UNIT .................................................................................................... 483.2.6 I BACKEND......................................................................................................................... 493.2.7 CREARE GLI INDICI............................................................................................................ 493.2.8 ACCESS CONTROL LIST .................................................................................................... 493.2.9 REPLICA ............................................................................................................................ 503.2.10 INTEGRAZIONE DI LDAP .................................................................................................. 513.2.11 IL PACCHETTO LDAP-UTILS ............................................................................................ 513.2.12 SUPPORTO DELLA CRITTOGRAFIA ................................................................................. 52
6
3.2.13 STRUMENTI DI AMMINISTRAZIONE ................................................................................. 523.2.14 INTEGRAZIONE DI LDAP SUI CLIENT ............................................................................... 53
CAPITOLO 4: I WEB SERVICES ......................................................................................... 54
4.1 I WEB SERVICES................................................................................................................... 554.2 MOTORI DI RICERCA PER WEB SERVICES.......................................................................... 564.3 UN PO’ DI ESEMPI................................................................................................................. 564.3.1 UN PRIMO ESEMPIO: UN TRADUTTORE INGLESE-ITALIANO ........................................... 564.3.2 I PARAMETRI CHE SI DEVONO PASSARE: UDDI .............................................................. 584.3.3 LE INFORMAZIONI IN XML SCAMBIATE ............................................................................ 594.3.4 UN SECONDO ESEMPIO: LA JPG DI UN CODICE A BARRE ................................................ 594.3.5 DAL CLIENT AL SERVER: CREARE UN WEB SERVICES................................................... 604.3.6 UN ALTRO ESEMPIO: IL CODICE IN PHP PER INTERROGARE GOOGLE.......................... 62
CAPITOLO 5: INSTALLAZIONE E TEST DEL SERVER ................................................ 63
5.1 COME INIZIARE.................................................................................................................... 645.2 PROCEDURA PER AUTO-CERTIFICARE IL SERVER, PER CREARE CERTIFICATI-CLIENT EPER RICONOSCERE ALTRI CERTIFICATI-CLIENT ..................................................................... 645.3 COSA ABBIAMO OTTENUTO................................................................................................. 665.3.1 “OVER HTTPS”................................................................................................................... 675.4 PROVIAMO A FARE DEI TEST ............................................................................................... 715.4.1 MODIFICHIAMO IL FILE DI CONFIGURAZIONE ................................................................... 715.4.2 PRELEVARE CON PHP I DATI DEL CERTIFICATO ............................................................. 725.4.3 L’USO DI UNO “SNIFFER” .................................................................................................. 72
CAPITOLO 6: INTERFACCIAMENTO DELL'INFRASTRUTTURA CONTECNOLOGIA WEB SERVICES .......................................................................................... 73
6.1 LA MIA SCELTA: UTILIZZARE NUSOAP E CURL ............................................................ 746.1.1 INSTALLARE NUSOAP PER APPLICAZIONI SERVER-CLIENT SOAP IN PHP .................... 746.1.2 COS’È NUSOAP .............................................................................................................. 746.2 UN ESEMPIO BANALE: IL WEB SERVICES CHE CONCATENA DUE STRINGHE .................... 756.3 FUNZIONI CURL, CLIENT URL LIBRARY......................................................................... 786.4 UN ESEMPIO COMPLETO: WEB SERVICES SU HTTPS CHE INTERROGA LDAP.................. 796.4.1 LA STAMPA DI REQUEST E RESPONSE ............................................................................ 816.5 APPLICAZIONI PRATICHE REALIZZATE.............................................................................. 826.5.1 RIVISTA ON-LINE ............................................................................................................... 826.5.2 ASSISTENZA ON-LINE ....................................................................................................... 886.5.3 CONSULTAZIONE BILANCI ................................................................................................ 896.5.4 CONSULTAZIONE CODICI FISCALI .................................................................................... 906.5.5 APPLICAZIONE DA UN SERVER ESTERNO (ARUBA) ......................................................... 916.5.6 L’UTILITÀ DEL “SINGLE SIGN ON” .................................................................................... 936.5.7 IL WSDL DEL MIO WEB SERVICES .................................................................................. 936.6 USUFRUIRE DEI SERVIZI DI UN WEB SERVICES SOLO SE SI È IN POSSESSO DI UNCERTIFICATO-CLIENT VALIDO.................................................................................................. 93
7
APPENDICE A: DEFINIZIONI E ABBREVIAZIONI ........................................................ 95
APPENDICE B: SINTESI SULLA CERTIFICAZIONE DIGITALE ............................ 101
B.1 I PUNTI DA FISSARE ........................................................................................................... 102B.1.1 NECESSITÀ E SOLUZIONE .............................................................................................. 102B.1.2 CIFRATURA ..................................................................................................................... 103B.1.3 AUTENTICAZIONE ........................................................................................................... 105B.1.4 INTEROPERABILITÀ......................................................................................................... 107B.1.5 PKCS ............................................................................................................................. 107B.1.6 COMPOSIZIONE DI UN CERTIFICATO .............................................................................. 108B.1.7 REVOCA DEI CERTIFICATI .............................................................................................. 108B.1.8 COME SI OTTENGONO I CERTIFICATI ............................................................................. 109B.1.9 COME SI USANO I CERTIFICATI....................................................................................... 109B.1.10 APPLICAZIONI ............................................................................................................... 109B.2 UNA SEMPLICE OSSERVAZIONE SULLA CONNESSIONE SICURA ...................................... 110
APPENDICE C: INSTALLAZIONI E CONFIGURAZIONI ............................................ 112
C.1 INSTALLARE E CONFIGURARE MYSQL, APACHE CON SSL, PHP, LDAP.................... 113C.2 GENERAZIONE DEI CERTIFICATI...................................................................................... 120C.2.1 OSSERVAZIONI SUI CERTIFICATI.................................................................................... 120C.2.2 CREARE CERTIFICATI SSL AUTO-FIRMATI.................................................................... 121C.2.3 RILASCIARE CERTIFICATI CLIENT A SEGUITO DI UNA RICHIESTA. ................................ 122C.2.4 RICHIEDERE UN CERTIFICATO-CLIENT AD UN ENTE CERTIFICATORE UFFICIALE......... 123C.2.5 CONSIDERARE VALIDI I CERTIFICATI-CLIENT RILASCIATE DA ALTRE CA ..................... 123C.3 IL MIO WEB SERVICES....................................................................................................... 125C.3.1 INSTALLAZIONE DI NUSOAP ........................................................................................ 125C.3.2 INSTALLAZIONE DI CURL .............................................................................................. 125C.3.3 IL WSDL DEL MIO WEB SERVICES: COME UTILIZZARE IL SERVIZIO............................ 126
APPENDICE D: LE APPLICAZIONI IN PHP ................................................................... 128
D.1 I LISTATI DEI FILE IN PHP................................................................................................ 129D.1.1 VERIFICA L’ESISTENZA DI UN DOMINIO: “CHECKDOMAIN.PHP”..................................... 129D.1.2 CODICE IN PHP PER INTERROGARE IL WEB SERVICES DI GOOGLE............................ 131D.1.3 LA STAMPA DI REQUEST E RESPONSE DI UN WEB SERVICES CHE REPERISCE SULDAP INFORMAZIONI SU CERTIFICATI-CLIENT ........................................................................ 133D.2 UN SITO PER TESTARE LE APPLICAZIONI........................................................................ 135D.2.1 SCARICARE I CERTIFICATI PER I TEST ........................................................................... 135D.2.2 IL LINK AI SERVIZI OFFERTI ............................................................................................ 136D.2.3 INVOCARE IL WEB SERVICES SU HTTPS DA HTTP: “L’ESEMPIO 6.5.5” ........................ 137
CONCLUSIONI E SVILUPPI FUTURI .............................................................................. 139
8
BIBLIOGRAFIA ..................................................................................................................... 140
SOFTWARE UTILIZZATO .................................................................................................. 141
RINGRAZIAMENTI .............................................................................................................. 142
9
10
Introduzione
Questo lavoro di tesi nasce con l’intento di effettuare degli studi relativi alla
certificazione digitale e all’autenticazione su Internet.
Ha come primo scopo la realizzazione di un Web server che supporta la
connessione sicura “over https”.
Prevede uno studio sui certificati, sulle tecniche crittografiche, sulle PKI.
Si è inoltre voluto trattare un argomento fondamentale in questo campo: i servizi basati
su directory LDAP.
Il servizio basato su directory LDAP ha un’architettura client/server: uno o più
server LDAP contengono i dati che costituiscono l’albero di directory e un client può
connettersi ad un server LDAP per interrogarlo. Il server risponde inviando una risposta
e/o un puntatore verso risorse dalle quali il client potrebbe ottenere informazioni
addizionali (un altro server LDAP).
Il lavoro si completa con lo studio dei Web services, analizzando la loro
crescente importanza su Internet e la loro facilità di utilizzo e, ovviamente
realizzandone uno.
Le applicazioni realizzate hanno come obiettivo un’integrazione dei suddetti
argomenti.
11
Capitolo 1: La sicurezza
12
1.1 Introduzione
Nel contesto dell’e-commerce e della sicurezza dei sistemi informatici, si può
dare una definizione di fiducia come l’aspettativa o la convinzione che la controparte di
una transazione si comporterà in accordo ad una data politica e senza intenti criminali;
una definizione di fiducia nei sistemi, invece, potrebbe essere l’aspettativa o la
convinzione che essi siano robusti, affidabili e resistenti di fronte agli attacchi. La
fiducia è quindi essenzialmente una convinzione e si assume che sia basata
sull’evidenza, sull’esperienza e sulla percezione.
Nel mondo fisico la fiducia nelle cose e in altre persone è basata
sull’esperienza, sull’apparenza e sulle informazioni raccolte: tutti questi aspetti
evidenziano il fatto che la fiducia è un fenomeno molto soggettivo. Un’altra
caratteristica del mondo fisico è che il numero di persone con cui si può entrare
potenzialmente in relazione è limitato dalla distanza e da altri limiti fisici, mentre su
Internet il limite è rappresentato solo dal numero di persone on-line in quel momento: la
sfida è quella di riuscire a stabilire la fiducia in ambito informatico. Il partner di una
transazione può essere qualcuno che si è già conosciuto, ma nella maggior parte dei
casi sarà qualcuno totalmente sconosciuto e con il quale non si è mai interagito prima:
le decisioni sulla fiducia devono essere basate su tutte le evidenze e le informazioni
che possono essere raccolte, perciò l’atto di decidere se fidarsi o no può essere
definito come l’attività di collezionare, codificare, analizzare e presentare evidenze
rilevanti con l’obiettivo di prendere decisioni.
La chiave della sicurezza è la fiducia.
Sia per uno sviluppatore sia per un fornitore di servizio, l’obiettivo è quello di
garantire il più alto grado di sicurezza possibile, in modo tale che l’utente possa essere
sicuro del fatto che le informazioni inviate e ricevute siano e si mantengano private e
veritiere; in una forma o nell’altra, comunque, ogni sistema di sicurezza si basa sulla
fiducia tra gli utenti di quello stesso sistema. Esistono differenti forme di fiducia, a
seconda dei problemi da affrontare e dei rischi da limitare, perciò la scelta su quale
forma di fiducia applicare viene determinata da scelte politiche. In particolare esistono
due importanti forme di fiducia che gli utenti di un sistema che implementa la sicurezza
devono essere in grado di capire: fiducia-nella-terza-parte (third-party trust) o indiretta
13
e fiducia personale o diretta. Cerchiamo di capire questi concetti e fornire alcune
informazioni addizionali.
1.1.1. La fiducia nella “terza-parte”
Il concetto di fiducia indiretta (third-party trust) si riferisce ad una situazione
nella quale due individui si fidano implicitamente l’uno dell’altro, anche senza aver
precedentemente stabilito una relazione personale: in questa situazione la reciproca
fiducia può sussistere, perché entrambi conoscono direttamente il medesimo terzo
individuo e quel terzo individuo garantisce ognuno dei due sulla affidabilità dell’altro.
La fiducia-nella-terza-parte è un requisito fondamentale per qualsiasi
implementazione su larga scala di un sistema di sicurezza basato sulla crittografia a
chiave pubblica, che prevede, cioè, l’accesso alle chiavi pubbliche degli utenti. Infatti,
in una rete su larga scala, è impraticabile e irrealistico aspettarsi che ogni individuo
abbia preventivamente stabilito relazioni con tutti gli altri; inoltre, per il fatto che le
chiavi pubbliche devono essere disponibili per tutti, l’associazione tra una chiave
pubblica e una persona deve essere garantita da una terza parte assolutamente
affidabile e irreprensibile, per prevenire «travestimenti». In effetti, gli utenti si fidano
implicitamente di una qualsiasi chiave pubblica certificata dalla terza parte, perché
l’organizzazione di quest’ultima è proprietaria e mantiene in modo sicuro l’associazione
tra la certificazione e l’oggetto della fiducia. In generale, l’agente di certificazione viene
chiamato «Certification Authority» (CA): si tratta di un’entità la cui principale
responsabilità è quella di certificare l’autenticità degli utenti e può essere vista come
analoga allo Stato che emette passaporti e carte di identità (identità cartacee). Ogni
altro Stato che si fidi dell’autorità del primo si fiderà anche del passaporto dell’utente:
questo è un buon esempio di fiducia-nella-terza-parte. Similmente ad un passaporto,
l’identità elettronica di un utente, emessa per lui da una CA, è la prova che l’utente ha
del fatto che una CA si fida di lui; per questo, attraverso la fiducia-nella-terza-parte,
chiunque ritenga la CA affidabile dovrebbe anche fidarsi dell’utente, per una sorta di
proprietà transitiva.
Sia l’ufficio di emissione passaporti sia la CA sono una combinazione di
strutture fisiche di controllo: nel caso dell’ufficio passaporti ci sono una serie di controlli
fissati dall’ordinamento giudiziario, che stabiliscono quali persone sono cittadini
14
rispettabili e le modalità per ottenere un passaporto; similmente, una CA può essere
pensata come un gruppo di persone facenti parte di un’organizzazione, le quali
determinano le politiche di sicurezza sulla rete e decidono quali individui possono
ricevere identità elettroniche, cioè certificati.
1.1.2. Fiducia senza intermediazioni
Il concetto di fiducia diretta si riferisce ad una situazione nella quale due
individui hanno stabilito una relazione di fiducia direttamente tra loro, senza
intermediazioni. Mentre la fiducia-nella-terza-parte permette agli individui di fidarsi
implicitamente l’uno dell’altro senza prima aver stabilito alcuna relazione personale, la
fiducia diretta si basa sulla conoscenza reciproca, prima dello scambio di informazioni
delicate. Per la sicurezza sulla rete è richiesta la fiducia diretta quando individui
provenienti da domini separati si scambiano informazioni sulle chiavi per rendere
sicure le comunicazioni, poiché le rispettive CA non hanno stabilito una relazione di
fiducia attraverso una certificazione incrociata. Senza una fiducia diretta, in questo
scenario lo scambio di chiavi non avrebbe alcun valore, perché l’informazione sulla
chiave stessa potrebbe essere non affidabile (non la chiave in sé, ma i dati del
proprietario).
Quando si applica la fiducia diretta per rendere sicure le comunicazioni,
solamente la responsabilità di ognuna delle parti può dare una qualche garanzia: se si
sceglie questa strada significa, probabilmente, che ognuna delle parti ritiene che la
fiducia personale sia sufficiente per il tipo di operazioni che si stanno portando avanti.
Comunque, quando è presente la fiducia diretta, lo scambio di chiavi tra
individui con un rapporto personale fornisce un potente meccanismo per assicurare
comunicazioni sicure.
1.1.3. Validità dei certificati
Il certificato di un utente della rete è l’equivalente elettronico del suo passaporto
e, in quanto tale, un certificato contiene informazioni sicure che possono essere usate
per verificare l’identità del proprietario: per esempio il certificato ne contiene il nome,
15
ma soprattutto la chiave pubblica, che rappresenta la parte critica di informazione per
quanto riguarda la sicurezza.
Volendo affrontare il problema in termini di fiducia, ci sono due aspetti centrali in
relazione ai certificati.
- Il primo riguarda la credibilità dell’informazione contenuta nel certificato. Come
si può pretendere che una persona si fidi del fatto che il nome e la chiave pubblica
contenuti in un certificato appartengano veramente a chi dichiara di esserne il
proprietario? Come si può essere sicuri che il certificato non sia stato falsificato? Senza
questo tipo di credibilità, la crittografia a chiave pubblica crollerebbe come un castello
di carte, perché nessuno sarebbe sicuro di crittografare dati per la persona giusta,
mentre un certificato sarebbe completamente inutile se non si potesse associarlo ad un
preciso individuo. Allora, per stabilire un rapporto di fiducia, deve esserci un
intermediario, la CA, che appone la propria firma digitale al certificato, garantendo così
l’integrità, l’autenticazione e il non ripudio dello stesso.
- Dopo aver appurato che un certificato è reso credibile dalla firma digitale della
CA, il secondo aspetto che porta a fidarsi di un certificato riguarda il lecito dubbio sulla
credibilità della CA in se stessa. Se, come prima, si mette in relazione di analogia
questo scenario con quello del mondo burocratico e giuridico, il corretto parallelo si
potrebbe fare su fino a che punto ci si può fidare dell’ufficio che ha emesso il
passaporto. Si prenda l’esempio di un cittadino che entra nello Stato A presentando un
passaporto apparentemente valido emesso da un ufficio dello Stato B: gli ufficiali dello
Stato A ospite dovranno valutare la credibilità dell’ufficio passaporti dello Stato B,
facendo riferimento ad una lista correntemente valida di Stati affidabili, redatta da un
gruppo di sorveglianza a livello superiore, che rientri, comunque, nei limiti di controllo
dell’agenzia.
L’analogia con la lista di Stati affidabili, nel contesto della sicurezza delle reti, è
riferita come «dominio di certificazione incrociata tra CA». La certificazione incrociata è
un processo grazie al quale due CA si scambiano, in modalità sicura, informazioni sulle
reciproche chiavi, in modo tale che ognuna delle due possa effettivamente certificare la
credibilità della chiave dell’altra. Essenzialmente, la certificazione incrociata è una
forma estesa di fiducia-nella-terza-parte, nella quale gli utenti appartenenti ad una rete
16
nel dominio di una CA si fidano implicitamente di tutti gli utenti appartenenti ai domini di
altre CA certificate in modo incrociato con la propria CA.
Da una prospettiva tecnica, la certificazione incrociata coinvolge la creazione di
certificati incrociati tra due CA: quando la CA X e la CA Y si certificano l’un l’altra, in
modo incrociato, la CA X crea e firma un certificato contenente la chiave pubblica della
CA Y, e viceversa. Di conseguenza, gli utenti appartenenti ad entrambi i domini sono
garantiti sul fatto che le relative CA si fidano l’una dell’altra; per questo gli utenti di un
dominio si possono fidare di quelli dell’altro attraverso una fiducia-nella-terza-parte
estesa.
Ci sono, naturalmente, molti più accordi da prendere nella certificazione
incrociata tra CA, piuttosto che nei dettagli tecnici che hanno a che fare con lo scambio
sicuro di chiavi ed informazioni analoghe tra utente e CA (cosa, in sé, abbastanza
facile da realizzare). In quanto la certificazione incrociata estende la fiducia-nella-terza-
parte, è importante, per ogni dominio CA, essere completamente sicuro delle strutture
di sicurezza degli altri partner. Riprendendo un’ennesima volta il parallelo del
passaporto, sarebbe inverosimile che uno Stato dichiarasse di avere fiducia nel
passaporto emesso da un altro Stato senza prima esaminarne a fondo la politica
adottata per creare e distribuire passaporti ai cittadini. Per esempio, prima di stabilire
un rapporto di fiducia, ogni Stato vorrà sicuramente capire in modo dettagliato il
processo con il quale la controparte verifica l’identità di un cittadino prima di conferirgli
un passaporto. Analogamente si presentano le cose quando si creano certificazioni
incrociate tra diversi domini CA: per esempio, prima di procedere, entrambi i domini CA
vorranno conoscere le altrui politiche di sicurezza, specialmente le modalità di accesso
alle funzioni di manipolazione della sicurezza all’interno del dominio. È anche
verosimile che gli accordi legali vengano firmati dai rappresentanti di entrambi i domini:
questi accordi dovrebbero precisare le politiche di sicurezza richieste in entrambi i
domini e fornire una garanzia controfirmata che le direttive saranno messe in pratica.
1.1.4. Certification Authority
Una CA può anche emettere un certificato per un’altra CA.
17
Nell’analisi di un particolare certificato, può sorgere il bisogno di esaminare
anche il certificato dell’emissario, eventualmente in modo ricorsivo per ogni CA
«madre», fino a raggiungere quella in cui riporre completa fiducia: si può anche
scegliere di fidarsi solamente di certificati con una catena limitata di emissari, per
ridurre il rischio di incontrare un anello debole (tutto ciò è generalmente trasparente
all’utente finale che, nella maggioranza dei casi, non avrebbe la preparazione per
comprendere ciò che avviene). Ogni certificato richiede un emissario che asserisca la
validità dell’identità del possessore del certificato stesso e ogni emissario richiede un
altro emissario che asserisca l’affidabilità del primo, fino ad arrivare al livello di CA che
ispiri fiducia, oppure al livello root, cioè alla radice dell’albero delle CA (possono
esistere diverse root per diverse strutture ramificate di certificati).
Qui sorge un problema: chi garantisce la validità del certificato della CA al livello
root, che per definizione non ha emissari? In questo caso particolare il certificato è
auto-assegnato, in modo tale che l’emissario del certificato ne sia anche il soggetto.
Come risultato vediamo che l’utente finale deve porre una grande attenzione nello
scegliere un certificato auto-assegnato, ma comunque la pubblicazione in grande stile
e con molta pubblicità della chiave pubblica della CA di livello root dovrebbe ridurre il
rischio: sarebbe facilissimo individuare un impostore che pubblicizzasse la propria
chiave proclamando di essere una CA a livello root.
Fondare una CA, anche non a livello di root, rappresenta comunque una grossa
responsabilità, che richiede una struttura interna estremamente solida dal punto di
vista amministrativo, tecnico e gestionale; le CA non hanno solamente il compito di
emettere certificati, ma anche quello di gestirli: questo significa anche decidere per
quanto tempo i certificati saranno validi, significa doverli rinnovare e mantenere delle
liste di certificati già emessi, ma non più validi (Certificate Revocation List, o CRL). Per
capire la funzione delle CRL, si provi ad immaginare un generico client, titolare di un
certificato in quanto impiegato di un’azienda; si immagini anche che questo stesso
certificato debba essere revocato quando l’impiegato lascia la compagnia: poiché i
certificati sono documenti che vengono distribuiti pubblicamente, non è possibile
stabilire, a partire dal certificato in sé, se questo sia stato revocato oppure no. Per
essere sicuri della validità del certificato, quindi, è necessario contattare la CA che lo
ha emesso, per procedere con il controllo delle CRL.
Si è parlato tanto e tanto si parlerà di certificati: a titolo di esempio si presenta
qui un esempio di certificato crittografato, per avere almeno un’idea del suo aspetto:
18
-----BEGIN CERTIFICATE-----
MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUGA
1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTE
VMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBzbmFrZW9pb
C5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzELMAkGA1UEB
hMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjE
XMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNlcnZlciBUZWFtMR
kwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcNAQkBFhB3d3dAc25ha2
VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDH9Ge/s2zcH+da+rPTx
/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8bvKR+yy5DGQiijsH1D/j8HlGE+q4TZ
8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaalWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2D
LbCTzLZyPwIDAQABoyYwJDAPBgNVHRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQ
QEAwIAQDANBgkqhkiG9w0BAQQFAAOBgQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1
v1KL8mQR+KFjghCrtpqaztZqcDt2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4
LuKMJX15hxBam7dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
-----END CERTIFICATE-----
1.2. La sicurezza
Poniamo il caso di un consumatore che desideri comprare qualcosa su Internet,
oppure quello di un uomo d’affari che cerca di vendere qualcosa su Internet : questi
due casi estremi enfatizzano la necessità di utilizzare comunicazioni sicure. A questo
scopo viene usata, ormai da qualche anno, la tecnologia Secure Sockets Layer (SSL)
per garantire una via sicura tramite la quale trasmettere informazioni delicate, come
quelle riguardanti acquisti con carta di credito, operazioni di borsa, invio e ricezione di
e-mail, trasmissione dei risultati di esami medici ed altre informazioni strettamente
personali.
In poche parole, SSL è una tecnologia che permette il trasferimento sicuro di
informazioni su Internet: consiste in un software installato su browser e server, che si
può facilmente ottenere sottoscrivendosi ad un Secured Service Provider (SSP) come
SSL.com, VeriSign, Entrust, Infinite Technologies, oppure ottenendo da esso un
Seller’s Certificate ed installandolo su un server sicuro preesistente; probabilmente,
comunque, una parte di esso è già contenuta sia nel Web browser sia nel Web server,
a priori: infatti, tutti i maggiori browser e server sono abilitati alla gestione di SSL.
19
La tecnologia SSL è stata sviluppata dalla Netscape Communications
Corporation ed è diventata presto la modalità industriale standard per proteggere le
comunicazioni sul Web: si tratta di un livello di protocollo che può essere posizionato
tra un protocollo di rete affidabile e connection oriented (ad esempio TCP/IP) ed un
protocollo a livello di applicazione (ad esempio HTTP): SSL garantisce una
comunicazione sicura tra client e server, tramite una mutua autenticazione, con l’uso
delle firme digitali per l’integrità e della crittografia per la privacy; è progettato per
supportare una rosa di specifici algoritmi crittografici, sia per il sunto matematico
(digest) sia per le firme digitali, permettendo di sceglierne di particolari per server
specifici, ma anche di supportare eventuali nuovi algoritmi: le varie decisioni su quali
algoritmi utilizzare sono prese durante la negoziazione tra il client e il server all’inizio
della sessione sicura.
Un protocollo è, essenzialmente, un insieme di regole e procedure ed, in quanto
tale, SSL applica ad un messaggio una serie di operazioni che lo manipolano
facendogli apparentemente perdere significato: queste operazioni sono portate avanti
in modo che il messaggio non possa essere letto mentre viene trasferito, o meglio: se
anche fosse intercettato durante la trasmissione, risulterebbe completamente
incomprensibile per chiunque, escluso il reale destinatario. Quando il messaggio
raggiunge il ricevente giusto, SSL si incarica di riportarlo al suo aspetto originale,
controllando che provenga dal mittente corretto (autenticazione) e che non sia stato
modificato nel frattempo (integrità).
1.2.1. Concetti base di un servizio di sicurezza
Sono quattro i concetti base che un servizio di sicurezza deve rispettare:
- Privacy: la privacy assicura che solamente il mittente ed il ricevente di un
messaggio crittografato possano leggerne i contenuti; per garantire la privacy,
una soluzione sicura deve, quindi, fare in modo che nessun altro possa vedere,
accedere o altrimenti usare le informazioni private trasmesse tramite Internet,
che potrebbero essere indirizzi, numeri di carte di credito, numeri di telefono,
ecc.
20
- Integrità: l’integrità assicura la rilevazione di qualsiasi cambiamento nel
contenuto di un messaggio, tra l’istante in cui viene inviato e l’istante in cui
viene ricevuto: per esempio, quando un utente ordina alla propria banca di
trasferire $ 1000 da un conto ad un altro, l’integrità garantisce che i numeri di
conto e l’ammontare della somma non possano essere alterati senza che la
banca o l’utente se ne accorgano; se il messaggio dovesse essere alterato in
un qualsiasi modo durante la trasmissione, il sistema di sicurezza deve
assolutamente avere un modo per scoprire e notificare l’alterazione: in molti
sistemi, quando viene riscontrata una alterazione, il sistema di ricezione impone
la ritrasmissione del messaggio.
- Autenticazione : l’autenticazione assicura che tutte le entità coinvolte in una
comunicazione siano in effetti chi dichiarano di essere: l’autenticazione del
server dà modo agli utenti di verificare di essere effettivamente in
comunicazione con il sito Web con cui sono convinti di essere connessi, mentre
l’autenticazione del client assicura che quest’ultimo sia proprio chi dichiara di
essere. Anche nel mondo reale esistono esempi di autenticazione: la
presentazione di una patente di guida o di una carta di identità garantisce che
l’acquirente che firma un assegno è proprio la persona nominata su
quell’assegno, mentre la presentazione di un distintivo o di una tessera di
riconoscimento dell’azienda dei telefoni, con annessa foto identificativa,
garantisce che la persona che si presenta alla porta è veramente l’addetto del
telefono…e questi sono solo alcuni dei tanti possibili esempi.
- Non ripudio (o non disconoscimento): il non ripudio fornisce un modo per
garantire che una parte coinvolta in una transazione non possa poi in seguito
falsamente dichiarare di non aver mai partecipato alla transazione stessa; nel
mondo reale questa funzione è svolta dalle firme apposte a mano in calce ai
documenti: quando un acquirente stacca un assegno, presentando la patente di
guida o la carta di identità assicura la controparte sulla propria identità
(autenticazione), mentre la firma sull’assegno assicura per il futuro che il
firmatario fosse di fatto presente e acconsentisse sull’importo e sul destinatario
dell’assegno stesso (non ripudio).
21
Nel mondo Internet, il protocollo SSL, i certificati digitali e la coppia
username/password sono usati in concomitanza per fornire tutti e quattro i livelli di
garanzia sopra citati.
1.2.2. Tecniche crittografiche
SSL comprende diverse tecniche crittografiche, qui elencate per sommi capi e
poi spiegate in modo approfondito.
- Crittografia con coppia di chiavi: la crittografia con coppia di chiavi (pubblica e
privata) è il metodo crittografico cruciale di SSL: utilizza due chiavi e sofisticati
algoritmi matematici per convertire un testo in chiaro in una serie di dati
crittografati e viceversa. La coppia di chiavi consiste in una chiave pubblica e
registrata, disponibile per chiunque, e in una chiave privata tenuta
rigorosamente segreta dal suo proprietario: un messaggio crittografato con la
chiave pubblica può essere decrittografato solamente da qualcuno in possesso
della corrispondente chiave privata (questo è fondamentale per la privacy);
analogamente, un messaggio crittografato con la chiave privata può essere
decrittografato solamente da qualcuno in possesso della corrispondente chiave
pubblica (questo è fondamentale per l’autenticazione con firma digitale). La
crittografia con chiave pubblica usa algoritmi molto avanzati per crittografare
una piccola quantità di informazioni, mentre non è applicabile per quantità di
dati più rilevanti.
- Algoritmi di bulk encryption: esistono, per contro, algoritmi di bulk encryption
(bulk = massa, grande quantità) che usano solamente una chiave segreta e
condivisa (bulk key) tra i due comunicanti per crittografare i messaggi: questi
algoritmi sono estremamente difficili da decodificare quando la bulk key
contiene un elevato numero di bit.
- Combinazione delle due tecniche : SSL utilizza, allora, la crittografia con coppia
di chiavi per scambiare tra il client e il server la bulk key, nelle primissime fasi di
una conversazione sicura in Internet, assicurando così che suddetta chiave
22
rimanga segreta per tutta la durata della conversazione; poi si serve di questa
chiave per crittografare la parte veramente sostanziale dei dati, cioè le
informazioni che rivestono importanza per i due comunicanti e che devono
essere scambiate. SSL utilizza la crittografia con coppia di chiavi e gli algoritmi
di bulk encryption per garantire la privacy in Internet.
- Algoritmi di hashing : SSL usa algoritmi di hashing per creare una piccola
«impronta digitale», matematicamente generata, di un messaggio: se una
qualsiasi parte del messaggio viene alterata, la sua impronta nuovamente
generata a partire dal messaggio ricevuto non coinciderà più con la prima,
quando il messaggio verrà controllato dal ricevitore: in questo caso viene
richiesto al mittente la ritrasmissione. Questo è il modo con cui SSL garantisce
l’integrità.
1.2.2.1. La crittografia simmetrica
La crittografia è la scienza di occultare le informazioni.
Per gran parte della storia dell’uomo è esistita solo una forma molto pratica e
semplice di crittografia: la crittografia simmetrica. Un esempio di crittografia simmetrica
è quella usata da Giulio Cesare, che spostava semplicemente in avanti ogni lettera di
un messaggio di un certo numero di lettere, secondo l’alfabeto. Per esempio,
spostando ogni lettera di tre posti in avanti, potremmo cifrare un messaggio in questo
modo:
«Questo è il messaggio», ottenendo: «Tahvzr h no phvvdllnr».
In questo caso, il testo «Tahvzr h no phvvdllnr» viene chiamato testo cifrato e il
numero 3 (il numero di posti di cui ogni lettera è stata spostata) è la chiave: chi riceve il
testo cifrato deve conoscere la chiave, cioè il numero 3 (per sapere di dover spostare
di 3 posti indietro le lettere).
Questo tipo di cifratura è ovviamente molto debole (ci sono solo 26 possibili
chiavi), ma è molto utile per spiegare a cosa assomiglia una cifratura simmetrica: è
simmetrica perché chiunque conosca la chiave per crittografare (muovere avanti le
lettere di tre posti) conosce anche la chiave per decrittografare (spostare indietro le
lettere di tre posti) e viceversa; tutte le cifrature simmetriche hanno questa proprietà,
23
anche se con quelle attuali si ha la possibilità di scegliere tra molte più chiavi di quante
ne avesse a disposizione Giulio Cesare.
1.2.2.2. La crittografia asimmetrica
Fino a poco tempo fa, si era soliti usare questa tecnica di crittografia simmetrica
per rendere sicura la trasmissione delle informazioni attraverso la rete pubblica, ma il
problema consisteva nel fatto che la chiave, per essere nota ad entrambi, doveva
essere trasmessa dall’uno all’altro in una trasmissione separata, rendendola
vulnerabile al furto durante il passaggio. Durante la seconda guerra mondiale, le spie e
le loro basi dovevano condividere un libro di codici; più tardi gli scienziati svilupparono
hardware specializzato che poteva operare all’interno di scatole a prova di
intromissione, spostato da luogo a luogo da corrieri fidati. Una volta che entrambe le
parti conoscevano la chiave, potevano comunicare in modo sicuro ogni qualvolta lo
desiderassero, ma stabilire la chiave all’inizio era dispendioso e rischioso. La
crittografia simmetrica rendeva possibile una comunicazione sicura tra persone che
veramente ne avessero le possibilità economiche e i mezzi (i governi, i militari, grosse
istituzioni finanziarie), ma non sarebbe mai diventata abbastanza semplice da utilizzare
per le persone comuni.
Più in particolare, supponendo di avere solo questo metodo di crittografia
simmetrica, in cui il client e il server conoscono entrambi la chiave A, sorgono
numerosi altri problemi: oltre al fatto che il client deve trovare un modo sicuro di
trasmettere la sua chiave segreta al server (se la chiave segreta venisse intercettata,
tutte le trasmissioni del client sarebbero compromesse), il client deve a maggior
ragione potersi fidare del server, per il fatto di usare sempre la medesima chiave: se il
server fa il doppio gioco, potrebbe dare la chiave segreta a qualcun altro, leggere altri
messaggi privati del client non indirizzati a lui dopo averli intercettati e addirittura
spacciarsi per il client! Inoltre, nel caso di un’organizzazione con persone che hanno
bisogno di scambiarsi messaggi segreti, ci sarebbe bisogno di tenere memorizzate
migliaia (per non dire milioni) di chiavi segrete, oppure utilizzarne meno (tipo
passpartout), compromettendo la sicurezza.
Negli ultimi anni’70, tre accademici di Stanford ebbero una brillante idea:
Whitfield Diffie, Martin Hellman e Ralph Merkle si chiesero cosa sarebbe successo se il
24
fatto di conoscere la chiave per crittografare non significasse conoscere
automaticamente la chiave per decrittografare. Cosa succederebbe se fosse così
difficile trovare la chiave per decrittografare a partire da quella per crittografare da
poter tranquillamente pubblicare quest’ultima di fronte al mondo intero? In questo
modo chiunque voglia comunicare con una persona in particolare potrebbe cercare la
sua chiave pubblica, con essa crittografare il messaggio e quindi inviarlo: solamente
quella persona conoscerebbe la corrispondente chiave per decrittografare e nessun
altro potrebbe leggere il messaggio, anche conoscendo la chiave pubblica. Questa fu
la geniale idea della crittografia a chiave pubblica, basata essenzialmente su una
crittografia ASIMMETRICA.
Certo che avere l’idea è una cosa, realizzarla nella pratica è un’altra: Diffie,
Hellman e Merkle cercarono di realizzare questo sogno con un metodo, chiamato
«Diffie-Hellman key agreement», attraverso il quale due persone potevano mettersi
d’accordo su una chiave simmetrica condivisa e segreta usando solo messaggi
pubblici, ma non si trattava della crittografia a chiave pubblica, che è tipicamente
asimmetrica.
L’invenzione di un vero e proprio sistema di crittografia asimmetrica a chiave
pubblica si deve a Ron Rivest, Leonard Adelman e Adi Shamir, che lavoravano al MIT
(Massachussets Institute of Technology): il loro sistema, chiamato «criptosistema
RSA» (prima fu messo il nome di Rivest, perché fu lui a colpire nel segno), era basato
sulla difficoltà nel trovare i divisori, cioè i due fattori primi, di numeri molto grandi (il
processo è noto come «fattorizzazione»). Questo metodo non solo permette di inviare
messaggi crittografati, ma possiede anche un’altra importante proprietà: una persona,
crittografando un messaggio con la propria chiave privata, può provare che un dato
messaggio proviene proprio da lui: questo è il concetto che sta alla base della «firma
digitale», che garantisce un modo per stabilire l’integrità di quanto inviato in un mondo
dove vengono scambiati solo bit e byte.
1.2.2.3. L’utilizzo pratico della crittografia
Con la crittografia a chiave pubblica vengono usate due chiavi separate per
crittografare e decrittografare un messaggio, in modo tale che nient’altro che messaggi
crittografati debbano attraversare la rete: la crittografia asimmetrica è utilizzata,
25
appunto, per risolvere il problema di consegnare la bulk key (usata nella crittografia
simmetrica) in modalità sicura. Per fare questo si cripta la bulk key con la chiave
pubblica del server al quale si vuole inviare il messaggio; dal momento che solo lui
conosce la corrispondente chiave privata e che solamente con la chiave privata si può
decriptare il messaggio, solamente quel server potrà ricavare la bulk key ed utilizzarla
per decriptare le successive trasmissioni.
Perché bisogna usare questa combinazione di crittografia asimmetrica e simmetrica?
La ragione è semplice: la crittografia a chiave pubblica è lenta ed è applicabile
solamente per crittografare piccole quantità di informazioni (la chiave simmetrica o bulk
key, per l’appunto), mentre la crittografia simmetrica è molto più veloce ed è adatta per
crittografare grandi quantità di dati.
1.2.3. La firma digitale
Una volta che si sia stabilita una connessione sicura tra due parti, qualsiasi
messaggio ricevuto da un’entità esterna alla connessione sicura viene rigettato, oppure
l’utente viene avvertito. SSL realizza ciò creando una specie di «impronta digitale»
univoca del messaggio (chiamata anche riassunto o digest) per entrambe le parti,
attaccandola in allegato ad ogni messaggio.
Vediamo meglio questo processo di firma digitale.
Prima di tutto, attraverso una one-way function, si realizza un riassunto
«matematico» del messaggio (chiamato anche «hash code» o «message digest) :se
anche un solo bit del messaggio dovesse variare, l’hash code cambierebbe in modo
drammatico. Più in particolare, l’hash code è la rappresentazione di messaggi lunghi e
di dimensione variabile attraverso loro riassunti più corti e con lunghezza fissa: gli
algoritmi di digest sono stati progettati per produrre riassunti univoci per ogni
messaggio, ognuno dei quali è strutturato in modo da rendere estremamente difficile
risalire al messaggio originale. È anche pressoché impossibile trovare due messaggi
differenti che generino lo stesso digest: questo fatto elimina la possibilità di sostituire
un messaggio con un altro mantenendo lo stesso digest.
Il secondo passo nel creare una firma digitale consiste nel crittografare l’hash
code insieme ad altre informazioni (come ad esempio un numero di sequenza), con la
chiave privata del mittente.
26
Anche se chiunque può decrittografare la firma usando la corrispondente chiave
pubblica, solamente il firmatario conosce la chiave privata: questo significa che
solamente lui può aver firmato il digest. Inoltre, includendo il digest nella firma,
quest’ultima risulterà valida solamente per quel messaggio: in questo modo si assicura
anche l’integrità del messaggio, in quanto nessun altro può cambiare il messaggio e
firmarlo nuovamente (con una chiave privata a lui ignota); inoltre, per essere tutelati
contro l’intercettazione e il riuso della firma da parte di un intruso in un istante
successivo, la firma contiene un numero di sequenza unico. Tutto questo meccanismo
protegge il server da un’eventuale falsa dichiarazione del client, che potrebbe dire di
non aver mai mandato il messaggio (non ripudio).
Il terzo passo consiste nell’appendere la firma digitale al messaggio, che si
comporta così alla stregua di una firma manuale in calce ad un assegno.
Infine il messaggio con apposta la firma digitale viene crittografato con la bulk
key , si unisce la bulk key crittografata con la chiave pubblica del server e si spedisce
il tutto.
Il ricevente del messaggio segue questi diversi passi a ritroso, per leggere il
messaggio: nella fase di apertura ricava, utilizzando la propria chiave privata, la bulk
key ; poi usa la bulk key per decriptare il resto del messaggio, che contiene anche la
firma digitale .
A questo punto, SSL verifica l’integrità del messaggio procedendo con un
ulteriore passo di autenticazione: verifica la firma digitale decrittografandola con la
chiave pubblica del mittente (è evidente che il mittente deve essere certificato, per
possedere una chiave pubblica), mettendo così in chiaro il ; allo stesso tempo viene
creato un nuovo hash code a partire dal messaggio ricevuto, posto poi a confronto con
l’originale decrittografato .
Se tra i due c’è un match, cioè se coincidono perfettamente, allora il ricevente
ha la conferma che il messaggio non è stato alterato, ma sa anche qualcosa in più:
solamente il mittente certificato con cui è convinto di parlare può aver inviato il
messaggio, perché solamente lui possiede la chiave privata che ha firmato l’hash code
originale, perciò la firma digitale garantisce sia l’integrità del messaggio, sia l’identità
del mittente, quindi l’autenticazione e il non ripudio. Se tra i due digest, invece, non si
verifica un match, SSL comprende che il messaggio è stato alterato e ne richiede la
ritrasmissione.
27
Una delle applicazioni più utili della firma digitale, a parte l’autenticazione dei
messaggi veri e propri, riguarda la conferma delle chiavi pubbliche di terze persone: la
crittografia a chiave pubblica, infatti, lascia scoperto un possibile punto debole. Nel
momento in cui si vuole comunicare con un particolare Web server, bisogna
determinarne la chiave pubblica e il modo migliore per ottenerla sarebbe quella di
ottenerla direttamente da lui: la maggioranza delle volte, però, questo non è possibile e
si è costretti ad ottenerla attraverso la rete.
Come abbiamo visto il sistema a doppia chiave risolve ogni problema rispetto
ad un’eventuale intercettazione della chiave lungo il tragitto, ma presta il fianco alla
possibilità che un terzo individuo malizioso, conoscendo la volontà di comunicare con
quel particolare Web server, si spacci per lui e spedisca una chiave pubblica
contraffatta. Se si cade nel tranello e si utilizza quella chiave, i successivi messaggi
saranno leggibili non dal Web server con cui si è convinti di comunicare, bensì dal
terzo individuo, titolare della vera corrispondente chiave segreta: quest’ultimo potrà poi
perfezionare il suo inganno rispedendo a sua volta tutti i messaggi al Web server, che
in questo modo non si accorgerà nemmeno dell’esistenza di una tappa in più lungo la
strada. Questo problema (chiamato problema «dell’uomo nel mezzo») è assolutamente
concreto e reale e la soluzione sta nel chiedere e ottenere che ogni nuova chiave
pubblica sia firmata da qualcuno che si conosce e di cui si dispone già con certezza
della rispettiva chiave pubblica. Se si è costretti a ottenere la chiave del Web server via
rete, si avrà cura di verificare che essa sia firmata da una CA che abbia magari contatti
quotidiani con il Web server stesso. Siccome si hanno tutte le ragioni per potersi fidare
di tale CA, si può dire di possederne con certezza la vera chiave pubblica. Con questa
chiave si può verificare la firma che la CA ha apposto sulla chiave pubblica del Web
server, potendo quindi verificare che la CA, considerata affidabile, garantisca che la
chiave pubblica appena arrivata sia effettivamente quella del Web server. A questo
punto è evidente che la certificazione delle chiavi può diventare rapidamente molto
complessa, consentendo, da un unico punto di partenza sicuro, di estendere la rete di
contatti a dismisura, comprendendo anche entità che non si incontreranno mai
direttamente. Con questa caratteristica il cerchio viene chiuso e diventa veramente
possibile stabilire un’infrastruttura comunicativa priva di contatti fisici che sia
doppiamente sicura, sia dal punto di vista della possibilità di leggere il contenuto della
comunicazione, sia da quello di poterne garantire la provenienza
28
1.2.4. Distribuzione sicura di certificati digitali
Dal momento che chiunque può generare coppie di chiavi (tutto sommato si
tratta di calcolare il prodotto di due numeri primi estremamente elevati: la sicurezza
deriva dal fatto che è estremamente difficile riuscire a ottenere i due fattori partendo dal
loro prodotto) sarebbe, in linea teorica, possibile per un individuo malizioso costruire un
sito Web, spacciarlo per quello, ad esempio, di una banca e quindi falsificare le
informazioni contenute in una transazione, fornendo una chiave pubblica agli utenti, i
quali sarebbero convinti di dialogare in modalità sicura con una banca, mentre in realtà
stanno sì comunicando in modo sicuro, ma con un individuo pericoloso: certamente
nessuno potrebbe intercettare le conversazioni che intercorrono tra loro, ma i clienti si
troverebbero nelle grinfie di una persona disonesta, alla quale, in buona fede,
comunicherebbero informazioni private e preziose.
Per prevenire questo tipo di frodi vengono utilizzati i certificati digitali, che
rappresentano un modo autenticato di distribuire le chiavi pubbliche (non quelle
private!): i certificati digitali sono usati per autenticare le parti di una conversazione in
Internet, in modo tale che entrambi (l’utente e il fornitore di contenuto) sappiano per
certo con chi ognuno di loro sta dialogando in quel momento. In particolare, SSL usa i
certificati digitali per collegare insieme importanti informazioni che servono per
identificare un client o un server (il nome dell’organizzazione, il suo indirizzo di email, il
paese di appartenenza, l’organizzazione che ha emesso il certificato, ecc.). Esistono
due tipi differenti di certificati digitali, presentati qui di seguito.
1) I certificati root:
le CA sono entità rispettabili, fidate e indipendenti che emettono chiavi e certificati in
favore di individui e società; esse utilizzano metodi molto seri e rigorosi, per sondare in
profondità le realtà che si trovano di fronte: avendo la responsabilità di garantire la
veridicità di quanto dichiarano i richiedenti il certificato, è loro preciso dovere capire se i
richiedenti sono veramente chi dichiarano di essere e sono, perciò, degni di fiducia. Le
CA rendono disponibili i propri certificati root per il download da parte di chiunque
(alcuni gratuiti di tipo «trial», cioè di prova, altri a pagamento), in modo che chiunque
voglia comunicare con loro in modo sicuro possa farlo; un certo numero di compagnie,
come VeriSign, Thawte, SSL.com o RSA Security, si sono pubblicamente proposte in
29
qualità di CA, fornendo servizi come la verifica e il trattamento delle richieste, e
l’emissione e la buona gestione dei certificati. È possibile per chiunque creare una
propria CA personale: anche se questo può risultare estremamente rischioso e
oneroso in Internet, nell’ambito di una rete Intranet potrebbe risultare utile, perché, in
questo ambiente ristretto, sarebbe più facile per l’organizzazione verificare l’identità
degli individui e dei server.
2) I certificati server e client :
i certificati server sono usati per autenticare un Web server (è facile trovare queste
realtà, in Internet), mentre i certificati client o personali sono usati per autenticare
l’identità di un singolo utente (per loro natura sono molto rari); entrambi i certificati
includono quattro componenti base:
- la chiave pubblica;
- informazioni che legano la chiave pubblica al suo possessore;
- informazioni su chi ha emesso il certificato;
- la firma digitale di chi ha emesso il certificato.
Più in particolare i campi di informazione tipici includono:
- il nome del possessore del certificato;
- l’indirizzo email del possessore del certificato;
- il numero di telefono del possessore del certificato;
- il nome della compagnia per cui il possessore del certificato lavora;
- le medesime informazioni per chi ha emesso il certificato;
- un identificatore univoco per il certificato (serial number);
- un indicatore del livello di fiducia che può essere posto nel certificato;
- la data di emissione del certificato
- a data di scadenza del certificato.
Ci si riferisce alle informazioni raccolte su un qualsiasi individuo come al suo
«Distinguished Name», o DN, perciò un certificato contiene due DN: quello del
possessore e quello dell’emissario del certificato. La cosa più importante, però, è che i
certificati server e client sono essi stessi crittografati con la CHIAVE PRIVATA della CA
30
e in questo modo si ha la sicurezza che sia veramente stata la CA ad emettere quel
certificato: quando un Web browser richiede di avere una conversazione sicura con un
Web server, il server spedisce al browser il proprio certificato (che contiene la propria
chiave pubblica) crittografato con la chiave privata di una determinata CA (è
praticamente lo stesso certificato che la CA ha inviato al Web server al momento della
certificazione); allora il browser autentica il Web server confermando che una CA fidata
ha crittografato il certificato CON LA PROPRIA CHIAVE PRIVATA E SEGRETA,
decrittografandolo con la chiave pubblica della CA stessa, pubblicamente disponibile e
da esso generalmente già conosciuta. A questo punto il browser usa la chiave pubblica
del Web server riposta nel certificato inviato per crittografare la bulk key (generata ex
novo tutte le volte che si stabilisce una nuova sessione sicura) da mandare e
condividere con il Web server: questa nuova chiave è ora usata per crittografare il
resto della conversazione. Usando il certificato server, il Web server e il browser
possono intrattenere una conversazione sicura privata e autenticata, con integrità
garantita: se ogni parte possiede un certificato che valida l’identità dell’altro, conferma
la sua chiave pubblica ed è «firmato» (=«crittografato con la chiave privata di …») da
un’agenzia fidata, allora entrambi saranno sicuri di comunicare con chi sono convinti di
star comunicando
1.2.5. Richiesta di un certificato digitale
Per ottenere un certificato si deve costruirne una richiesta, che contenga tutte le
informazioni personali che appariranno nel certificato stesso: esistono due tipi di
richieste di certificato largamente usate, note come PKCS#10 e RFC 2511.
Una richiesta di certificato PKCS#10 (di gran lunga la più semplice) consiste
internamente di quattro campi:
- un numero di versione (1-3);
- il nome dell’utente finale (DN o Distinguished Name);
- la sua chiave pubblica;
- gli attributi.
31
Il campo degli attributi contiene qualsiasi altra cosa si desideri codificare nel
certificato, come il numero di telefono, il numero di fax, l’indirizzo e-mail, lo scopo per
cui si intende usare la chiave e una moltitudine di altre proprietà.
Può essere difficile capire quali informazioni possano essere incluse ne l DN, che,
teoricamente, è una stringa univoca che identifica il possessore del certificato, e quali,
invece, debbano far parte degli attributi: la distinzione consiste nel fatto che un DN
dovrebbe possedere soltanto i seguenti campi:
- il codice del paese (due lettere), tipo «IT», «UK», ecc.;
- lo stato o la provincia;
- la località;
- l’organizzazione o la compagnia;
- la propria unità organizzativa;
- il proprio nome
La richiesta di certificati RFC 2511, invece, permette di includere altre informazioni
attraverso l’uso delle estensioni, che possono essere attributi addizionali, come il
numero di telefono, oppure istruzioni per l’uso del certificato. Per esempio, un
certificato auto-assegnato richiede un’estensione Key Usage per assicurare che possa,
tale chiave, firmare altri certificati; si può anche voler aggiungere qualche estensione
sulla politica del certificato.
Per quanto riguarda le chiavi, ci sono due differenti approcci per generarne una
coppia e creare un certificato a partire dalla chiave pubblica, come si è già avuto modo
di dire:
1) delegare alla CA il compito di generare la coppia di chiavi e il certificato;
2) generare la coppia di chiavi localmente, usando mezzi hardware o software,
creare la richiesta di certificato contenente la propria chiave pubblica e inviare
tutto alla CA. Nel caso si stia mantenendo una rete con molti server, è meglio
generare centralmente tutte le coppie di chiavi, certificarle tutte e distribuire tutti
i certificati simultaneamente.
32
Quando il certificato raggiunge la data di scadenza, si può generare una nuova
coppia di chiavi ed inviare la nuova chiave pubblica alla CA perché venga certificata,
oppure ricertificare la vecchia chiave inviandola alla CA: in generale, è meglio generare
una nuova coppia di chiavi. Sarebbe quello anche il momento giusto per cambiare la
frase che protegge (passphrase) la chiave privata.
Se altre persone hanno usato il vecchio certificato per inviare messaggi
crittografati e il ricevente li ha memorizzati in questa forma, allora quest’ultimo deve
mantenere una copia della vecchia chiave privata per poter poi leggere i vecchi
messaggi, ma se questo dovesse causare problemi, si può anche decrittografare i
messaggi e ricrittografarli con la nuova chiave pubblica.
1.2.6. Il “lato” utente
Piuttosto che sull’autenticazione dell’utente, la maggior parte delle applicazioni
Web attuali si basano semplicemente sull’immissione di uno username e di una
password da parte dell’utente, per cercare di garantire il non ripudio. Le applicazioni,
però, possono richiedere una firma digitale da parte del client, che implica che l’utente
autorizzi specificatamente una transazione e, in particolare, che possieda un certificato
client. L’autorizzazione è quindi crittografata con la chiave privata del client, che
quest’ultimo mantiene rigorosamente segreta. In ogni caso, però, l’adozione dei
certificati client per uso individuale su Internet ha avuto uno sviluppo molto scarso,
anche perché gli utenti non hanno né tempo né voglia di seguire il noioso iter
burocratico necessario per l’ottenimento di un certificato client.
Differenti combinazioni di tutte le tecniche di sicurezza sopra esposte sono
usate per diverse applicazioni, a seconda della tipologia di sicurezza necessaria e della
misura in cui la soluzione ha necessità di essere bilanciata con la convenienza per
l’utente finale. Proprio per questo i certificati client per la garanzia di autenticazione e
non ripudio non sono utilizzati in modo diffuso sul Web, attualmente, perché la
maggioranza degli utenti non vuole essere annoiata con pratiche amministrative e
burocratiche per ottenere e mantenere in modo sicuro un certificato client.
33
1.3. SSL 3.0
Esiste una serie di versioni del protocollo SSL: in particolare, uno dei maggiori
benefici di SSL 3.0 risiede nel fatto che questa versione aggiunge il supporto per il
caricamento automatico delle catene dei certificati, permettendo così ad un server di
inviare al browser un proprio certificato insieme ai certificati degli emissari. Il browser
che si utilizza per navigare su Internet supporta tipicamente un certo numero di CA ben
note, perciò, richiedendo una comunicazione sicura con un Web server, se questo
risultasse certificato da una di esse, si è automaticamente garantiti sulla tutela delle
trasmissioni. Se, invece, ci si trova a comunicare con un Web server certificato da una
CA non compresa nella lista contenuta nel browser, sarà necessario caricare il
certificato della CA in questione nel browser stesso, abilitando perciò quest’ultimo a
validare anche tutti i certificati server firmati da quella CA.; questo comportamento
potrebbe risultare alla lunga pericoloso, perché, una volta caricato il certificato, il
browser accetterà tutti i certificati firmati da quella particolare CA. Invece il caricamento
automatico delle catene di certificati che si ha con la versione 3.0 del protocollo SSL
permette al browser di validare il certificato del server anche se i certificati di alcune CA
intermedie non sono stati installati, in quanto essi fanno comunque parte della catena
di certificati . SSL 3.0 è la base del protocollo standard Transport Layer Security
(TLS), sviluppato ad opera della Internet Engineering Task Force (IETF).
1.3.1. Sequenza di handshake
La sessione SSL viene stabilita seguendo una sequenza di handshake tra il
client e il server, che può variare, a seconda che il server sia stato configurato per
fornire un certificato server, oppure per richiedere un certificato client. Anche se
possono esistere casi particolari in cui vengono richiesti passi addizionali di
handshake, ad esempio per la gestione delle informazioni sulla Cipher Suite, cioè il set
riguardante gli algoritmi da usare per la crittografia, qui di seguito si tratterà lo scenario
più comune, rimandando, per ulteriori dettagli, alle specifiche di SSL.
34
Una volta che una sessione SSL è stata stabilita (durante l’handshake sono
stati fissati il numero di versione del protocollo, l’identificatore di sessione, il set di
algoritmi crittografici e le tecniche di compressione), può essere utilizzata per più
comunicazioni richiesta/risposta consecutive, evitando così le penalizzazioni di
performance legate alla necessità di ripetere i numerosi passi necessari per iniziare
una sessione ex novo: per questo, il server assegna ad ogni sessione SSL un unico
identificatore di sessione (memorizzandolo in cache) che può essere usato dal client
nelle successive comunicazioni, per ridurre il tempo necessario per l’handshake
(perlomeno finché l’identificativo di sessione rimane memorizzato nella cache del
server e naturalmente finché il client non chiude il browser).
I passi della sequenza di handshake sono:
- negoziazione della Cipher Suite da usare durante il trasferimento dati;
- costituzione e distribuzione della chiave di sessione o bulk key tra client e server
(«exchange random values»);
- autenticazione del server nei confronti del client (opzionale);
- autenticazione del client nei confronti del server (opzionale).
Un modo comune di usare SSL è proprio quello di rendere sicure le comunicazioni
HTTP sul Web, tra un browser e un Web server. Questa possibilità non preclude l’uso
di comunicazioni HTTP non sicure. La versione sicura viene realizzata sovrapponendo
HTTP su SSL (protocollo HTTPS), ma con un rilevante differenza: usa lo schema URL
https piuttosto che http e una differente porta del server (per default la 443).
35
Capitolo 2: PKI
36
2.1 Public Key Infrastructure
Una buona soluzione per la sicurezza in rete impone che il fornitore di contenuti
ed il client gestiscano e mantengano segreti, in modo responsabile e attento, i rispettivi
certificati digitali ed altre informazioni riguardanti la sicurezza: le soluzioni di Public Key
Infrastructure (PKI) aiutano le compagnie nel difficile compito di gestire queste
informazioni, in modo da mantenerle sicure e facili da organizzare; infatti la crittografia
a chiave pubblica garantisce gli aspetti critici della sicurezza nelle transazioni
elettroniche, ma tutto ciò non può essere realizzato «sottovuoto», cioè rimanendo
all’interno degli algoritmi matematici.
Ad esempio si può aver bisogno di sapere:
- chi ha emesso il certificato;
- dove viene immagazzinata la chiave privata;
- dove si possono trovare i certificati.
2.2 Funzioni assolte da una PKI
Una PKI comprende comunemente le seguenti componenti funzionali:
- Certificate Authority (CA): hanno il compito di emettere, consegnare e revocare i
certificati (internamente o in outsourcing);
- Registration Authority (RA): hanno il compito di verificare il legame tra le chiavi
pubbliche e le identità dei possessori;
- Soggetti o possessori dei certificati: persone, organizzazioni, macchine o software
per i quali è stato emesso un certificato e che possono usarlo per firmare i propri
documenti;
- Clienti: questi validano le firme digitali e la propria catena di certificati attraverso la
chiave pubblica di una CA fidata;
- Repository: contenitore per le chiavi, i certificati e la lista dei certificati revocati o
Certificate Revocation List (CRL), mantenuto in una directory abilitata all’LDAP
(Lightweight Directory Access Protocol);
- Funzione di gestione: tipicamente implementata tramite una console di gestione;
37
- Politica di sicurezza: stabilisce e definisce la direzione che viene scelta, ad alto
livello, per l’organizzazione della sicurezza, così come tutti i processi e i principi per
l’uso della crittografia.
- In aggiunta a tutto ciò la PKI può fornire un servizio di recupero delle chiavi nel
caso in cui un utente dovesse perdere la propria chiave privata, a causa di un
crash hardware o di altri problemi.
Le seguenti sono alcune delle funzioni realizzate all’interno di una PKI:
- Registrazione: questo è il processo attraverso il quale il richiedente si presenta alla
CA, per cercare di ottenere un certificato: durante la procedura viene richiesto al
soggetto di fornire i propri attributi, come il nome, l’indirizzo di e-mail, il numero di
telefono ed altre informazioni, seguendo le specifiche CPS (Certification Practices
Statement) della CA; quindi la CA segue le linee guida specificate nel CPS, per
verificare che i dettagli forniti dal soggetto siano corretti, prima di emettere il
certificato;
- Certificazione: è il processo attraverso il quale la CA emette un certificato che
contiene la chiave pubblica del soggetto, lo consegna al soggetto stesso e lo
pubblica in un repository pubblico e accessibile a tutti;
- Generazione delle chiavi: in qualche caso, il soggetto genera la coppia di chiavi nel
proprio ambiente locale e poi passa la chiave pubblica alla CA per l’emissione del
certificato; se invece è la CA ad essere responsabile della generazione delle chiavi,
le stesse sono normalmente inviate al soggetto sottoforma di file crittografato,
oppure su un token fisico come una Smartcard. Per ragioni di sicurezza, è
considerata migliore la pratica di generazione della coppia di chiavi da parte
dell’utente, seguita dalla trasmissione della sola chiave pubblica alla CA, perché in
questo modo si è sicuri che la chiave privata sia memorizzata solo in un’unica
postazione;
- Recupero della chiave: alcune implementazioni PKI richiedono che di tutte le
chiavi, comprese quelle per la bulk encription, venga fatta una copia di backup
immagazzinata in una postazione sicura da parte dell’utente: in questo modo esse
38
sono recuperabili se il soggetto dovesse perderle, permettendo così di
decrittografare dati crittografati precedentemente inviati. Se invece è stato
implementato un altro sistema di recupero delle chiavi, la CA stessa o il sistema
dedicato per il recupero fa il backup di tutte le chiavi di tutti i soggetti: il compito
principale della CA è, in questo caso, quello di assicurare che una chiave possa
essere recuperata dal soggetto che ne è il proprietario, ma non da altre parti non
autorizzate;
- Aggiornamento delle chiavi: tutte le coppie di chiavi ed i certificati ad esse associati
devono essere aggiornati ad intervalli regolari; possono presentarsi essenzialmente
due scenari che rendono necessaria la sostituzione della coppia di chiavi di un
utente:
1) la data specificata nel certificato come data di scadenza è stata
raggiunta: in questo caso i differenti componenti della PKI devono
assicurare che l’aggiornamento sia quanto più possibile
trasparente, in modo da minimizzare il disturbo arrecato all’utente
quando la sua coppia di chiavi viene aggiornata;
2) la chiave privata (dell’utente o della CA) è compromessa: in questo
caso la transizione non è trasparente. La PKI deve avere un
meccanismo per annunciare pubblicamente che il vecchio
certificato, corrispondente alla chiave privata compromessa, non è
più valido e che un suo sostituto (eventualmente) è disponibile e
valido con effetto immediato. Lo scenario peggiore per una
qualsiasi PKI è la compromissione della chiave privata della sua
stessa CA . Un modo per limitare i danni di questo disastro è quello
di pregenerare e immagazzinare in una postazione sicura una
coppia di chiavi di riserva, da usare in una situazione di
emergenza; anche con questa coppia di riserva non si evitano
naturalmente le complicazioni, perché ogni utente della PKI deve
essere informato della sostituzione usando una qualche modalità
«off line», ad esempio tramite telefono, fax, lettera o un incontro
39
faccia a faccia con la controparte, per evitare di usare la
trasmissione elettronica e le conseguenti possibili intercettazioni;
- Certificazione incrociata: il processo di certificazione incrociata permette ad utenti
appartenenti al dominio amministrativo di una particolare CA di fidarsi dei certificati
emessi da una CA operante in un dominio amministrativo diverso. Si noti che la
certificazione incrociata può essere un processo ad una o due vie: se la CA X
emette un certificato in favore della CA Y, la CA Y può emettere a sua volta un
certificato in favore della CA X;
- Revoca o annullamento: nella maggior parte dei casi, un certificato rimane valido
fino a quando non viene raggiunta la data di scadenza. Ci sono comunque un certo
numero di situazioni in cui è necessaria una revoca prematura del certificato, che
includono i seguenti casi:
1) il soggetto ha cambiato nome;
2) un impiegato lascia la compagnia che ha emesso il certificato;
3) si è verificata una compromissione (o una sospetta
compromissione) della chiave privata.
Il metodo stabilito per la revoca dei certificati include l’uso di una Certificate Revocation
List (CRL), che raccoglie i certificati revocati (normalmente ogni certificato è identificato
da un numero seriale unico, assegnato nel momento dell’emissione) ed è firmata con
tanto di data dalla CA; la CA pubblica la CRL ad intervalli regolari, nello stesso
repository pubblico. Un punto critico che emerge dall’uso delle CRL è giudicare
l’intervallo più appropriato tra una pubblicazione e l’altra della CRL aggiornata: un
certificato la cui corrispondente chiave privata sia stata compromessa deve essere
revocato il più presto possibile, subito dopo che la compromissione è stata scoperta;
altrimenti, se la CRL non venisse pubblicata per molti giorni, dopo la revoca del
certificato, gli utenti non sarebbero a conoscenza del problema e potrebbero accettare
messaggi firmati da un intruso con la chiave privata rubata; comunque, anche se la
40
CRL fosse pubblicata immediatamente dopo la revoca, non ci sarebbe garanzia che gli
utenti ne vengano a conoscenza in tempo.
2.3 Tipi di PKI
I problemi, crittografici e non, di cui le PKI si devono fare carico, sono relativamente
ben compresi dal mondo che lavora utilizzando Internet: a causa di questi problemi la
realizzazione pratica di una PKI richiede grossi sforzi di gestione e per necessità di
specializzazione ne sono essenzialmente emersi due tipi:
1) root PKI;
2) PKI ordinarie.
Tutte le chiavi pubbliche delle CA a livello root sono inserite nei Web browser
pubblicamente disponibili sul mercato, sottoforma di certificati X.509 auto-assegnati (la
chiave pubblica è auto certificata con la corrispondente chiave privata della root CA):
l’unico scopo dell’autocertificazione è quello di semplificare la gestione dei certificati.
Essendo i certificati root distribuiti insieme ai browser, essi non possono essere
facilmente aggiornati, perciò la gestione di chiavi root segue il destino delle versioni e
delle distribuzioni dei browser stessi. Quindi, per tenere aggiornate le chiavi root, gli
utenti devono continuamente tenere allineati i loro browser alle versioni più nuove e
appena uscite; inoltre, dal momento che non è possibile, praticamente, modificare
centinaia di migliaia di copie di chiavi sparse sui browser di mezzo mondo, è anche
praticamente impossibile revocare i certificati root: per questo motivo le CA root si
distinguono dalle altre per la propria organizzazione, estremamente solida e a prova di
pirata informatico.
Una delle tante applicazioni dei certificati digitali è quella di firmare digitalmente
componenti software per autenticarne i produttori: infatti il problema della sicurezza che
gli utenti stanno affrontando, relativamente a componenti attivi come gli Applet Java e
gli Active-X Microsoft, è se tali programmi, importati dall’esterno e fatti eseguire sul
proprio computer, possano essere eseguiti in modo sicuro. Un modo di risolvere
questo problema potrebbe essere quello di accettare solo i componenti firmati
41
digitalmente dalla chiave pubblica dei relativi costruttori, ma così si avrebbe solamente
un modo per identificarne l’identità e, in linea di principio, questo non può garantire
nulla: anche una software house fidata e perfettamente in buona fede potrebbe, per
errore, costruire un componente pericoloso. L’esecuzione di componenti software
richiede molto più dell’autenticazione del produttore del software e della sua origine.
Questo è un problema cruciale dell’ingegneria del software in generale, ma è
particolarmente rilevante nell’e-commerce, dove i componenti che rendono semplice le
transazioni elettroniche sulla rete hanno una natura sempre più dinamica. Nei sistemi
tradizionali, il testing accresce la fiducia in un comportamento sicuro da parte del
sistema stesso, ma nei sistemi di e-commerce, i componenti software vanno e
vengono dinamicamente e l’opportunità per un testing integrato e immediato
diminuisce sempre di più, invece di aumentare.
Al contrario delle root PKI, una PKI ordinaria non distribuisce le proprie chiavi
pubbliche all’interno dei Web browser, ma attraverso procedure separate, controllate
dall’organizzazione della PKI stessa: questa organizzazione generalmente amministra
alcuni server dai quali possono essere scaricati i certificati. Le PKI ordinarie sono nate
per incontrare specifici bisogni all’interno di particolari organizzazioni o attività di
business; tali PKI avranno pieno controllo sulle politiche di fiducia all’interno della
propria gerarchia, ma, non potendo inserire le chiavi all’interno dei Web browser, non
riescono ad ottenere facilmente una copertura globale. Le PKI ordinarie possono
garantire grande affidabilità ed essere quindi adatte per transazioni di grande portata:
inoltre le organizzazioni che le gestiscono possono decidere, o possono essere
costrette dalle leggi di un particolare paese, a fare certificazioni incrociate con altre
PKI, ordinarie oppure root. In questo modo si formano diverse gerarchie di certificazioni
collegate ed un utente, che si trovi di fronte alla necessità di identificare in modo sicuro
un Web server certificato da una PKI ordinaria, può risalire la gerarchia fino a ritrovare
un certificato root.
La distribuzione sicura delle chiavi pubbliche è essenziale e una tipica soluzione
potrebbe essere anche quella di equipaggiare ogni utente con una Smartcard,
contenente le chiavi private dell’utente e le chiavi root pubbliche.
Il grado di fiducia nel legame tra una chiave pubblica e l’identità del possessore
memorizzata in un certificato dipende da molti fattori, incluse le pratiche seguite dalla
CA nel verificare l’identità del proprietario, la politica operativa della CA, le procedure e
i controlli di sicurezza, gli obblighi del proprietario (riguardanti ad esempio la
42
memorizzazione sicura della chiave privata) e gli obblighi legali della CA (ad esempio
le garanzie che deve fornire agli utenti). In accordo con X.509, una politica di
certificazione è un «insieme di regole che indicano l’applicabilità di un certificato a
particolari comunità e/o classi di applicazioni con requisiti comuni di sicurezza’’. È
interessante notare che una root PKI consiste di gerarchie isolate con una CA root
distinta al top: la ragione di questo è in parte dovuta alla difficoltà di confrontare il CPS
(Certificate Practices Statement) e renderle compatibili e alla conseguente difficoltà nel
creare certificazioni incrociate.
I modelli di sicurezza basati sulla politica sono utili, in quanto specificano regole
generali per il reperimento di gruppi di informazioni oggettive e verificate dalla CA, ma,
perché questi abbiano significato, la parte interessata dovrebbe effettivamente leggere
il CPS o i documenti riguardanti la politica ogni volta che accede ad un Web server
sicuro. Questa eventualità è di fatto estremamente remota in condizioni normali,
perché significherebbe leggere ogni volta un documento lungo almeno 10 pagine,
scritto in un linguaggio poco formalizzato, relativamente complesso e comprensibile
esclusivamente da esseri umani (anche se sono stati fatti vari tentativi per
standardizzarlo e quindi per automatizzarne la lettura).
43
Capitolo 3: LDAP
44
3.1 LDAP Introduzione
Abbiamo visto che una PKI si occupa della gestione di una grande quantità di
informazioni particolarmente riservate e delicate: per poterle organizzare ha, quindi,
bisogno di un database; un database classico, però, non sarebbe di molta utilità, in
quanto dotato essenzialmente di una struttura centralizzata, mentre servirebbe un
database distribuito.
Una directory è, essenzialmente, un database specializzato e ottimizzato per la
lettura, la visualizzazione e la ricerca di dati memorizzati sottoforma di file. Le directory
contengono informazioni descrittive basate su attributi e, sfruttando questi, supportano
sofisticate funzioni di filtraggio, ma generalmente non possono gestire transazioni
complicate o schemi di rollback come quelli che sono all’ordine del giorno nei DBMS
(DataBase Management System), progettati, invece, per gestire grandi volumi di dati
sui quali eseguire complicati aggiornamenti e selezioni multiple. Gli aggiornamenti in
un file system sono tipicamente cambiamenti «tutto o niente» e la struttura delle
directory è stata appositamente pensata per fornire risposte veloci in seguito ad
operazioni di ricerca riguardanti anche grandi volumi di dati; esse permettono di
replicare informazioni ad ampio raggio, per aumentarne la disponibilità (information
sharing) e l’affidabilità (backup), riducendo nel contempo i tempi di risposta.
Ci sono molti modi differenti per fornire un servizio basato sulle directory; alcuni
permettono di immagazzinare nelle directory differenti tipi di informazione, stabilire
differenti requisiti su come tali informazioni possono essere referenziate, interrogate ed
aggiornate, come possono essere protette da accessi non autorizzati ecc. Alcuni di
questi servizi sono locali, dal momento che riguardano un contesto ristretto, mentre
altri sono globali, riguardando un contesto di gran lunga più vasto (ad esempio l’intera
rete Internet): i servizi globali sono generalmente distribuiti, il che significa che i dati
che contengono sono sparsi su diverse macchine, tutte cooperanti per fornire il servizio
nella sua interezza; il Domain Name System (DNS) di Internet è un esempio di servizio
basato su directory, ma distribuito su scala globale.
Un possibile modello globale basato su directory è LDAP (Lightweight Directory
Access Protocol): si tratta di un protocollo di accesso alle directory che si basa sul
TCP/IP e fu concepito inizialmente dai ricercatori dell’Università del Michigan.
Il modello di organizzazione delle informazioni è basato sulle «entry», attributi
che possiedono un Distinguished Name (DN) unico a livello globale usato per riferirsi
45
ad ogni entry in modo non ambiguo. Ogni entry possiede un tipo e uno o più valori: i tipi
sono generalmente mnemonici come «cn» (common name), oppure «mail» (indirizzi e-
mail), mentre la sintassi dei valori dipende dal tipo. Per esempio, l’entry cn può avere il
valore «Salvatore Iacometta», mentre mail può contenere il valore
«[email protected]» e jpegPhoto contiene obbligatoriamente una immagine
nel formato binario JPEG.
In LDAP, le entry delle directory sono organizzate in una struttura gerarchica ad
albero; tradizionalmente, questa struttura riflette quella geografica o organizzativa: le
entry rappresentanti Federazioni di Stati compaiono al livello radice, seguite dalle entry
rappresentanti Stati ed organizzazioni nazionali; proseguendo si trovano le entry che
rappresentano aziende, poi via via le unità organizzative, poi persone, stampanti,
documenti e qualsiasi altra entità del mondo informatico.
L’albero può essere anche strutturato sui nomi di domini Internet: questo
approccio sta diventando sempre più popolare, perché permette di localizzare i servizi
basati su directory usando il DNS (Domain Name System).
Una entry viene riferita attraverso il suo DN (Distinguished Name), che è
costruito prendendo il nome stesso della entry (chiamato RDN = Relative Distinguished
Name) e concatenandogli i nomi delle entry sue genitrici.
LDAP definisce operazioni per interrogare e aggiornare la directory: ci sono
operazioni per aggiungere e rimuovere una entry dalla directory, per cambiarne una
esistente e per cambiarne il nome. La maggior parte del tempo, comunque, LDAP è
usato per cercare informazioni in una directory: le sue operazioni di ricerca permettono
di cercare, in precise porzioni della directory, entry che rispettino determinati criteri
specificati da un filtro di ricerca, dopodiché si possono richiedere informazioni da una
qualsiasi delle entry che rispetti i criteri. Alcuni servizi basati su directory non
forniscono protezione, permettendo a chiunque di accedere alle informazioni; LDAP,
invece, fornisce meccanismi che permettono ad un utente di autenticarsi o comunque
di provare la propria identità, trovando così il modo di proteggere, attraverso un ricco
controllo dell’accesso, le informazioni contenute dal server. LDAP supporta anche
servizi di sicurezza che garantiscono privacy ed integrità.
Il servizio basato su directory LDAP ha una architettura client/server: uno o più
server LDAP contengono i dati che costituiscono l’albero di directory e un client può
connettersi ad un server LDAP per porgli una domanda; il server risponde inviando una
risposta e/o un puntatore verso risorse dalle quali il client potrebbe ottenere
46
informazioni addizionali (si tratta generalmente di un altro server LDAP). Non ha
importanza a quale server LDAP un client si connette, perché egli ha sempre la
medesima visuale della directory: un nome presentato come criterio di ricerca ad un
particolare server LDAP produce gli stessi risultati che si sarebbero ottenuti da un altro
server, perché referenzia comunque la stessa entry. Questa caratteristica riveste una
grande importanza, specie in un servizio globale basato su directory come LDAP.
Tecnicamente, LDAP è un protocollo di accesso ad un servizio di directory
X.500 (il servizio di directory OSI) e inizialmente i server erano Gateway tra LDAP e il
Directory Access Protocol (DAP) X.500.
DAP è un protocollo piuttosto pesante che opera al di sopra di uno stack di
protocolli OSI completo e richiede una significativa quantità di risorse computazionali.
Invece LDAP è progettato per operare su TCP/IP e fornisce molte delle funzionalità
DAP ad un costo molto minore. L’utilizzo di LDAP rende semplice accedere ad una
directory X.500, ma richiede ancora un servizio X.500 completo per fornire tutte le
funzionalità garantite da DAP.
Una directory, nella terminologia X.500, è una speciale forma di database
progettata per essere particolarmente adatta per l’uso su Internet ed altri sistemi
distribuiti e il DAP è uno dei quattro protocolli definiti dallo standard X.500 per
supportare servizi di directory aperti e standardizzati.
L’LDAP, come si è avuto modo di dire, semplifica l’accesso ai servizi della
directory modellati nello standard X.500 e ha funzionalità simili al DAP operando
direttamente sopra il TCP/IP, ma la «leggerezza» del protocollo LDAP viene realizzata
rimuovendo alcune delle caratteristiche definite in X.500 e, di conseguenza, le directory
LDAP non supportano funzionalità che sono molto importanti in un ambiente con
directory distribuite, come quello di una interconnessione tra directory server e duplicati
online. Un ulteriore inconveniente del protocollo LDAP è quello del processo di replica
delle informazioni tra una directory LDAP e una DAP (problema di migrazione dei
database): fino a quando i server con directory LDAP non supporteranno il protocollo
DISP (Directory Information Shadowing Protocol), la replica dovrà essere fatta usando
essenzialmente un processo manuale, anche se alcuni aspetti possono essere
automatizzati. La replica manuale è realizzata attraverso una serie di aggiornamenti
incrementali che contengono solo i cambiamenti avvenuti a partire dall’ultimo update,
seguiti ciclicamente da un aggiornamento completo, per assicurare che tutti i
47
cambiamenti siano inclusi: per ora si tratta di una serie di copie multiple (di un
certificato, nel caso di una PKI) scritte sulla directory.
L’IETF (Internet Engineering Task Force) sta correntemente lavorando su un
progetto per la replica delle informazioni tra server LDAP: lo standard proposto è noto
come LDAP Duplication-Replication/Update Protocols (LDUP).
3.2 LDAP in dettaglio
Dopo aver spiegato in modo generico cosa è e a cosa serve LDAP, possiamo
ora entrare più in dettaglio introducendo qualche informazione tecnica:
possiamo dire che LDAP è un protocollo per far comunicare più computer con un
directory server. Viene definito nelle rfc (Requests For Comments, documentazione
tecnica di Internet) 1777 e 2251. Ldap è stato disegnato per permettere un accesso
leggero ad alberi derivati da directory X.500 OSI Directory Access
3.2.1 Cosa è una directory
E' una collezione gerarchica di oggetti e di diritti associati agli oggetti stessi, un
po' come le directory di un filesystem.
Non è una base di dati intesa come sql. In sql i dati sono organizzati in tabelle, in ldap i
dati sono organizzati in una struttura ad albero.
3.2.2 Differenze tra ldap e database relazionali
Ldap è stato progettato per basi di dati che devono essere letti spesso e
aggiornati meno frequentemente. E' quindi ottimizzato per permettere letture veloci,
anche a discapito della velocità di scrittura.
I dati sono organizzati in una struttura gerarchica e non in tabelle.
48
3.2.3 Differenze tra ldap e X.500
Programmi basati su X.500 erano particolarmente pesanti e consumavano molte
risorse ed erano quindi inadatti all'esecuzione su macchine client.
Ldap mantiene le stesse caratteristiche principali, si basa su tcp/ip invece che sullo
stack osi, tutti i dati sono stringhe e non binari.
IETF prevede per ldap in più rispetto ad X.500 la replicazione multimaster.
Esempio di directory
dc=crotone,dc=calabria,dc=it
3.2.4 La radice dell'albero
Nel corso degli anni ci sono state evoluzioni dell'ldap e la radice può essere
specificata in più modi:
o=gruppostudenti, c=IT (X.500)
dc=crotone.calabria.it
dc=crotone,dc=calabria,dc=it (rfc 2247)
La terza formulazione riflette la struttura dei dns, con tutti i vantaggi che ne
conseguono.
3.2.5 Organizational Unit
Sono i nodi interni dell'albero ldap. Permettono una divisione in sottoparti dei
dati raggruppandoli in gruppi logici.
La divisione dei dati in ou permette di restringere le ricerche a sottoporzioni
dell'albero, diminuendo quindi i tempi di ricerca.
49
Tutti i dati e gli oggetti che compongono l'albero ldap vengono descritti dagli
schemi, in cui per ogni oggetto vengono definiti i campi che lo compongono e i tipi dei
dati.
Per aumentare gli oggetti salvabili all'interno degli alberi ldap è necessario
includere gli schemi necessari.
3.2.6 I backend
Openldap può salvare i dati in molti formati. I più importanti sono:
- ldbm (formato predefinito, basato su bdb)
- bdb (vecchio formato basato su bdb)
- ldap (il server funziona in modalità proxy)
- sql (serve come gateway tra applicazioni e db)
3.2.7 Creare gli indici
Gli indici vengono definiti nel file slapd.conf:
index objectClass eq index mail,mailAlternateAddress,uid eq index givenName,sn eq
index uidNumber,gidNumber eq
Dopo averli dichiarati gli indici devono essere creati col comando slapindex,
ricordandosi prima di fermare il server ldap.
3.2.8 Access control list
L'accesso ai dati può essere ristretto ad un particolare insieme di utenti, e si
può limitare l'accesso in lettura e scrittura alle porzioni dell'albero.
access to attribute=userPassword by dn="cn=admin,dc=salvatore,dc=crotone,dc=it"
write by anonymous auth by self write by * none
50
3.2.9 Replica
Openldap prevede due demoni slapd e slurpd. Il primo è il demone del server
ldap, mentre il secondo è il demone di replicazione. Si occupa di inoltrare le modifiche
dell'albero a tutti i server di replica.
In caso di interruzione della connettività tra master e slave le modifiche vengono
cachate per essere poi inoltrare al ripristino della stessa.
Esempio di replica
Configurazione della replica sul server di backup
rootdn "cn=admin,dc=qualcosa" rootpw "passwordcopia"
updatedn "cn=admin,dc=qualcosa" updateref "ldap://serveroriginale"
Configurazione della replica sul master
replogfile /var/lib/ldap/replog
replica host=servercopia:389 binddn="cn=admin,dc=qualcosa" bindmethod=simple
credentials=passwordcopia
Replica multimaster
51
Sebbene le rfc di ldap prevedano la replica multimaster, questa è implementata ma
non supportata da openldap.
Il codice c'è, si può abilitare, ma gli sviluppatori ne sconsigliano l'uso perché
potrebbero esserci dei rischi di corruzione dei dati.
3.2.10 Integrazione di ldap
Ldap può essere integrato con molti servizi per permettere una loro gestione
centralizzata:●
posta (postfix, courier-imap, pop3, squirrelmail e openwebmail)●
web server (libapache-auth-ldap)●
ssh●
server ftp (proftpd-ldap)●
application server (zope-ldapuserfolder)●
client (samba e pam)
3.2.11 Il pacchetto ldap-utils
Contiene tutti i programmi base per la gestione dell'albero ldap.
I programmi devono essere configurati con il file /etc/ldap/ldap.conf, in cui si
specificano l'indirizzo del server ldap e il suffisso.
Il pacchetto contiene ad es. ldapsearch:
è il programma base con cui fare le interrogazioni all'albero.
Per vedere il contenuto di tutto l'albero si usa il comando
Ldapsearch –x -D»cn=admin,dc=salvatore,dc=crotone,dc=it» -W objectclass=*
Opzioni di ldapsearch
52
-x implica l'uso dell'autenticazione semplice (al posto di sasl)
-D è il binddn (se omesso la connessione è di tipo anonimo)
-W richiede la password da riga di comando
objectclass=* richiede di mostrare gli oggetti di tutte le classi.
3.2.12 Supporto della crittografia
Per permettere una consultazione sicura dei dati contenuti all'interno di un
albero ldap è possibile utilizzare la crittografia.
Openldap supporta:
- ssl v3
- tls v1
- sasl
3.2.13 Strumenti di amministrazione
I programmi del pacchetto di ldap-utils sono utili ma non intuitivi. Ci sono un paio di
programmi interessanti:
- gq è un client basato su gtk 1
- phpldapadmin è un programma scritto in php che gira su apache dall'interfaccia
molto intuitiva.
Tramite phpldapadmin si possono importare dei file con estensione “ldif” con contenuti
simili a ciò che segue:
dn: cn=Iacometta,dc=my-domain,dc=com
cn: Iacometta
sn: Iacometta
53
objectClass: top
objectClass: person
3.2.14 Integrazione di ldap sui client
Ldap non prevede l'uso esclusivo sul lato server. Può essere usato anche sui
client per la gestione delle rubriche (netscape e mozilla) e dei bookmarks (netscape).
54
Capitolo 4: I Web Services
55
4.1 I Web services
In questo periodo si fa un gran parlare dei Web Services che sembra
diventeranno la nuova frontiera del Web. Attorno ruotano molti termini nuovi come
SOAP, WSDL, UDDI. Al di là di queste parole i Web Services sono però
semplicemente un sistema standardizzato per scambiare dati fra applicazioni e per
l'uso di procedure in remoto da parte di altri programmi.
Mentre i siti Web sono costruiti fondamentalmente per condividere informazioni
tra le persone e sono pensati per essere visualizzati con un browser, i Web Services
sono invece costruiti per lo scambio e la condivisione di dati tra programmi. Il modo in
cui i dati saranno visualizzati non ha niente a che fare con i Web Services, sarà
compito del programmatore mostrarli sul browser, stamparli o manipolarli come meglio
crede.
Semplificando un po' possiamo affermare che non è niente di così
rivoluzionario, le stesse cose che si fanno con i Web Services le facciamo già da
qualche tempo, anche se non le chiamiamo così.
Quando interroghiamo la Banca per verificare che un numero di carta di credito
sia valido è un simile ad usare un Web Services. Stessa cosa quando facciamo il
parsing di una pagina con gli orari dei treni per poi visualizzarli sul nostro sito, o ancora
quando ci mettiamo d’accordo con un sito d’informazioni per poterle pubblicare anche
sul nostro. TCP/IP e HTTP sono sempre alla base di tutto e con i Web Services è la
stessa cosa.
Qual è allora la differenza? La differenza è che adesso non esiste un modo
standard per effettuare tutte queste operazioni. Dobbiamo sempre accordarci su come
scambiare i dati, su come chiamare la pagina remota e se passare i parametri via URL
(Get) o via Form (Post). Magari poi capita che il sito remoto cambi il lay-out della
pagina ed a noi tocca rifare tutto il parser.
Se poi vogliamo utilizzare servizi messi a disposizione da più siti per incorporarli
nel nostro, ogni volta dobbiamo scrivere qualcosa di completamente diverso.
Con i Web Services, invece, abbiamo un file che descrive le operazioni
supportate dal Web Service, i parametri richiesti per funzionare ed il tipo di dati che
vengono restituiti. Questi sono i file WSDL (Web Services Description Language).
Normali file XML che possono essere chiamati direttamente dal browser in modo da
56
visualizzare la descrizione della struttura delle interfacce di chiamata e risposta.
Provate a visualizzare quello di Google andando qui:
http://api.google.com/GoogleSearch.wsdl
Poi abbiamo SOAP, uno standard per definire come i dati devono essere
incapsulati e strutturati.
Infine, troviamo UDDI che in pratica sono una serie di specifiche per creare un
motore di ricerca per Web Services.
Conoscere nel dettaglio questi protocolli e specifiche non è necessario. Usare i Web
Services, è molto più semplice di quello che sembra.
4.2 Motori di ricerca per Web services
Abbiamo parlato fino ad ora di Web services, ma non sappiamo se ne esistono,
cosa fanno, dove trovarli e se sono gratis. Dunque come per tutte le cose esistono dei
motori di ricerca per Web services. Ad esempio http://uddi.microsoft.com oppure
http://www-3.ibm.com/services/uddi/ o ancora www.xmethods.net o
www.salcentral.com.
4.3 Un po’ di esempi
Sono stati raccolti un po’ di esempi per fare un po’ di chiarezza sulla
realizzazione e sull’uso dei Web Services.
Da questo momento in poi il linguaggio di programmazione che utilizzeremo per
la realizzazione delle nostre applicazioni sarà PHP.
4.3.1 Un primo esempio: un traduttore Inglese-Italiano
Il primo esempio che vedremo è un Web services che consente di tradurre un
documento da una lingua all'altra in modo automatico. Passeremo al servizio la stringa
da tradurre, il linguaggio da utilizzare per la traduzione, ed il gioco è fatto! Se avessimo
dovuto scrivere noi un'applicazione del genere, senza utilizzare un Web services,
avremmo dovuto raccogliere i dati dei vocabolari e scrivere gli algoritmi di traduzione,
57
invece in questo modo possiamo semplicemente invocare un Web services che fa il
lavoro per noi, e potremo offrire ai visitatori del nostro sito un servizio di traduzione
simultanea.
Vediamo come funziona:
<?
require_once('nusoap/nusoap.php');
$parameters = array(
"translationmode"=>"en_it",
"sourcedata" =>"Hello World - this is Italian"
);
$soapclient = new soapclient
('http://www.xmethods.net/sd/2001
/BabelFishService.wsdl','wsdl');
$result = $soapclient->call('BabelFish',$parameters);
print "$result";
?>
La prima riga è fondamentale. Abbiamo detto che il linguaggio che utilizziamo
deve avere come unico requisito quello di essere compatibile con SOAP.
Una volta inclusa nusoap.php abbiamo definito i parametri dal passare al Web
services. Lo abbiamo fatto per comodità utilizzando un array. I due parametri sono
"translationmode" e "sourcedata", rispettivamente contengono il tipo di traduzione che
deve essere effettuata e la stringa da tradurre.
Infine instanziamo un oggetto di tipo soapclient con la riga
$soapclient = new soapclient
('http://www.xmethods.net/
sd/2001/BabelFishService.wsdl','wsdl');
e richiamiamo la funzione BabelFish del Web services passandogli i parametri definiti
sopra.
Il Web Services esporrà il risultato della funzione BabelFish nella variabile
$result che noi prontamente stamperemo a video tramite un print. Ovviamente quello
che vedremo è la nostra stringa tradotta dall'inglese all'italiano. Pensate se avessimo
58
dovuto implementare noi il servizio di traduzione per i nostri clienti! Usando un Web
services possiamo scrivere applicazioni potenti, servendoci del lavoro che altri ci hanno
messo a disposizione. A nostra volta scrivendo le nostre applicazioni, esponendo dei
Web services, potremo contribuire al lavoro di altri.
4.3.2 I parametri che si devono passare: UDDI
E’ stato dato per scontato:
1)Di conoscere l'indirizzo del Web services da richiamare
2)Di sapere quali parametri passargli
3)Di sapere quale funzione richiamare per la traduzione.
Queste informazioni sono note perché è stato usato UDDI per trovare il Web services.
UDDI pubblica:
1)L'indirizzo del Web services da richiamare
2)Una breve descrizione del suo funzionamento (opzionale)
3)Le funzioni esposte (opzionale)
4)I parametri da passare (opzionale)
Esporre un Web services significa anche corredarlo di un file in formato WSDL
che ne descrive in XML perfettamente il funzionamento. Per cui se proprio ci sono
dubbi su come funziona il Web services che è stato trovato, basta dare uno sguardo al
file WSDL che lo descrive e se ne saprà di più. Anche WSDL (come tutto il resto
quando si parla di Web Services) è uno standard. L'acronimo di WSDL è Web Services
Description Language.
59
4.3.3 Le informazioni in XML scambiate
Come già detto ci pensa SOAP a trasformare la nostra richiesta in una richiesta
XML compatibile. Ovviamente anche per SOAP esiste un sito ufficiale che descrive il
protocollo http://www.w3.org/TR/SOAP/.
Quali sono state le informazioni in formato XML che si sono scambiati client e
server? Aggiungendo un paio di righe al codice:
echo 'Request: <xmp>'.$soapclient->request.'</xmp>';
echo 'Response: <xmp>'.$soapclient->response.'</xmp>';
chiediamo che vengano stampate in chiaro la richiesta effettuata dal client e la risposta
data dal server.
Si potrà notare che la richiesta e la risposta sono state effettuate entrambe in
formato XML. Usando SOAP ad un livello più alto, poco ci importa di come siano
composte domande e risposte (a meno che non stiamo facendo il debug
dell'applicazione). L'importante è sapere che questo modo di scambiarsi i dati, ci astrae
totalmente dal conoscere i dettagli di come è implementato il Web services dal lato
server. Non sapremo mai cosa fa per tradurre la nostra stringa , ne su che architettura
gira, non dovremo preoccuparci di niente, se non di passargli i dati corretti, per il resto
ce la caveremo con un semplice print $return.
4.3.4 Un secondo esempio: la jpg di un codice a barre
Questo secondo esempio invia ad un Web services un numero e ottiene come
risposta un'immagine che rappresenta il codice a barre di quel numero. Vediamo come
funziona
<?php
require_once('nusoap/nusoap.php');
$parameters = array(
"username" =>"any",
60
"password" =>"any",
"num" =>"123456",
"imgtype" =>"JPG"
);
$soapclient = new soapclient('http://www.flash-db.com
/services/ws/barCodes.wsdl', 'wsdl');
$barCodeHex = $soapclient->call('doBarCodes',$parameters);
if ($imgtype == "jpg") {
header("Content-type: image/jpg");
} else {
header("Content-type: image/png");
}
$binaryBarCode = base64_decode($barCodeHex);
print $binaryBarCode;
?>
In questo caso la tecnica è assolutamente identica a quella usata in
precedenza.
A seconda di come il Web services è stato implementato, potrebbe avere
bisogno di qualche parametro in più o in meno (occorre leggere sempre bene la
documentazione relativa al Web services e se è il caso, il suo file wsdl). Il metodo Call
dell'oggetto soapclient ha due parametri obbligatori e tre opzionali. I due obbligatori
sono il nome della funzione da richiamare è un array di parametri, opzionalmente
possono seguire il namespace, la SOAPaction, e un array di headers.
4.3.5 Dal Client al Server: creare un Web Services
Se normalmente si inizia con il “lato” client, per scoprire come funziona il
meccanismo e per scovare web services interessanti, il successivo passo logico è
scrivere un proprio web services e, magari, pubblicarlo.
Creiamo un Web services che mette a disposizione un servizio che determina
se l’indirizzo di un sito Web, che gli passiamo come variabile, esiste o no.
Partiamo subito con un esempio di codice:
61
“checkdomain.php”
ed è possibile visualizzare il listato completo nell’Appendice D:
“D.1.1 checkdomain.php”
Si può notare, analizzando il listato, che viene inclusa, ovviamente, l'onnipresente
libreria nusoap.php
Viene inizializzato un nuovo oggetto di tipo soap_server.
Viene registrata la funzione selectomaincheck che è quella esportata dal Web services.
Infine il metodo service è quello che fisicamente invia la risposta al client.
Il nostro primo Web services è terminato: completo, operativo e funzionante!
Ritorniamo al client.
Il client che usa questo Web services è il seguente( il seguente esempio va salvato con
il seguente nome: controlladominio.php ):
<?php
require_once('nusoap/nusoap.php');
$parameters = array(
"domain" =>"salvatoreiacometta",
"domainextension" =>".it"
);
$soapclient = new soapclient('http://il-nostro-webservices/checkdomain.php');
$result = $soapclient->call('selectdomaincheck',$parameters);
print $result;
?>
Questa funzione del Web services ci restituisce “0” se il dominio che gli
passiamo, esiste, mentre ci restituirà “1” altrimenti.
Salvando il precedente file (checkdomain.php) sul server da noi realizzato e il
file controlladominio.php su un qualunque sito dal quale vogliamo usufruire del servizio
messo a disposizione dal nostro Web services, caricando la pagina
controlladominio.php, otterremo la risposta del Web services.
62
4.3.6 Un altro esempio: Il codice in PHP per interrogare Google
Il Web services di Google mette a disposizione una funzione grazie alla quale,
passandogli una chiave di ricerca (tramite la variabile 'q'), restituisce un array con gli
indirizzi dei siti che contengono la chiave specificata.
Possiamo, cioè, “inglobare” in un nostro sito il motore di ricerca di Google e
metterlo a disposizione ai nostri visitatori.
C’è qualche piccola restrizione: ad es. non si possono fare più di 1000 richieste
al giorno e l’array non può contenere più di 10 indirizzi di siti.
Nell’Appendice D è possibile trovare il “Codice in PHP per interrogare il Web
services di Google”.
63
Capitolo 5: Installazione e test del Server
64
5.1 Come iniziare
Dopo essermi documentato, ho ritenuto opportuno testare personalmente tutto
ciò che riguarda questi argomenti per fare poi delle applicazioni pratiche.
L’azienda per la quale lavoro come analista programmatore, mi ha dato la
possibilità di utilizzare una macchina alla quale è stato assegnato un indirizzo pubblico
(raggiungibile anche dall’esterno) sulla quale fare delle prove.
Ho installato Linux (Debian 30R2) e poi ho proceduto come descritto
nell’Appendice C al paragrafo 1: “Installare e configurare MySQL, Apache con SSL,
PHP, LDAP”.
In questa procedura è interessante sottolineare il fatto che non sono state usate
le locazioni standard che vengono proposte quando si installa qualche pacchetto, ma
sono state definite dei percorsi per ogni pacchetto da installare.
L’unica accortezza che bisogna avere è che durante l’installazione di un
pacchetto che richiede altri pacchetti, si deve specificare esplicitamente il percorso.
5.2 procedura per auto-certificare il server, per creare certificati-client e perriconoscere altri certificati-client
Nell’Appendice C al paragrafo 2 “Generazione dei certificati” è possibile trovare
la procedura per creare un certificato per il server appena realizzato , la procedura per
creare certificati per i clienti e quella per considerare validi i certificati-client rilasciati da
altre CA.
Una volta seguita la procedura che ci permette di generare un certificato-server
e dopo averlo installato sul nostro server, questo certificato ci viene esibito ogni volta
che effettuiamo una connessione di tipo “https”.
Sul browser “Internet Explorer” è possibile visualizzare questo certificato
cliccando sul lucchetto in basso a destra.
Per quanto riguarda i certificati-client, dopo aver eseguito la procedura per
crearne uno e una volta installato sul client, sarà possibile visualizzarlo semplicemente
andando sul browser (da es. Internet Explorer) nel menu
65
strumenti opzioni Internet contenuto certificati
Di seguito le informazioni generali del certificato-client:
e il dettaglio:
66
5.3 Cosa abbiamo ottenutoUna volta che avremo seguito le istruzioni contenute nei precedenti due
paragrafi, avremo ottenuto un Web server che supporta il protocollo https.
Questo vuol dire che, aprendo il nostro browser e digitando
http://81.118.52.132/
(dove 81.118.52.132 è l’indirizzo IP pubblico assegnato al server), verrà visualizzata la
pagina di default (ad es. index.html) che si trova nella cartella
“/usr/www/htdocs_senza_crittografia/”,
mentre digitando
https://81.118.52.132/
verrà visualizzata la pagina di default (ad es. index.html) che si trova nella cartella
“/usr/www/htdocs_con_crittografia/”.
Entrando un po’ di più nel dettaglio, si può affermare che la crittografia SSL
nell'ambito del protocollo HTML, viene applicata utilizzando una porta diversa da quella
standard. Di solito si tratta del numero 443, a cui si abbina la definizione ‘https’, mentre
sappiamo che la porta che in genere viene usata (‘http’) è la 80.
Inoltre, con questo tipo di installazione, visto che abbiamo installato PHP, sarà
ovviamente possibile realizzare pagine non solo .html ma anche .php.
E’ stato installato anche MySql, che non verrà utilizzato perché abbiamo
installato anche LDAP e quindi ogni informazione verrà archiviata tramite strutture
gerarchiche.
Personalmente in questo lavoro ho utilizzato MySql soltanto per immagazzinare
informazioni relative ai visitatori di questo server.
Infatti all’inizio di alcune pagine, ho incluso il seguente codice:
<? include ("connmysql.php");?>
<?
$ip=getip();
$host=gethostbyaddr($ip);
$pagina='index.php di http';
$query ="insert into visite (ip,host,data_visita,pagina) values ('$ip',
'$host', now(),'$pagina')" ;
$risultato=mysql_query( $query, $csql );
?>
67
cioè si inseriscono nella tabella “visite” l’ip e l’host del visitatore per avere la “storia”
delle visite.
Di “ PhpLDAPadmin” si è fatto, invece, un uso più intensivo.
Ricordo che PhpLDAPadmin è un browser LDAP scritto interamente in PHP, per
gestire un LDAP Server.
Tramite questo strumento sono stati creati dei profili, sono stati aggiunti,
modificati, cancellati degli attributi, ecc…
5.3.1 “Over https”
Vediamo cosa succede se scriviamo nel browser
https://81.118.52.132/
La prima cosa che potremo notare è la comparsa di questo avviso:
che ci garantisce che “navigando over https”, le informazioni scambiate con il sito non
possono essere visualizzate da altri utenti via Web.
Cliccando su “Ulteriori informazioni”, si legge che “…questo sito Web fornisce
una comunicazione protetta e dispone di un certificato valido. Comunicazione protetta
significa che le informazioni inviate al sito, quali il nome o il numero di carta di credito,
sono crittografate in modo da non poter essere lette o intercettate da altre persone. Il
certificato è una dichiarazione che garantisce la protezione di un sito Web. Un
certificato contiene informazioni che garantiscono che un sito Web è attendibile e che
nessun altro sito può assumere la sua identità. ”
Cliccando su OK, comparirà questa finestra:
68
Tramite questa finestra il client potrà scegliere quale dei suoi certificati-client in
suo possesso potrà esibire al server al quale si sta connettendo.
Si ricorda che il "certificato personale" attesta l'identità dell'utente. Questi dati
vengono utilizzati quando l'utente invia informazioni personali su Internet a un sito Web
che richiede un certificato attestante l'identità dell'utente. È possibile controllare
l'utilizzo che può essere fatto della propria identità tramite una chiave privata, che solo
l'utente conosce e che si trova esclusivamente nel suo computer.
Cliccando su “Ulteriori informazioni” si potrà leggere che “ Un certificato di
protezione, sia esso un certificato personale o un certificato di un sito Web, associa
una "chiave pubblica" a un'identità. Solo il proprietario del certificato conosce la
corrispondente "chiave privata". La "chiave privata" consente al proprietario di creare
una "firma digitale" o di decrittare informazioni crittografate con la corrispondente
"chiave pubblica". Inviando il proprio certificato ad altri utenti, si invia in realtà la propria
chiave pubblica e si consente ad essi di trasmettere informazioni crittografate, che
potranno essere decodificate e lette solo con la propria chiave privata.”.
Cliccando su “Visualizza certificato…” sarà visibile il certificato in dettaglio come
visto nel paragrafo 5.2
Cliccando su OK comparirà un’altra finestra:
69
cioè un’applicazione (Internet Explorer) sta tentando di accedere a dei dati protetti (i
dati del nostro certificato-client) e perciò richiede all’utente la possibilità di accedere a
questi dati.
Continuiamo cliccando su OK. Comparirà quest’altra finestra:
Qui ci sono dei messaggi di avviso.
Il primo ci informa che la società che ha rilasciato il certificato al server che
stiamo per visitare non è attendibile. Infatti bisogna tenere presente che il nostro server
è stato “auto-certificato”, cioè la società che lo ha certificato (il server stesso !) è
evidentemente non riconosciuta dal nostro browser (Internet Explorer). Per fare in
modo che questo primo messaggio di errore non compaia più, occorre installare sul
client con il quale stiamo navigando, il certificato della società che certificato il nostro
server (cioè il certificato del server stesso!).
Il secondo ci dice che il certificato-server non è scaduto.
Il terzo ci dice che il nome del certificato non coincide con il nome del sito. Infatti
il sito è “81.118.52.132” (il mio server non ha un DNS, cioè non ha un nominativo
alfabetico), mentre il nome del certificato è “CERT SITO CIOCCOLATO E AFFINI”.
70
Il primo è il terzo messaggio, comunque, non ci impediscono di continuare la
navigazione.
Cliccando su OK, finalmente siamo in grado di visualizzare la pagina richiesta.
In basso a destra (almeno nel browser Internet Explorer), compare il “rassicurante”
lucchetto:
Facendo doppio click sul lucchetto è possibile visualizzare il certificato-server.
Qui cliccando su “Installa certificato…” possiamo installare il certificato sul client e
quindi considerarlo attendibile in futuro.
Si ricorda che il certificato-server garantisce che nessun altro sito Web possa
assumere l'identità del sito originale.
Infine, se abbandoniamo la connessione sicura (cioè ci spostiamo da https a
http), il browser ci avvisa con il seguente messaggio:
71
cioè il sito Web al quale si desidera accedere non utilizza un protocollo di protezione e
le informazioni inviate e ricevute non saranno protette. Il sito non dispone di un
certificato e non è possibile verificarne l'identità.
5.4 Proviamo a fare dei testOra che abbiamo visto in pratica cosa succede, proviamo a fare qualche
variazione.
5.4.1 Modifichiamo il file di configurazione
Proviamo a modificare leggermente il file di configurazione di Apache.
Ricordo che con il tipo di installazione vista nei precedenti paragrafi, il file di
configurazione si trova nel seguente percorso:
/usr/www/conf/httpd.conf
Cerchiamo la riga
SSLVerifyClient……
Modificando questa riga è possibile scegliere se rendere obbligatorio o opzionale la
verifica del certificato-client.
Scriviamo
SSLVerifyClient optional
e riavviamo il server.
Ora proviamo ad andare di nuovo con il browser su
https://81.118.52.132/
E’ immediato constatare che anche se ora il client non esibisce nessun certificato, avrà
ugualmente la possibilità di visualizzare le pagine che si trovano in
“/usr/www/htdocs_con_crittografia/”.
Se, invece, scriviamo
SSLVerifyClient require
E riavviamo il server, se il client non esibisce un certificato-client valido, non avrà la
possibilità di visualizzare nessuna pagina !
72
5.4.2 Prelevare con PHP i dati del certificato
Ora che siamo su una connessione protetta e abbiamo la certezza che il client
ha esibito un certificato-client valido, può essere interessante sapere come prelevare i
dati del suo certificato e utilizzarli per un qualunque scopo (fare delle ricerche su un
data base, immagazzinarli per scopi futuri, ecc…).
Ci sono delle semplici istruzioni in PHP che ci permettono di fare questo:
<?php
//----------------- DATI CERTIFICATO CLIENT -----------------------------
$sslversion = getenv("SSL_VERSION_LIBRARY"); //SSL Version used
$sslcaname = getenv("SSL_CLIENT_I_DN_CN"); //Your Certificate are signed by
$sslusername = getenv("SSL_CLIENT_S_DN_CN"); //Your Name
$ssluserdetails = getenv("SSL_CLIENT_S_DN"); //Your Certificate details
$sslexpire = getenv("SSL_CLIENT_V_END"); //Your Certificate will expire on
//----------------------------------------------------------------------------
-----------
?>
Ad esempio nella variabile “$sslusername ” troveremo il CN (Common Name) del
certificato-client esibito, in “$sslexpire ” la data di scadenza, ecc…
5.4.3 L’uso di uno “Sniffer”
Una ultima considerazione su questo test si può fare utilizzando uno “sniffer” ,
cioè un programma che analizza e monitorizza il traffico di rete.
Se si avvia lo sniffer durante una normale connessione (cioè “over
http”),qualunque dato il client invia al server, compare in chiaro nei pacchetti e quindi
può essere banalmente letto e utilizzato per “svariati” scopi.
Nell’Appendice B al paragrafo “B.2 Una semplice osservazione sulla
connessione sicura”, lo sniffer è stato avviato mentre ci si apprestava a consultare la
posta sul Provider “Libero”.
Se la stessa operazione si fa su una connessione sicura (“over https” ), il
contenuto dei pacchetti è crittografato e quindi illeggibile e, ormai lo sappiamo bene,
tutto ciò che il client cifra con la chiave pubblica del destinatario, il destinatario (server)
decifra con la propria chiave privata.
73
Capitolo 6: Interfacciamento dell'infrastruttura con tecnologia Web Services
74
6.1 La mia scelta: Utilizzare NUSOAP e CURL
Per la mia tesi ho ritenuto opportuno orientarmi su strumenti utilizzabili con
PHP. Di seguito il dettaglio delle mie scelte.
6.1.1 Installare nusoap per applicazioni server-client SOAP in PHP
Come si è già detto, SOAP (Simple Object Access Protocol) e' un protocollo di
comunicazione basato su XML che permette lo scambio di informazioni tra programmi
scritti anche in linguaggi differenti.
Solitamente le informazioni relative a SOAP "viaggiano" sulla stessa porta
utilizzata dai server web (porta 80), per cui non e' necessario cambiare le impostazioni
dei firewall presenti sulla rete.
Nel caso generale, il sistema e' composto da un programma client che esegue
delle richieste SOAP e da un server che risponde alle richieste SOAP.
6.1.2 Cos’è NUSOAP
NUSOAP è un insieme di classi sviluppate da Dietrich Ayala's SOAPx4
(http://dietrich.ganx4.com/nusoap/). Esistono molte implementazioni di SOAP per PHP,
tuttavia nusoap sembra essere piuttosto affidabile e sta diventando nel tempo uno
standard di fatto.
Nusoap permette la costruzione di applicazioni server e client in PHP basate sul
protocollo SOAP.
Tramite nusoap e' possibile creare e utilizzare in modo facile e rapido delle
funzionalità utilizzabili mediante protocollo SOAP.
75
6.1.3 Come funziona PHP + NUSOAP
Nel caso di PHP + NUSOAP, il server viene implementato mediante l'utilizzo di
Apache Server e PHP a cui vengono aggiunte le funzionalità SOAP tramite la libreria
nusoap.
Nusoap consiste del file nusoap.php da importare negli script PHP che creano il
servizio lato server, e negli script che implementano (eventualmente) il lato client in
PHP.
Nusoap può essere scaricato dal sito
http://dietrich.ganx4.com/nusoap/
L'installazione di nusoap e' banale, in quanto consiste unicamente nella copia
del file scaricato in una directory scelta a piacere, ad esempio in /usr/www/strumenti e
nell'importazione del file stesso negli script PHP mediante l'istruzione
require_once('/var/www/strumenti/nusoap.php');
6.2 Un esempio banale: il web services che concatena due stringhe
Per cominciare a capire come realizzare praticamente un Web services,
occorre realizzare sia il file che viene utilizzato per invocare il Web services, sia il file
da caricare sul Web services e che viene richiamato da chi vuole usufruire dei servizi
messi a disposizione del Web Services.
Vogliamo realizzare un Web services che fornisce il servizio di
“concatenamento di due stringhe”, cioè riceve due stringhe e restituisce una stringa
composta dal concatenamento delle due (!).
Ovviamente è un servizio banalissimo, ma lo realizziamo semplicemente a
scopo didattico: i Web services in genere mettono a disposizione servizi molto più
complessi !
Di seguito il file da caricare su un sito dal quale si vuole richiamare il nostro
Web services:
76
"esempio-client.php"
<?php
require_once('./nusoap/nusoap.php');
$parameters = array(
"primo" =>"abcde",
"secondo" =>"fghil"
);
$soapclient = new soapclient('http://xx.xxx.xx.xxx/webservices/esempio-
server.php');
$result = $soapclient->call('esempio_funzione',$parameters);
echo 'Il risultato è : ';
print $result;
echo '<br>';
echo '----------------------------------------------------------------';
echo '----------------------------------------------------------------';
echo 'Request: <xmp>'.$soapclient->request.'</xmp>';
echo '----------------------------------------------------------------';
echo '----------------------------------------------------------------';
echo 'Response: <xmp>'.$soapclient->response.'</xmp>';
echo '----------------------------------------------------------------';
echo '----------------------------------------------------------------';
echo '----------------------------------------------------------------';
echo 'debug_str: <xmp>'.$soapclient->debug_str.'</xmp>';
echo '----------------------------------------------------------------';
echo '----------------------------------------------------------------';
?>
Si può notare che viene inclusa la libreria nusoap.
Le due stringhe che passeremo al Web services sono “primo” (abcde) e “secondo”
(fghil).
Nella variabile “$result” il Web services restituirà il risultato, cioè la
concatenazione delle due stringhe che “esempio-client.php” gli passa.
77
A scopo didattico abbiamo stampato a video (tramite una serie di “ echo ”) la
richiesta (request) e la risposta (response) (si potrà notare che è tutto in XML: merito di
NUSOAP).
La funzione che il Web services mette a disposizione si chiama
“esempio_funzione”.
Questa funzione si trova in:
“http://81.118.52.132/webservices/esempio-server.php”
Di seguito il file da caricare sul nostro Web services:
"esempio-server.php"
<?
function esempio_funzione ($primo,$secondo)
{
$risultato=$primo.$secondo;
return $risultato;
}
require_once('./nusoap/nusoap.php');
$server=new soap_server;
$server->register('esempio_funzione');
$server->service($HTTP_RAW_POST_DATA);
?>
E’ presente la funzione “esempio_funzione” che concatena le due stringhe
passate.
E’, inoltre, presente la onnipresente libreria NUSOAP.
Il risultato (il valore della funzione) viene restituito a chi ha invocato il Web
services.
Quindi, riassumendo, tramite "esempio-client.php" richiamiamo la function
“esempio_funzione” messa a disposizione dal Web services e gli passiamo:
"primo" =>"abcde",
"secondo" =>"fghil"
Il Web services ci restituirà : "abcdefghil"
78
6.3 Funzioni CURL, Client URL Library
Ho provato a realizzare l’esempio illustrato al Capitolo 4 relativo al paragrafo
“4.3.5 Dal Client al Server” (ricordiamo che il servizio offerto dal Web services così
realizzato, fornisce “0” se il dominio che gli passiamo esiste, “1” altrimenti).
Relativamente ai due file checkdomain.php e controlladominio.php, è stato
copiato il primo in
/usr/www/htdocs_senza_crittografia/checkdomain.php
dove “htdocs_senza_crittografia” è la cartella di default, del server che abbiamo
realizzato, raggiungibile tramite la porta 80, cioè tramite http,
e il secondo in
www.salvatoreiacometta.it/tesi/controlladominio.php
ed è stato constato che tutto funziona.
Quando, però si sposta il primo file in
/usr/www/htdocs_con_crittografia/checkdomain.php
(dove “htdocs_con_crittografia” è la cartella di default raggiungibile tramite la porta 443,
cioè tramite https)
il servizio non è più utilizzabile !
Infatti il problema è che per far viaggiare XML su https, occorre caricare una
libreria in PHP: Client URL Library.Ora il problema è che il PHP messo a disposizione da Aruba (dove risiede il sito
www.salvatoreiacometta.it) non ha queste librerie. Questo vuol dire che da
www.salvatoreiacometta.it/tesi non si possono fare chiamate tramite soap a un Web
79
services ATTRAVERSO HTTPS (cioè utilizzando curl ! ) ma si possono fare chiamate
tramite soap a un Web services solo attraverso HTTP.
Quindi per fare questa ulteriore prova (cioè richiamare una funzione di un Web
services attraverso https), si fa fungere il server da noi realizzato, sia da server Web
(che ospita la pagina che interroga il Web services) che da Web services stesso.
Ritornando alla Client URL Library, c’è da dire che PHP supporta libcurl, una libreria
creata da Daniel Stenberg, che permette di collegarsi e comunicare con parecchi tipi di
server e con parecchi tipi di protocolli. Libcurl al momento supporta i protocolli http,
https, ftp, gopher, telnet, dict, file, e ldap. libcurl supporta anche i certificati HTTPS,
HTTP POST, HTTP PUT, l'upload via FTP (questo può essere ottenuto anche con
l'estensione ftp di PHP), upload attraverso una form HTTP, proxy, cookie e
autenticazione con utente e password.
6.4 Un esempio completo: web services su https che interroga LDAP
Un esempio che abbraccia un po’ tutto quello che si è studiato fino ad ora è il
seguente:
Tramite il “Web-based LDAP browser” (l’applicazione in php per gestire LDAP
server) creiamo un utente che abbia come CN (common name) il CN del certificato-
client che abbiamo rilasciato al cliente.
Inoltre, l’attributo: “description” lo settiamo a “ABILITATO”.
Creiamo una funzione in PHP che effettua una ricerca in LDAP partendo da un
CN e restituisce il valore dell’attributo “description”.
Creiamo un file php che richiama questa funzione (messa a disposizione dal
nostro Web services) e, in base al valore dell’attributo “ description ” decide di far
proseguire o meno il client che si trova a visitare il sito.
Ovviamente questo file php deve essere salvato in
/usr/www/htdocs_con_crittografia/daticlient.php
altrimenti non sarà in grado di prelevare il CN del certificato-client.
80
Ecco il file “daticlient.php”:
<?phprequire_once('./nusoap/nusoap.php');
//----------------- DATI CERTIFICATO CLIENT -----------------------------$sslversion = getenv("SSL_VERSION_LIBRARY"); //SSL Version used$sslcaname = getenv("SSL_CLIENT_I_DN_CN"); //Your Certificate are signed by$sslusername = getenv("SSL_CLIENT_S_DN_CN"); //Your Name$ssluserdetails = getenv("SSL_CLIENT_S_DN"); //Your Certificate details$sslexpire = getenv("SSL_CLIENT_V_END"); //Your Certificate will expire on//---------------------------------------------------------------------------------------
$parameters = array( "CN" => $sslusername);
$soapclient = newsoapclient('https://81.118.52.132/webservices/restituisciclient.php');
$result = $soapclient->call('estraidati',$parameters);
echo 'STATO CLIENT: ';echo '<br>';
print $result;echo '<br>';?>
ed ecco il file da salvare sul Web services (nel nostro caso su
/usr/www/htdocs_con_crittografia/ restituisciclient.php)
<?function estraidati ($CN){
$ldap_server = "ldap://81.118.52.132/";$auth_user = "cn=Manager,dc=my-domain,dc=com";$auth_pass = "nutella";
// Set the base dn to search the entire directory.$base_dn = "DC=my-domain, DC=com";
$filter = "(cn=$CN)";
// connect to serverif (!($connect=@ldap_connect($ldap_server))) { die("Could not connect to ldap server");}
// bind to serverldap_set_option($connect, LDAP_OPT_PROTOCOL_VERSION, 3); //senzaquesto,ldap_bind dà errore
81
if (!($bind=@ldap_bind($connect, $auth_user, $auth_pass))) { die("Unable to bind to server");}
// search active directoryif (!($search=@ldap_search($connect, $base_dn, $filter))) { die("Unable to search ldap server");}
$number_returned = ldap_count_entries($connect,$search);$info = ldap_get_entries($connect, $search);
//echo "The number of entries returned is ". $number_returned."<p>";$conteggio=$number_returned;
for ($i=0; $i<$info["count"]; $i++) {
$Description=$info[$i]["description"][0]; }
return $Description;}
require_once('./nusoap/nusoap.php');
$server=new soap_server;$server->register('estraidati');$server->service($HTTP_RAW_POST_DATA);?>
Quindi in questo modo potremo sapere se il client che sta visitando il nostro sito
è “ABILITATO” per un determinato servizio, fornendo il CN del certificato, che ci sta’
esibendo, al Web services e analizzando il risultato che il Web services, dopo che ha
fatto dei controlli su una struttura LDAP, ci restituisce.
6.4.1 La stampa di Request e Response
Per curiosità, nell’Appendice D (“D.1.3 La stampa di Request e Response”)
viene riportato il risultato dell’applicazione precedente.
Si potrà notare che “STATO CLIENT” assume il valore “ABILITATO”, questo
vuol dire che il Web services, in LDAP ha trovato il CN del certificato-client esibito dal
cliente e il valore del campo “Description” è “ABILITATO”.
Questo risultato verrà restituito a chi ha invocato il Web services.
Da notare, inoltre “ Request ” e “ Response” convertiti in XML dalla libreria
NUSOAP.
82
6.5 Applicazioni pratiche realizzate
La applicazioni pratiche realizzate sono visibili all’indirizzo:
http://81.118.52.132
questo, infatti, è l’indirizzo pubblico assegnato al server da me realizzato (a proposito: il
suo nome è “nutella” !).
A questo indirizzo si trova un sito web realizzato in Swish formato da alcune pagine:
- nella home page è possibile visionare la mia tesi
- nella pagina “L’obiettivo” è spiegato molto brevemente il senso di queste
applicazioni
- nella pagina “Certificati” è possibile scaricare certificati-client da usare per le prove
- nella pagina “Servizi” ci sono quattro servizi offerti dal sito
- nella pagina “Altro” c’è un servizio leggermente diverso rispetto ai primi quattro
Questo sito web è illustrato un po’ più in dettaglio nell’Appendice D al paragrafo “D.2
Un sito per il test”.
Di seguito una sintesi delle cinque applicazioni pratiche realizzate sul sito.
Si ricorda che il certificato-client rimane attivo per tutta la sessione, quindi se si
vogliono testare più servizi con diversi certificati-client, occorre chiudere e riaprire il
browser andando di nuovo sul sito web.
6.5.1 Rivista on-line
La prima applicazione realizzata consiste nel mettere a disposizione degli
articoli di una rivista solo ad alcuni “visitatori”.
Per testare questa applicazione occorre scaricare e installare un certificato-
client (dal nome “certificato rivista”) abilitato a questo servizio, reperibile nella sezione
“Certificati”.
83
Ovviamente questo certificato è scaricabile solo perché siamo in fase di test. La
procedura reale consisterebbe nel richiederlo ad un ente certificatore che, dopo i dovuti
controlli, rilascia il certificato (vedere Appendice C al paragrafo “ C.2 Generazione dei
certificati”).
Nella sezione “Servizi” è presente un link a questo servizio.
Tra i vari servizi offerti, si sceglie “RIVISTA ON LINE”.
84
Questa è la videata che compare:
Da notare che siamo ancora “su http” (vedere indirizzo in alto a sinistra), e che è
comparsa la finestra che ci informa che stiamo per andare su una connessione protetta
(“over https”).
Cliccando su OK, il browser ci chiederà quale dei nostri certificati-client vogliamo
esibire al server:
85
Qui sceglieremo il certificato “CLIENT RIVISTA” precedentemente scaricato.
In effetti qui stiamo fornendo la nostra CHIAVE PUBBLICA al server.
Subito dopo tocca al server:
86
Ci sono i soliti avvisi analizzati nel capitolo 5 al paragrafo “5.3 Cosa abbiamo ottenuto”.
In questa fase è il server che ci sta fornendo la sua CHIAVE PUBBLICA.
Ora siamo in “https”.
Con delle semplici istruzioni in PHP ( viste nel capitolo 5, paragrafo “5.4
Proviamo a fare dei test ”), preleviamo il CN (Common Name) del certificato esibito.
Ora entra in gioco il Web Services realizzato.
Si ricorda che il servizio consiste nel ricevere il CN, fare delle ricerche su un
LDAP Server usando come filtro proprio il CN, rilevare alcune informazioni relative al
certificato e restituirle al sito che ha invocato il web services (vedere Appendice C,
paragrafo “C.3.3 Il WSDL del mio Web Services: come utilizzarlo.”).
Il certificato-client è valido (altrimenti non saremmo riusciti ad arrivare a questo
punto del sito), occorre vedere se è abilitato.
Invochiamo il Web Services passandogli il CN.
Sia la richiesta che la risposta è in XML (vedere Appendice D, paragrafo “D.1.3
La stampa di Request e Response”).
Con l’ausilio di “PhpLDAPAdmin”, seguiamo ciò che sta facendo il web
services.
87
Tra i CN in LDAP individua quello uguale a “CLIENT_RIVISTA”, legge il valore
dell’attributo “description” e lo restituisce al sito che lo ha invocato.
Se l’attributo ha il valore che ci si aspetta (ad es. “abilitato”, oppure “abilitato alla
rivista”), si dà la possibilità al “cliente” di proseguire e quindi di leggere gli articoli.
In caso contrario, il “cliente” termina la sua navigazione.
Di seguito una figura esplicativa di tutto quello che accade:
88
6.5.2 Assistenza on-line
Con un procedimento simile a quello esposto nel paragrafo precedente, diamo
o meno la possibilità a un “cliente” di poter compilare un form e quindi di inviare un
messaggio di aiuto a un team di tecnici per ottenere un’assistenza on-line.
Ecco la figura che illustra il processo:
1 Il browser effettua una connessione “over https” con il web server 81.118.52.132
2 Il client esibisce il suo certificato
3 Il server invoca il web services con stringhe in xml…
4 …e gli fornisce il CN del certificato client
5 Il web services interroga il server LDAP utilizzando come filtro il CN
6 Il server LDAP raccoglie informazioni relative al client e le fornisce al web services
7 Queste informazioni vengono restituite al server che ha invocato il servizio del web services
8 Il server da la possibilità al client di compilare un form di “richiesta assistenza on-line”
9 I tecnici ricevono la richiesta
89
6.5.3 Consultazione Bilanci
Anche qui il procedimento è analogo a quello precedente.
Se il certificato esibito dal client è abilitato a questo servizio, sarà possibile visualizzare
un bilancio riservato.
La figura seguente chiarisce il procedimento che è molto simile a quello
illustrato nel paragrafo 6.5.1:
90
6.5.4 Consultazione Codici Fiscali
Questo servizio può nascere dall’esigenza di determinare se un codice fiscale
esista veramente. Infatti anche se un codice fiscale e' valido (il check-sum e' corretto),
non si può affermare con certezza che esiste. Questo servizio mette a disposizione
una lista di codici fiscali esistenti ma solo ai clienti che sono in possesso di un
certificato valido e che sia abilitato a questo servizio.
Nella figura che segue viene chiarito questo procedimento:
91
6.5.5 Applicazione da un server esterno (Aruba)
Questa applicazione nasce dai problemi derivati dalla seguente prova:
dal mio sito (www.salvatoreiacometta.it) ho provato a invocare la funzione messa a
disposizione dal mio web services. Si ricorda che questa funzione, passando il
Common Name del certificato Client, fornisce delle informazioni relative al certificato
stesso (o, più precisamente, il nome dei servizi ai quali è abilitato).
Mi sono reso subito conto che non era possibile fare questo perché ARUBA non
mette a disposizione il pacchetto CURL (la libreria di PHP che permette di far
"viaggiare" le informazioni XML su HTTPS).
Ho allora pensato di aggirare questo problema chiamando una pagina del mio
server (il server “nutella” o “81.118.52.132”) da www.salvatoreiacometta.it e poi
spostarmi su HTTPS all'interno del mio server per invocare il mio web services.
Solo così è possibile ricevere informazioni relative al certificato-client.
Alla fine ritorneremo sul sito di partenza richiamando cioè, dal server “nutella”,
una pagina che si trova su www.salvatoreiacometta.it/tesi :
arrivando su questa pagina, non sappiamo cosa sia successo nel server (“nutella”), ne
tantomeno nel web services.
Non conosciamo nemmeno i dati relativi al certificato che il cliente ha esibito.
Sappiamo solo che il web services, analizzando i dati in LDAP, ha determinato il o i
servizi per i quali è abilitato il cliente e quindi posso procedere o non procedere nel mio
sito (in funzione della risposta ottenuta).
Nella figura seguente si cerca di chiarire questo procedimento che è un pò
diverso rispetto a quelli visti precedentemente:
92
1 Il browser si collega al sito www.salvatoreiacometta.it tramite una connessione http
2 Questo sito non è in grado di richiedere un certificato-client perche il server sul quale risiede non è
abilitato. Il client viene, allora, indirizzato “over https” su una pagina che risiede su un altro server.
3 Il nuovo server (81.118.52.132) si fa riconoscere
4 Il client invia il suo certificato
5 Il server invoca il servizio offerto dal web services…
6 …e gli passa il CN del client
7 Il web services interroga il server LDAP facendo una ricerca per CN
8 Il server LDAP invia le informazioni relative al client al web services
9 Il web services restituisce al server 81.118.52.132 i dati richiesti
10 Si ritorna a una pagina che si trova sul sito www.salvatoreiacometta.it residente sul server Aruba
93
6.5.6 L’utilità del “Single Sign On”
Osservando le applicazioni precedenti si può dedurre che possiamo abilitare il
client ad altri servizi o bloccarlo su alcuni servizi per i quali è già abilitato,
semplicemente modificando il contenuto del campo “description” relativo al suo CN
presente nel server LDAP (che il servizio del Web Services consulta per reperire
informazioni relative al client).
Il client non deve quindi richiedere altri certificati per poter usufruire di altri
servizi né deve preoccuparsi di iscriversi presso altri enti che erogano altri servizi (cioè
non occorre che duplichi i suoi dati).
6.5.7 Il WSDL del mio Web Services
Il web services realizzato fornisce un servizio ben preciso:
riceve il CN (Common Name) del certificato-client di un visitatore di un determinato
sito, effettua una ricerca su un LDAP Server utilizzando come filtro appunto il CN
ricevuto, determina alcune informazioni relative a questo certificato ( ad es. “cliente
inaffidabile”, “cliente sicuro”, ecc…) e le passa al sito che ha invocato il web services.
Ora il sito, in base a ciò che il web services ha restituito, può decidere se far continuare
o meno nella navigazione il suo “visitatore”.
Per capire come utilizzare il servizio offerto dal mio web services, occorre
consultare il paragrafo “C.3.3 Il WSDL del mio Web Services: come utilizzarlo”
dell’Appendice C.
6.6 Usufruire dei servizi di un web services solo se si è in possesso di uncertificato-client valido
Ho voluto fare questo test:
Ho preso il file “esempio_server.php” che, ricordo, rappresenta il servizio del mio Web
services che restituisce la concatenazione delle due stringhe passate come variabili, e
l'ho spostato su https.
Ho invocato questo servizio con una pagina che risiede su http.
Questo esperimento non porta a nessun risultato!
94
Infatti, le pagine di un servizio non possono risiedere su un server dove è obbligatorio
l’esibizione di un certificato-client.
Questo perché nusoap, per convertire in XML la Request e la Response, richiama i
seguenti link:
http://schemas.xmlsoap.org/soap/encoding/
http://schemas.xmlsoap.org/soap/envelope/
http://www.w3.org/2001/XMLSchema
http://www.w3.org/2001/XMLSchema-instance
http://soapinterop.org/xsd
http://testuri.org
Quando questi siti forniscono i dati richiesti da nusoap, ovviamente non
esibiscono nessun certificato-client ! Se il Web services ne esige uno (perché le sue
pagine sono “over https” con “verifica-client” obbligatoria), questi dati non possono
essere forniti e l’esperimento fallisce.
L’unico modo per usufruire dei servizi di un Web services solo dopo aver esibito
un certificato-client valido, è quello adottato nell’esempio “6.5.5 Applicazione da un
server esterno (Aruba)”, cioè, prima di invocare il Web services, si viene indirizzati su
una pagina (over https) che obbliga l’esibizione di un certificato valido.
95
Appendice A: Definizioni e abbreviazioni
96
AIPA: Autorità per l’Informatica nella Pubblica Amministrazione.
Venne posta in essere dal decreto legislativo del 12 febbraio 1993, n. 196, il quale
fissava "Norme in materia di sistemi informativi automatizzati delle amministrazioni
pubbliche".
Soppressa nel 2003, sostituita da un organismo simile, ma forse meno indipendente
dal Governo: la CNIPA
Apache: è un web server per il protocollo HTTP, designato per girare come un
processo standalone, senza cioè chiedere l'appoggio ad altre applicazioni o
direttamente all'utente. Per fare ciò, Apache, una volta che sia stato avviato, crea dei
sottoprocessi (comunemente e meglio detti "children processes") per poter gestire le
richieste: questi processi, comunque, non potranno mai interferire con il processo
maggiore, ma può succedere l'opposto: mandando un segnale di stop a questo, anche
i children saranno terminati.
Client: Un client e’ il programma che, in un sistema client/server, inoltra le richieste
dell’utente ad un programma server. L’esempio più comune e’ sicuramente il browser
che l’utente utilizza per inviare richieste ai web server cosi da poter visionare le pagine
che interessano.
CNIPA: Centro Nazionale per l’Informatica nella Pubblica Amministrazione.
CURL: Client URL Library. PHP supporta libcurl, una libreria creata da Daniel
Stenberg, che permette di collegarsi e comunicare con parecchi tipi di server e con
parecchi tipi di protocolli. Libcurl al momento supporta i protocolli http, https, ftp,
gopher, telnet, dict, file, e ldap. libcurl supporta anche i certificati HTTPS, HTTP POST,
HTTP PUT, l'upload via FTP (questo può essere ottenuto anche con l'estensione ftp di
PHP), upload attraverso una form HTTP, proxy, cookie e autenticazione con utente e
password.
Debian: è un sistema operativo (OS) libero (free). Utilizza Linux come kernel (la parte
centrale di un sistema operativo), ma molti dei programmi di utilità vengono dal GNU
project.
97
Debian GNU/Linux fornisce più di un semplice OS: viene distribuito con oltre 8710
pacchetti, programmi già compilati e impacchettati in modo tale da permettere
installazioni facili sulla macchina.
Firma elettronica: insieme dei dati in forma elettronica, allegati oppure
connessi tramite associazione logica ad altri dati elettronici, utilizzati come metodo di
autenticazione informatica.
Firma elettronica avanzata: firma elettronica ottenuta attraverso una procedura
informatica che garantisce la connessione univoca al firmatario e la sua univoca
identificazione, creata con mezzi sui quali il firmatario può conservare un controllo
esclusivo e collegata ai dati ai quali si riferisce in modo da consentire di rilevare se i
dati stessi siano stati successivamente modificati.
Hash: Tecnicamente la firma digitale è basata su una funzione di hash non invertibile
ed uno schema di cifratura a chiave pubblica. La funzione di hash non invertibile (detta
anche valore di controllo o checksum) verifica l’eventuale modifica dei dati durante la
trasmissione, accodando al messaggio un valore di controllo ottenuto effettuando
alcune operazioni sui dati protetti. Scopo di tale funzione è quello di fornire al
destinatario del messaggio un mezzo per individuare le eventuali alterazioni dei dati
trasmessi. La funzione hash produce una sorta di impronta digitale del messaggio, di
dimensioni molto più piccole del messaggio stesso.
HTTP: (Hyper Trasport Protocol). Protocollo con cui file ipertestuali vengono trasmessi
lungo la WWW.
HTTPS: (Hyper Trasport Protocol Secure). La crittografia SSL nell'ambito del
protocollo HTML, viene applicata utilizzando una porta diversa da quella standard. Di
solito si tratta del numero 443, a cui si abbina la definizione `https'.
Interoperabilità: Il concetto di interoperabilità indica la possibilità per un sistema di
protocollo informatico ricevente di una certa amministrazione di trattare
automaticamente le informazioni trasmesse dal sistema di protocollo informatico
98
mittente di un’altra amministrazione al fine di automatizzare le attività e i processi
sottostanti.
LDAP: Il protocollo LDAP (Lightweight Directory Access Protocol) è costituito da una
serie di protocolli utilizzati per accedere ai servizi sullo standard X.500 per la
condivisione di directory. organizza le informazioni in ordine gerarchico servendosi di
directory che sono in grado di immagazzinare numerose informazioni e possono anche
essere utilizzate a mo' di NIS (Network Information Service), permettendo a chiunque
di accedere al loro account da qualsiasi macchina presente sulla rete LDAP abilitata.
Mysql: è il database open source per eccellenza. Cresciuto molto in questi anni, è
diventato il DBMS più utilizzato dalla comunità open source e apprezzato anche da chi
scrive pagine con tecnologie diverse da PHP e su server diversi da Linux.
NUSOAP: Nusoap e' una libreria che permette la costruzione di applicazioni server e
client in PHP basate sul protocollo SOAP.
Tramite nusoap e' possibile creare e utilizzare in modo facile e rapido delle funzionalità
utilizzabili mediante protocollo SOAP.
OpenSSL: Il progetto OpenSSL è uno sforzo collaborativo per lo sviluppo di un tool
robusto per l'implementazione del Secure Sockets Layer (SSL v2/v3) e Transport
Layer Security (TLS v1) così come anche una libreria per la crittografia per ogni
settore.
PHP: è un modulo aggiuntivo per web servers che permette di creare delle pagine web
dinamiche.
In pratica, una pagina in Php è composta sia da tag html, sia da parti in codice di
programmazione Php. Ogni porzione di codice, limitato entro i tag "<?php" e "?>",
viene eseguito prima di essere inviato all'utente che ne fa richiesta.
PhpLDAPadmin: è un browser LDAP per gestire un LDAP Server. E’ scritto
interamente in PHP.
99
Phpmyadmin: è uno strumento scritto in PHP per poter amministrare MySql attraverso
il Web.
PKCS: Public Key Cryptography Standards
RA: Registration Authority (Centro di Registrazione)
Entità responsabile dell'identificazione e dell'autenticazione dei soggetti della
certificazione, ma che non è una CA e, pertanto, non firma né emette certificati. La RA
procede al riconoscimento delle persone che si recano fisicamente ai propri sportelli e
ne raccoglie dati anagrafici, tipo di servizio, etc., comunicandoli in modalità protetta alla
CA.
Server: e’ un programma che fornisce dei servizi ad altri programmi dello stesso (ma
anche di altri) computer ma è anche il computer in cui e’ operativo il programma server.
Nei sistemi client/server un server e’ un programma che elabora e processa le richieste
che gli arrivano dal client.
Single Sign On: In un'applicazione "Single Sign On" l'utente deve autenticarsi una
volta sola e poi i vari client si occuperanno di ricevere dall'applicazione con cui l'utente
si è autenticato le credenziali necessarie per verificare l'identità dell'utente.
Una applicazione di questo tipo è fondamentale per evitare problemi di sicurezza
riguardanti la diffusione della password degli utenti. Con questo sistema infatti nessuna
applicazione ha bisogno della password dell'utente per verificarne l'identità.
Sniffer: Programma che monitorizza e analizza il traffico di rete.
SOAP: (Simple Object Access Protocol) e' un protocollo di comunicazione basato su
XML che permette lo scambio di informazioni tra programmi scritti anche in linguaggi
differenti.
Ad esempio, tramite SOAP e' possibile creare delle funzioni in PHP e utilizzarle in
Visual Basic 6.
Solitamente le informazioni relative a SOAP "viaggiano" sulla stessa porta utilizzata dai
server web (porta 80), per cui non e' necessario cambiare le impostazioni dei firewall
presenti sulla rete.
100
Nel caso generale, il sistema e' composto da un programma client che esegue delle
richieste SOAP e da un server che risponde alle richieste SOAP.
Policy o Certificate Policy
Definizione delle regole generali che indicano in che contesto, a che dominio e con
quali modalità di servizio un certificato viene utilizzato. Tutte le regole di servizio
vengono poi definite, nel dettaglio, dal documento di Certification Practice Statement (o
CPS).
Web Server: e’ un programma che, utilizzando il modello client/server e il protocollo
HTTP, fornisce i file che costituiscono una pagina web agli utenti che ne fanno richiesta
utilizzando un programma client: il browser. Ogni computer che contiene un sito web
deve avere un programma web server.
Tra i programmi web server i più utilizzati sono: Apache e Microsoft Internet
Information Server (IIS).
Web Services: è un'interfaccia che descrive una collezione di operazioni, accessibili
attraverso una rete mediante messaggistica XML
WSDL: file che descrive le operazioni supportate dal Web Service, i parametri richiesti
per funzionare ed il tipo di dati che vengono restituiti. Questi file WSDL (Web Services
Description Language) sono normali file XML che possono essere chiamati
direttamente dal browser in modo da visualizzare la descrizione della struttura delle
interfacce di chiamata e risposta
XML: L'Extensible Markup Language è una tecnologia che serve a creare linguaggi di
markup che descrivono i dati di qualsiasi tipo e in modo strutturato. Xml è quindi un
metalinguaggio cioè un sistema linguistico per mezzo del quale è possibile analizzare i
simboli e le strutture del linguaggio ordinario, consentendo così di creare dati
intelligenti.
101
Appendice B: Sintesi sulla certificazione digitale
102
B.1 I punti da fissare
B.1.1 Necessità e soluzione
Necessità:
• Riservatezza: la comunicazione è stata intercettata?
• Autenticazione: l’utente è veramente chi dice di essere?
• Autorizzazione: ogni utente può accedere solo alle risorse cui ha diritto.
• Integrità: i dati ricevuti sono proprio quelli spediti?
• Non ripudio: il mio interlocutore può ritrattare quello che ha detto?
• Disponibilità: il mezzo di comunicazione è stato reso inutilizzabile?
Crittografia:
La crittografia risponde alle necessità di sicurezza.
– Riservatezza: cifratura.
– Autenticazione: firma digitale e certificati.
– Integrità: one-way hash(message digest).
– Non ripudio: integrità e autenticazione.
103
B.1.2 Cifratura
Cifratura a chiave privata:
• Richiede una chiave segreta nota solo ai corrispondenti.
• La stessa chiave serve per cifrare e decifrare il messaggio.
104
Cifratura a chiave pubblica:
Ogni utente ha due chiavi: una privata ed una pubblica:
– dalla chiave pubblica è praticamente impossibile scoprire quella privata;
– quello che si cifra con una, si può decifrare solo con l’altra.
Non è necessario nessuno scambio di chiavi segrete: il mittente cifra con la chiave
pubblica del destinatario e il destinatario decifra con la propria chiave privata;
105
A è il client
B è il server
- Nella prima figura in alto a sinistra la chiave è quella PUBBLICA DI B
- Nella seconda figura in alto a destra la chiave è quella PRIVATA DI B
- Nella terza figura in basso a sinistra la chiave è quella PRIVATA DI A
- Nella quarta figura in basso a destra la chiave è quella PUBBLICA DI A
A prende la chiave pubblica di B dal certificato server (visibile cliccando sul lucchetto
nel browser)
B.1.3 Autenticazione
• A calcola l’hash del messaggio e lo cifra con la sua chiave privata: l’hash cifrato è la
firma digitale.
• A invia il messaggio firmato a B.
• B ricalcola l’hash sul messaggio e lo confronta con quello inviato, dopo averlo
decifrato con la chiave pubblica di A.
• Se i due hash sono uguali, il messaggio non è stato modificato e A non può
ripudiarlo.
106
La firma digitale rende sicuro un messaggio se:
- la chiave privata di A non è stata compromessa;
- B è in possesso della chiave pubblica di A;
ma come può B essere certo di possedere la vera chiave di A?
La convalida dell’abbinamento tra dati anagrafici e chiavi pubbliche viene fatta tramite i
Certificati Digitali: un’autorità esterna (Certification Authority) che garantisce
l’autenticità delle chiavi pubbliche.
A e B devono fidarsi della Certification Authority.
107
B.1.4 Interoperabilità
Il concetto di interoperabilità indica la possibilità per un sistema di protocollo
informatico ricevente di una certa amministrazione di trattare automaticamente le
informazioni trasmesse dal sistema di protocollo informatico mittente di un’altra
amministrazione al fine di automatizzare le attività e i processi sottostanti.
E’ la condizione necessaria per la diffusione della firma digitale, e per l'utilizzo
friendly da parte dell'utente (librerie software diverse, dispositivi diversi, …).
AIPA, in attesa di standard a livello europeo/internazionale, ha sviluppato una
soluzione concreta, semplice ed immediata sul tema dell'interoperabilità relativamente
a:
- la struttura dei certificati e la loro estensione
- la rappresentazione dei dati dei certificati
- la struttura ed il formato delle CRL ovvero CSL
- la struttura e la rappresentazione dei documenti firmati
- la marcatura temporale
Si è quindi passati da una fase che vedeva una CA compatibile soltanto con se
stessa, ad una situazione in cui ogni CA inscritta all'elenco pubblico CNIPA è in grado
di leggere e gestire certificati emessi da altre CA.
B.1.5 PKCS
Di seguito gli standard di crittografia delle chiavi pubbliche:
- PKCS#1 : RSA Cryptography
- PKCS#3 : Diffie-Hellman Key Agreement
- PKCS#5 : Password Based Cryptography
- PKCS#7 : Digital Envelope
- PKCS#8 : Private Key Information Syntax
- PKCS#9 : Selected Attribute Type
108
- PKCS#10 : Certificate Request
- PKCS#11 : Cryptographic Token Interface
- PKCS#12 : Personal Information Exchange Syntax
- PKCS#15 : Cryptographic Token Information Format
- #2,#4,#6 obsoleti, #13 e #14 in sviluppo
Ulteriori informazioni : http://www.rsasecurity.com/rsalabs/PKCS
B.1.6 Composizione di un certificato
Un certificato è composto fondamentalmente da:
- informazioni sul proprietario;
- la data di scadenza;
- la chiave pubblica del proprietario;
- informazioni sull’autorità garante (la Certification Authority o CA);
- la firma della CA.
I certificati sono pubblicati in una directory pubblica (ad es. LDAP o
WWW) gestita dalla CA.
B.1.7 Revoca dei certificati
Normalmente il legame tra identità e chiave pubblica vale per l’intero periodo di
validità del certificato. Può essere necessario rescindere questo legame in anticipo (ad
es. la chiave privata è stata persa).
Una CA può (e deve) revocare un certificato non più valido.
I browser contengono preinstallati alcuni root certificates, visibili sotto
Certificates nel menu Tools/Internet Options.
Si possono aggiungere, eliminare e modificare i certificati.
109
B.1.8 Come si ottengono i certificati
- A sceglie una Certification Authority e se ne procura il certificato;
- A genera una coppia di chiavi: pubblica e privata;
- A sottopone una richiesta di certificato alla CA scelta;
- la CA verifica che la richiesta provenga veramente da A;
- la CA emette il certificato per A e lo pubblica.
B.1.9 Come si usano i certificati
B vuole scambiare messaggi «sicuri» con A:
- si procura il certificato di A (e i certificati della catena di CA di A che ancora non
possiede);
- verifica la validità del certificato di A (una tantum):
- decifra l’hash del certificato di A con la chiave pubblica della CA di A (ricavata del
certificato di quest’ultima);
- calcola l’hash del certificato di A;
- controlla che i due hash, quello calcolato e quello decifrato, siano uguali;
- controlla la data di scadenza;
- verifica che il certificato di A non sia revocato o sospeso;
- usa il certificato di A per:
verificare la firma dei messaggi che riceve da A;
cifrare i messaggi per A.
B.1.10 Applicazioni
– autenticazione di un server web da parte dei clienti e cifratura dei dati trasmessi:
– pagamenti online;
– autenticazione dei clienti da parte del server web e cifratura dei dati trasmessi:
– accesso a dati riservati senza dover digitare password;
110
– autenticazione e cifratura di messaggi.
B.2 Una semplice osservazione sulla connessione sicura
Per una semplice curiosità, viene allegata un’analisi di un comune sniffer su un
pacchetto mentre ci si apprestava a consultare la posta su www.libero.it.
Si può notare che la password di accesso è facilmente visibile (cancellata per
ovvie ragioni di privacy).
Questo non sarebbe accaduto se tra client e il provider ci fosse stata una
connessione sicura.
Infatti “over https” tutto ciò che il client invia al server viene criptato dal client
con la chiave pubblica del server (che il server ha fornito al client nel momento della
connessione e dopo la fase dell’autenticazione) e decriptato dal server con la sua
chiave privata.
111
Se, in questo caso, dovessimo “sniffare” un pacchetto in uscita, non vedremmo
nessuna stringa comprensibile (come nell’esempio precedente) ma solo dei dati senza
significato.
112
Appendice C: Installazioni e configurazioni
113
C.1 Installare e configurare MySQL, Apache con SSL, PHP, LDAP
Occorre avere un accesso alla macchina come superuser. Ogni cosa in questo
esempio può essere fatta per via remota usando ssh o telnet, così come localmente
operando sulla macchina.
Punto 1:
Per prima cosa, serve una struttura di directory per installare e compilare il
tutto. Alcune persone usano le locazioni standard quando installano. Se si
amministrano poche macchine, o se si usa un solo S.O., non c'è nulla di sbagliato. Si
Può mettere tutto in /usr/bin o /usr/local/bin, oppure /export/home/web o dovunque il
sistema decida di mettere le cose.
Usare uno schema di directory generale per le installazioni complesse è una
cosa buona che sicuramente semplifica di molto il lavoro.
In questo modo, non occorre andare in giro a caccia delle cose, tentando di
ricordare lo schema delle directory di ogni sistema operativo.
Per cui creiamo le seguenti directory:
# mkdir /usr/www
# mkdir /usr/db
# mkdir /usr/berkeley
# mkdir /usr/ldap
Inoltre occorre creare directory per ogni cosa che verrà compilata in Apache:
# mkdir /usr/www/php
# mkdir /usr/www/mod_ssl
# mkdir /usr/www/openssl
# mkdir /usr/www/mm
# mkdir /usr/www/curl
# mkdir /usr/www/logs
114
È ora di prelevare i sorgenti del software che bisogna installare.
Bisogna trovare sulla rete i seguenti pacchetti:
Per mysql:
mysql-3.22.32
phpmyadmin 2.2.7 (interfaccia in PHP per gestire mysql)
Per Apache:
apache_1.3.31
Per il protocollo SSL
mm-1.1.3
mod_ssl-2.8.19-1.3.31
openssl-0.9.6
Per PHP
php-4.3.7
Per LDAP:
db-4.1.25 (il database backend per ldap)
openldap-2.1.16
phpldapadmin-0.9.4b (interfaccia in PHP per gestire LDAP)
Per le prove relative alla realizzazione di un webservices:
nusoap.0.6.4 (per xml)
curl-7.12.1 (per xml su https)
Si scompattano i sorgenti nelle relative cartelle create.
A questo punto, si può iniziare la compilazione di MySQL.
# cd /usr/db/mysql-3.22.32/
115
Si configurano i sorgenti in modo che compilino sul sistema.
# configure --prefix=/usr/db
Si compila il sorgente:
# make
Si installa MySQL:
# make install
Ora si installa il database MySQL.
In /usr/db/mysql-3.22.32/.
# cd scripts
# make install
# chmod +x mysql_install_db.sh
# ./mysql_install_db.sh
Ora si può avviare il server MySQL e impostare la relativa password di root:
# cd /usr/db/bin
# ./safe_mysqld &
# ./mysqladmin -u root password 'new-password'
Punto 2:
Ora si compilerà tutto il software SSL. A differenza di PHP, mod_ssl è compilato
direttamente nel server Apache, invece di girare come modulo. La prima cosa da fare è
installare MM, la Shared Memory Library:
# cd /usr/www/mm-1.1.3
si configura il makefile:
# ./configure --prefix=/usr/www/mm
Si compila il sorgente:
# make
Una volta compilato, si test la compilazione:
# make test
Infine:
# make install
Punto 3:
Ora si compilerà OpenSSL.
# cd /usr/www/openssl-0.9.6
116
# ./config --prefix=/usr/www --openssldir=/usr/www/openssl
# make
# make test
# make install
Punto 4:
Ora verrà compilato mod_ssl.
# cd /usr/www/ mod_ssl-2.8.19-1.3.31
Ora bisogna specificare le opzioni richieste per configurare il Makefile.
# ./configure --with-apache=/usr/www/apache_1.3.31 --with-ssl=/usr/www/openssl-
0.9.6 --with-mm=/usr/www/mm --prefix=/usr/www --enable-shared=ssl --
prefix=/usr/www --enable-module=rewrite --enable-shared=rewrite --enable-
module=speling --enable-module=so
Una volta configurato, è la volta di compilare il sorgente.
# cd /usr/www/apache_1.3.31
Ora bisogna compilare il sorgente.
# make
Ora bisogna creare un certificato. Verranno chieste le informazioni necessarie
per creare un certificato auto-firmato, che si può usare al posto di uno firmato, o per lo
sviluppo finché non se ne ottiene uno.
# make certificate
Ora verranno chieste delle informazioni necessarie per creare il certificato:
-Stato
-Città
-common name
-ecc…
117
occorre fornire tutte queste informazioni.
Ora, finalmente, si installerà il server.
# make install
Al termine, si vedrà un messaggio che confermerà l'avvenuta installazione.
Non avviamo il server.
Si installeranno ora i moduli per gestire gli altri servizi che vogliamo.
Punto 5:
Installiamo LDAP.
Occorre prima installare Il “Barkeley DB”:
# cd /usr/berkeley/db-4.1.25/build-unix/
#../dist/configure –prefix=/usr/berkeley
# make
# make install
Installiamo ora LDAP:
# cd /usr/ldap/openldap-2.1.16
# env CPPFLAGS=”-I/usr/www/mod-ssl/include –I/usr/berkeley/include” LDFLAGS=”-
L/usr/www/lib –L/usr/berkeley/lib” ./configure –prefix=/usr/ldap –enable-slurpd
# make depend
# make
# make install
startiamo LDAP:
# /usr/ldap/libexec/slapd
118
Punto 6:
Installiamo CURL.
Curl verrà utilizzato relativamente alla fase di realizzazione di un web services perché
è necessario a nusoap per connessioni di tipo SSL (con protocollo https):
# cd /usr/www/curl-7.12.1
# ./configure –with-ssl=/usr/www –prefix=/usr/www/curl
# make
# make install
Punto 7:
Si installerà ora PHP dentro Apache.
# cd /usr/www/php-4.3.7
# ./configure --prefix=/usr/www/php --with-mysql --with-apxs=/usr/www/bin/apxs –with-
ldap=/usr/ldap –with-curl=/usr/www/curl –enable-track-vars
# make
# make install
Una volta installato, si può verificare che il modulo sia stato caricato ispezionando
/usr/www/conf/httpd.conf.
Dovrebbe esserci:
LoadModule php4_module libexec/libphp4.so
AddModule mod_php4.c
nella sezione DSO del file.
Bisogna togliere i commenti alle linee che seguono:
#AddType application/x-httpd-php .php
#AddType application/x-httpd-php-source .phps
119
E’ possibile modificare il file di configurazione di Apache,
Si trova in
/usr/www/conf/httpd.conf
Ad es. è possibile scegliere se rendere obbligatorio o opzionale la verifica del
certificato-client modificando la seguente riga
SSLVerifyClient optional
con
SSLVerifyClient require
oppure
SSLVerifyClient none
Oppure si possono fare altre modifiche.
A questo punto, si può partire.
Per avviare Apache
# cd /usr/www/sbin
# ./apachectl startssl
Sarà chiesta la SSL passphrase (scelta quando è stato creato il certificato
digitale).
A questo punto il server partirà.
Sarà possibile accedere via telnet alla porta 80 della macchina localhost,
richiedere l'header http, e vedere la pagina di benvenuto di Apache .
Sarà anche possibile potersi connettere alla porta 443 (digitando nel browser
https:\\indirizzodelserver) .
E’ stato ottenuto un singolo processo Apache che può soddisfare entrambe le
richieste http e https, analizzare PHP4, mentre dialoga con un database MySQL o
mentre utilizza LDAP.
120
C.2 Generazione dei certificati
Di seguito è possibile trovare la procedura per creare un certificato “auto-
firmato” con il quale un server afferma di “essere effettivamente chi dice di essere” e,
inoltre, la procedura tramite la quale è possibile rilasciare dei certificati-client.
In questo modo i certificati-client rilasciati non sono validi per il “mondo esterno”
a meno che il certificato-server che utilizziamo non sia auto-firmato ma sia rilasciato da
una Certification Autority.
Prima di vedere queste due procedure è quindi opportuno fare una distinzione
tra un certificato-server auto-firmato e uno rilasciato da una CA:
C.2.1 Osservazioni sui certificati
La certificazione si può ottenere in uno dei due modi seguenti.
1) Inviare la richiesta di certificazione ad un ente certificatore (Certificate Authority)
come, ad esempio, EuroPKI http://www.europki.org. L'ente certificatore dopo un
certo periodo manda il certificato desiderato e lo si può installare sul un web server
per utilizzare SSL. Questa procedura non è gratuita e richiede parecchio tempo. Il
maggior vantaggio è quello di ottenere un certificato universalmente riconosciuto.
2) Si ottiene il proprio certificato utilizzando il software Openssl validando la richiesta
di certificazione. l vantaggio di questa metodologia è di ottenere un certificato, da
utilizzare con SSL in poco tempo ed in maniera gratuita. Lo svantaggio è che il
browser, sia Netscape sia MS Explorer, avvertirà l'utente che la CA (Certificate
Authority) non è fra quelle riconosciute e gli chiederà una conferma prima di
iniziare il collegamento sicuro.
121
C.2.2 Creare certificati SSL auto-firmati
Spostiamoci nella seguente directory:
cd /usr/www/bin
e digitiamo la seguente riga:
./openssl req -new > new.cert.csr -config /usr/www/openssl/openssl.cnf
./openssl rsa -in privkey.pem -out new.cert.key
./openssl x509 -in new.cert.csr -out new.cert.cert -req -signkey new.cert.key -days 999
la chiave e il certificato appena ottenuti vanno spostate nelle opportune directory:
cp new.cert.key /usr/www/conf/ssl.key/server.key
cp new.cert.cert /usr/www/conf/ssl.crt/server.crt
Riavviare APACHE altrimenti il certificato non risulterà valido !
Attenzione a un probabile errore che è possibile commettere (e che io ho
commesso) : il certificato server appena creato (e che mi veniva esibito nel momento in
cui invocavo il server via https) risultava “non valido”. Dopo moltissime prove ho capito
che risultava “non valido ” perché l’orologio interno del server era di un paio di ore più
avanti rispetto a quello del client che stavo utilizzando, perciò il certificato non era
ancora entrato nel periodo di validità !!
Un client può richiedere un certificato-client al nostro server.
Ecco di seguito come può fare
122
C.2.3 rilasciare certificati client a seguito di una richiesta.
Passi che un client deve seguire:
1) scaricare l'applicativo openssl.exe (che può essere messo a disposizione sul server
e pronto per essere scaricato oppure può essere scaricato da internet)
2) Unzipparlo
3) Doppio click su openssl.exe
4) digitare la seguente riga
genrsa -out client.key 1024
5) digitare la seguente riga
req -new -key client.key -out client.csr -config openssl.cnf
In questo modo è stato generato un file "client.csr" che rappresenta una richiesta di un
certificato client.
Prendere questo file e inviarlo in qualche modo (ad es. via e-mail) al server (o
meglio al responsabile del rilascio dei certificati).
Dopo che è stato accertato che la richiesta arriva da una fonte attendibile, verrà
elaborata e verrà spedito al mittente il certificato "client.crt"
6) salvare il certificato nella stessa cartella in cui risiede openssl.exe
7) doppio click su openssl.exe
8) digitare la seguente riga
pkcs12 -export -clcerts -in client.crt -inkey client.key -out client.p12
9) scegliere una password
10) verrà generato un file "client.p12". Basta fare un doppio click per installarlo.
Tra il passo 5) e il passo 6) si noterà che c’è un intervento sul server.
Ecco quello che succede:
bisogna prendere il file "client.csr" inviatoci dal cliente, metterlo in /usr/www/bin
e digitare:
./openssl x509 -req -days 900 -CA /usr/www/conf/ssl.crt/server.crt -CAkey
/usr/www/conf/ssl.key/server.key -CAcreateserial -in client.csr -out client.crt
123
il file "client.crt" deve essere mandato al cliente.
C.2.4 Richiedere un certificato-client ad un ente certificatore ufficiale
Prendiamo come esempio la EuroPKI.
La richiesta deve essere mandata presso
Indirizzo:EuroPKI Italian Certification Authority
c/o prof. Antonio Lioy
Dip.Automatica e Informatica
Politecnico di Torino
corso Duca degli Abruzzi 24
10129 - TORINO
phone:+39 0115647021 / +39 0115647054
fax:+39 0115647099
URL:http://www.europki.org/ca/it/it_index.html
e-mail:[email protected]
Bisogna compilare il modulo scaricabile dal loro sito e mandarlo via fax.
Inoltre bisogna presentarsi in una delle loro Registration Authority (Torino,
Bologna o Catanzaro) per l'identificazione (un incontro "de visu") con una copia di un
documento di identità (C.I. o passaporto)
C.2.5 Considerare validi i certificati-client rilasciate da altre CA
Per ogni CA per la quale dobbiamo considerare validi i certificati-client da essa
rilasciati, occorre installare il suo certificato sul nostro server.
124
Prendendo come esempio sempre la EuroPKI, al seguente link
http://www.europki.org/ca/it/ca_cert/it_index.html
è possibile trovare il certificato della CA EuroPKI. Occorre scaricarlo e installarlo sul
nostro server.
Scarichiamo quello in formato PEM:
ca_cert.pem
Ora, se vogliamo che il nostro server consideri validi sia i certificati-client da
esso rilasciato, sia i certificati-client rilasciati dall’EuroPKI, occorre concatenare i due
certificati delle due CA in un unico file e specificare il path del file tramite la direttiva
SSLCACertificateFile
che si trova nel file di configurazione di Apache “httpd.conf”.
Vediamo come fare.
Innanzi tutto bisogna trasformare il certificato del nostro server
server.crt
nel formato PEM.
Creiamo prima la cartella /usr/www/conf/ssl.pem
poi:
cd /usr/www/bin
cat /usr/www/conf/ssl.key/server.key /usr/www/conf/ssl.crt/server.crt >
/usr/www/conf/ssl.pem/server.pem
abbiamo così ottenuto il certificato
server.pem
Ora occorre concatenare i due .pem:
cd /usr/www/bin
cat /usr/www/conf/ssl.pem/server.pem /usr/www/conf/ssl.pem/ca_cert.pem >
/usr/www/conf/ssl.crt/concatenati.crt
In questo modo abbiamo ottenuto il certificato
concatenati.crt
dato dalla concatenzione dei due.
Modifichiamo infine il file di configurazione di Apache (che si trova in
“/usr/www/conf/httpd.conf “ ) “httpd.conf” .
125
In corrispondenza di
SSLCACertificateFile
Scriviamo:
SSLCACertificateFile /usr/www/conf/ssl.crt/concatenati.crt
Abbiamo, quindi, concatenato tutti i certificati in un unico file e abbiamo specificato il
path del file tramite la direttiva SSLCACertificateFile.
Al termine delle modifiche occorre riavviare il server.
In questo modo ora il nostro server riconoscerà anche i certificati-client rilasciati calla
CA "EuroPKI".
C.3 Il mio web services
Per costruire un web services, è stato visto che bisogna tenere conto che si deve avere
a che fare con un insieme di messaggi inviati tramite Soap (o meglio, NUSOAP, visto
che è stata preferita questa scelta), questo perché sfruttano XML per garantire
l'indipendenza dalle piattaforme utilizzate.
C.3.1 Installazione di NUSOAP
NUSOAP non si installa ! Basta solo copiare l’intera cartella in un punto
qualunque e poi includere il file “nusoap.php” in tutti i file php che si realizzano. Ad es.:
include("./nusoap/nusoap.php");
C.3.2 Installazione di CURL
Sappiamo che Curl viene utilizzato perché è necessario a nusoap per
connessioni di tipo SSL (con protocollo https). L’installazione è illustrata al Punto 6 nel
paragrafo “C.1 Installare e configurare MySQL, Apache con SSL, PHP, LDAP”.
Dopo l’installazione occorre includerlo, successivamente, durante
l’installazione di PHP.
126
C.3.3 Il WSDL del mio Web Services: come utilizzare il servizio.
Una volta realizzato il web services, occorre spiegare agli “utilizzatori” del o dei
servizi offerti
- come richiamarlo
- cosa passargli
- quale funzione invocare per ottenere ciò che si vuole
- cosa restituirà
Queste informazioni sono racchiuse nel “WSDL” che dovrà essere pubblicato nel
momento in cui il web services si metterà on-line.
Cioè se decideremo di iscrivere il nostro Web services ad un motore di ricerca,
occorrerà corredarlo, oltre che di una descrizione sui servizi offerti, anche del suo
WSDL.
Il web services che io ho realizzato, riceve il CN (Common Name) del certificato-
client di un visitatore di un sito, fa una ricerca su un LDAP server, rileva alcune
informazioni relative al CN e le restituisce al sito che ha invocato il web services.
Ad es. può restituire la stringa “sicuro” oppure “inaffidabile” ecc…e il sito potrà
decidere di far continuare o meno il suo “cliente” nella navigazione.
Ecco il WSDL del mio web services:
https://81.118.52.132/webservices/restituisciclient.php
<?xml version="1.0" encoding="ISO-8859-1"?><SOAP-ENV:Envelope SOAP-
ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-
ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:si="http://soapinterop.org/xsd"><SOAP-ENV:Body><ns1:estraidatixmlns:ns1="http://testuri.org">
<CN xsi:type="xsd:string">VALORE DEL COMMON NAME</CN></ns1:estraidati></SOAP-ENV:Body></SOAP-ENV:Envelope>
127
dove:
- la prima riga rappresenta l’indirizzo del mio web services
- “estraidati” rappresenta la funzione da chiamare
- CN rappresenta la variabile da passare.
Se “l’utilizzatore” del mio web services decidesse di richiamarlo tramite una pagina
PHP, allora dovrebbe banalmente scrivere:
<?phprequire_once('./nusoap/nusoap.php');
//----------------- PER PRELEVARE IL CN DEL CERTIFICATO CLIENT -------------$sslusername = getenv("SSL_CLIENT_S_DN_CN");//-----------------------------------------------------------------------------------------------------------
//------- IL PARAMETRO DA PASSARE ------------------------------------------$parameters = array( "CN" => $sslusername);
//--------L’INDIRIZZO DEL MIO WEB SERVICES -------------------------------$soapclient = newsoapclient('https://81.118.52.132/webservices/restituisciclient.php');
//------------RICHIAMA LA FUNZIONE PASSANDO I PARAMETRI---------$result = $soapclient->call('estraidati',$parameters);
//----IN $result CI SARA’ CIO’ CHE IL WEB SERVICES RESTITUIRA’-----
?>
128
Appendice D: le applicazioni in PHP
129
D.1 I listati dei file in PHP
D.1.1 Verifica l’esistenza di un dominio: “checkdomain.php”
Il seguente file deve essere copiato sul web services.
In pratica rappresenta una funzione che il web services mette a disposizione.
Viene chiamata passando un dominio e la sua estensione, e restituisce “0” se
l’indirizzo passato esiste, “1” altrimenti:
<?function selectdomaincheck ($domain,$domainextension){Switch ($domainextension) { case ".it": case ".at.it": case ".co.it": case ".go.it": case ".is.it": case ".me.it": case ".to.it": case ".tv.it": $domainexists = checkinextension($domain,$domainextension); break; case ".net": case ".com": case ".biz": case ".info": case ".org": $domainexists = checkoutextension($domain,$domainextension); break; } return $domainexists; }
function checkinextension ($domain,$domainextension) {if ($domain) {
if (trim($domain) <> "") { $domain = trim($domain); $domain .= $domainextension; $fp = fsockopen("whois.nic.it", 43, $errno, $errstr, 30); if (!$fp) { $server="-1"; } else { fputs($fp, "$domain\r\n"); $server = "0"; while (!feof($fp)) { $buf = fgets($fp,128); if (ereg("No entries found ", $buf))
130
{ $server = "1"; } } fclose ($fp); return $server; } }}}
function checkoutextension ($domain,$domainextension) {if ($domain) {
if (trim($domain) <> "") { $domain = trim($domain); $domain .= $domainextension; $fp = fsockopen("whois.networksolutions.com", 43, $errno, $errstr, 30); if (!$fp) { $server="-1"; } else { fputs($fp, "$domain\r\n"); $server = "0"; while (!feof($fp)) { $buf = fgets($fp,128); if (ereg("NO MATCH", $buf)|| ereg("NOT FOUND", $buf)|| ereg("No Match", $buf)|| ereg("Not found", $buf)|| ereg("not found", $buf)|| ereg("no match", $buf)) { $server = "1"; } } fclose ($fp); return $server; } }}}require_once('nusoap/nusoap.php');$server=new soap_server;$server->register('selectdomaincheck');$server->service($HTTP_RAW_POST_DATA);?>
Il client invocherà il Web services tramite il seguente codice :
<?php
require_once('nusoap/nusoap.php');
$parameters = array(
"domain" =>"salvatoreiacometta",
"domainextension" =>".it"
);
131
$soapclient = new soapclient('http://il-nostro-webservices/checkdomain.php');
$result = $soapclient->call('selectdomaincheck',$parameters);
print $result;
?>
D.1.2 Codice in PHP per interrogare il web services di Google
Si ricorda che prima di provare il seguente esempio, occorre registrarsi per
poter ottenere una chiave necessaria per poter utilizzare i servizi del web services di
Google. La registrazione si effettua su questo sito:
http://www.google.it/apis/index.html:
<?php/*include la classe base (il file nusoap.php)*/INCLUDE("./NUSOAP/NUSOAP.PHP");
/*crea un istanza del client SOAP e indica l'indirizzo del servizio*/$soapclient = new soapclient("http://api.google.com/search/beta2");
/*decommenta la riga seguente per vedere i messaggi di debug*/// $soapclient->debug_flag = 1;
/*Google vuole che la request venga confezionata con il seguente namespace*/$namespace = 'urn:GoogleSearch' ;
/*L'array con i parametri da passare alla procedura remota*/$parametri = array(
//la chiave di accesso fornitaci con l'iscrizione//'key' => 'XXX-TUA_CHIAVE_ACCESSO-XXX',
'key' => 'mL+nrSVQFHJF5ev2AaCAz9XivPzQLqdb',
//i parametri per la ricerca
'q' => '"salvatore iacometta',
//Il risultato da cui iniziare la visualizzazione
132
'start' => 0,
//Il numero di risultati da restituire (max 10)'maxResults' => 8,
//Elimina i duplicati'filter' => true,
//Circoscrive in base all'argomento//o al TLD (top level domain, es .it)'restrict' => '',
//Elimina i siti per adulti'safeSearch' => false,
//Seleziona il linguaggio (si può omettere)'lr' => 'lang_it',
//Codifica usata per la request (default UTF-8)'ie' => '',
//Codifica usata per la risposta (default UTF-8)'oe' => '');
/*Invoca la procedura remota "doGoogleSearch"*/$risposta = $soapclient->call("doGoogleSearch", $parametri, $namespace);
/*Se riceve una risposta SOAP di errore la stampa*/if($soapclient->fault){
echo('ERRORE! '.$soapclient->faultstring."\n<br>") ;
}
else{
/*DIMOSTRATIVOStampa l'array completo con il risultato della ricerca*/
echo('<pre>') ;
print_r($risposta);
echo('</pre>') ;
}
/*DIMOSTRATIVOStampa la richiesta in XML, la risposta e la stringa di debug*/
echo '----------------------------------------------------------------';
133
echo '----------------------------------------------------------------';echo 'Request: <xmp>'.$soapclient->request.'</xmp>';echo '----------------------------------------------------------------';echo '----------------------------------------------------------------';echo 'Response: <xmp>'.$soapclient->response.'</xmp>';echo '----------------------------------------------------------------';echo '----------------------------------------------------------------';echo '----------------------------------------------------------------';echo 'debug_str: <xmp>'.$soapclient->debug_str.'</xmp>';echo '----------------------------------------------------------------';echo '----------------------------------------------------------------';
?>
D.1.3 La stampa di Request e Response di un Web Services che reperisce suLDAP informazioni su certificati-client
Per curiosità, qui di seguito viene riportato il risultato dell’applicazione relativa al
paragrafo “6.4 Un esempio completo: web services su https che interroga LDAP ”:
STATO CLIENT:ABILITATO
RequestPOST /webservices/restituisciclient.php HTTP/1.0User-Agent: NuSOAP/0.6.6Host: 81.118.52.132:443Content-Type: text/xml; charset=ISO-8859-1SOAPAction: ""Content-Length: 568
<?xml version="1.0" encoding="ISO-8859-1"?><SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"xmlns:si="http://soapinterop.org/xsd"><SOAP-ENV:Body><ns1:estraidatixmlns:ns1="http://testuri.org"><CN xsi:type="xsd:string">CLIENTE-DEL-SITO-CIOCC-E-AFFINI</CN></ns1:estraidati></SOAP-ENV:Body></SOAP-ENV:Envelope>
ResponseHTTP/1.1 200 OKDate: Tue, 26 Oct 2004 17:46:36 GMTServer: Apache/1.3.31 (Unix) mod_ssl/2.8.19 OpenSSL/0.9.6 PHP/4.3.7X-Powered-By: PHP/4.3.7Status: 200 OKContent-Length: 528Connection: closeContent-Type: text/xml; charset=ISO-8859-1
134
<?xml version="1.0" encoding="ISO-8859-1"?><SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"xmlns:si="http://soapinterop.org/xsd"><SOAP-ENV:Body><estraidatiResponse><soapValxsi:type="xsd:string">attivo</soapVal></estraidatiResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
Debugsoapclient: call: estraidati, Array, , , ,soapclient: endpointType:soapclient: in serialize_val: CLIENTE-DEL-SITO-CIOCC-E-AFFINI, CN, , , , ,encodedsoapclient: endpoint: https://81.118.52.132/webservices/restituisciclient.php,soapAction: , namespace: http://testuri.orgsoapclient: sending msg (len: 568) w/ soapaction ''...soapclient: transporting via HTTPsoapclient: sending message, length: 568soapclient: transport debug data...soap_transport_http: scheme = httpssoap_transport_http: host = 81.118.52.132soap_transport_http: path = /webservices/restituisciclient.phpsoap_transport_http: entered send() with data of length: 568soap_transport_http: connect using httpsoap_transport_http: cURL connection set upsoap_transport_http: set cURL payloadsoap_transport_http: send and receive with cURLsoap_transport_http: No cURL error, closing cURLsoap_transport_http: found proper separation of headers and documentsoap_transport_http: cleaned data, stringlen: 528soap_transport_http: end of send()
soapclient: got response encoding: ISO-8859-1soapclient: got response, length: 528 use encoding: ISO-8859-1soapclient: Entering parseResponse(), about to create soap_parser instancesoapclient: soap_parser: Entering soap_parser(), length=528, encoding=ISO-8859-1soap_parser: found root struct estraidatiResponse, pos 2soap_parser: inside buildVal() for estraidatiResponse(pos 2) of type structsoap_parser: parsed successfully, found root struct: 2 of nameestraidatiResponse
soapclient: sent message successfully and got a(n) array back
Osservando Request e Response noteremo le stringhe XML (la conversione in
XML è realizzata dalla libreria NUSOAP).
135
D.2 Un sito per testare le applicazioni
Per poter testare tutte le applicazioni realizzate in questa tesi, è stato costruito
un sito web utilizzando Swish, visibile al seguente indirizzo:
http://81.118.52.132/
Si presenta più o meno così:
D.2.1 Scaricare i certificati per i test
Nella sezione “Certificati”, è possibile scaricare dei certificati-client da utilizzare
per effettuare dei test.
136
D.2.2 Il link ai servizi offerti
Nella sezione “Servizi”
è possibile scegliere uno delle applicazioni da testare, illustrate nel capitolo 6 al
paragrafo “6.5 Applicazioni pratiche realizzate”.
137
D.2.3 Invocare il Web services su https da http: “L’esempio 6.5.5”
Infine, nella sezione “Altro”, è possibile seguire passo passo l’applicazione
illustrata nel capitolo 6 paragrafo “6.5.5 Applicazione da un server esterno (Aruba)”.
In questa ultima applicazione è interessante notare come, partendo dal sito
http://www.salvatoreiacometta.it/TESI/applicazione_tesi.php
si richiama una pagina che si trova su
https://81.118.52.132/…….
Da qui viene invocato il Web services, che restituisce le informazioni relative al
certificato-client.
Ora si richiama la pagina
http://www.salvatoreiacometta.it/TESI/esito.html
e si prosegue di conseguenza.
Questa ultima applicazione fa ben comprendere che il gestore del sito
“www.salvatoreiacometta.it”, ignora completamente i dati del certificato-client di un suo
“visitatore”; la responsabilità di far procedere il “visitatore” nel sito è lasciata
interamente al Web services.
138
139
Conclusioni e sviluppi futuri
Una volta che sono stati portati a termine tutti gli studi relativi a questo lavoro di
tesi e dopo aver concluso la realizzazione pratica di tutti gli applicativi, si può senza
dubbio concludere che sono molti gli argomenti che fino a poco tempo fa ignoravo e su
cui ora sento di avere una discreta padronanza.
Anche se da anni lavoro come analista programmatore in un’azienda di servizi,
questo lavoro di tesi mi ha portato a documentarmi su cose che fino ad ora non avevo
mai trattato.
Grazie all’azienda per la quale lavoro, ho avuto la possibilità di fare delle prove
pratiche importanti per comprendere a pieno alcuni concetti.
Il fatto di avere avuto a disposizione un indirizzo pubblico da poter assegnare
alla macchina sulla quale ho fatto tutto il lavoro di tesi, mi ha permesso di simulare
perfettamente ogni situazione reale.
Il mondo dell’autenticazione su Internet che guardavo fino a poco tempo fa con
molto sospetto e che etichettavo in modo spietato come inaffidabile mi trova oggi più
fiducioso.
Infine la creazione di un Web services che mette a disposizione un servizio
legato all’autenticazione e alla connessione sicura, conclude il mio lavoro di tesi che
completa il percorso che era partito con l’intento di realizzare un server che
supportasse la connessione sicura.
La realizzazione di un Web Services che può essere invocato a seguito
dell’esibizione di un certificato oppure che mette a disposizione servizi che hanno
come input alcuni dati del certificato esibito, ne mette in risalto l’utilità e apre la strada a
una più frequente realizzazione di Web Services per l’autenticazione su infrastruttura
PKI/LDAP.
140
Bibliografia
[1] Morena Bonezzi "Le tecnologie WWW in ambito wireless: una applicazionepush/pull sicura WAP integrata con SMS" (Sicurezza informatica)
[2] http://security.fi.infn.it/CA/istruzioni.pdf (Autenticazione e crittografia)
[3] http://www.campana.vi.it/ottavio/Vari (LDAP )
[4] http://www.ziobudda.net/Recensioni/vedi_recensione.php?ff=35 (Installazioni econfigurazioni)
[5] http://www.vaisulweb.it/index.php?/vaisulweb/content/view/full/438/ (PHP & WebServices )
Software utilizzato
Sistema operativo: Linux (Debian 30R2)
Database: MySQL 3.22.32 PhpMyAdmin 2.2.7 (interfaccia in PHP per gestire mysql)
Server:
Apache 1.3.31
mm 1.1.3
mod_ssl 2.8.19 -1.3.31
Openssl 0.9.6
Ambiente di sviluppo: PHP 4.3.7
Protocollo LDAP:
Berkeley Db 4.1.25 (database backend per ldap)
OpenLDAP 2.1.16
PhpLDAPAdmin-0.9.4b (interfaccia in PHP per gestire LDAP)
Classi in PHP per consumare Web Services: Nusoap.0.6.4
Tool per il trasferimento over https di dati in XML: Curl-7.12.1
Client ssh: Putty 0.53b
Sniffer: Sniff’em
HTML editing e web management program: Macromedia Dreamweaver MX 6.0
Applicativo per animazioni su Web: Swish 2.0
141
142
Ringraziamenti
Per questo lavoro di tesi mi preme molto ringraziare il Prof. Ing. Nicola Frega
per il suo supporto, i suoi consigli, i suoi suggerimenti, i suoi chiarimenti, le sue
spiegazioni e soprattutto per la sua pazienza e disponibilità.
Un grande ringraziamento va al Prof. Antonio Volpentesta per avermi dato la
possibilità di lavorare su un argomento così stimolante che ha contribuito ad arricchire
molto la mia esperienza professionale.
Ringrazio i responsabili del reparto sviluppo dell’azienda Datel s.p.a. di Crotone
per la quale lavoro da sette anni come analista programmatore per avermi dato la
possibilità di poter usufruire delle strutture aziendali per portare a termine questo lavoro
di tesi.
Il mio più grande ringraziamento va ovviamente alla mia famiglia e in particolar
modo ai miei genitori che mi hanno costantemente incoraggiato e sostenuto in questa
lunga carriera universitaria.
La conclusione degli studi vuole essere soprattutto un piccolo riconoscimento
per il loro smisurato e insostituibile amore nei miei confronti.
E’ ovvio, però, che questi ringraziamenti non avrebbero alcun senso se non mi
rendessi conto che l’unico a cui rendere davvero grazie è coLui che continuamente e
incondizionatamente mi dona il Suo Amore. Ringrazio Dio per avermi fatto incontrare
nella mia vita delle persone che testimoniano il Suo Amore per me.
143
Solo la ricerca della verità
giustifica la nostra vita
144
