Sicurezza delle applicazioni di rete Situazione standard
Oggi si considera la situazione standard, ovvero il modo in cui gli sviluppatori creano le applicazioni di rete, una situazione abbastanza negativa, questo per i seguenti motivi :
autenticazione ed autorizzazione basate su username e password ne deriva un problema legato principalmente alle reti e al modo in cui esse sono organizzate, infatti quei dati sono potenzialmente sniffabili in rete: password snooping
autenticazione basata su indirizzo IP ( questa è possibile farla ad esempio nel caso dei server web, o anche nel caso della suite di comandi R come rsh, rlogin, rcp, ...)
in questo caso il problema sarebbe comunque l’IP spoofing
Anche a voler implementare il meccanismo più sicuro, rimangono sicuramente problemi di carattere generale, come:
data snooping / forging shadow server / MITM
Per cercare di risolvere i problemi appena citati, presentiamo alcuni approcci possibili.
Sicurezza di canale
Questo approccio consiste nel proteggere i dati nel momento in cui transitano all’interno del canale. Come vediamo i due nodi che vogliono comunicare dei dati che sono indicati in rosso (quindi dati sensibili e che devono essere opportunamente protetti) decidono di comunicare tra loro attraverso un canale protetto. In questo senso notiamo che non solo vengono solo protetti i dati in rosso, ovvero quelli che i due nodi intendevano scambiarsi, ma anche i dati che casualmente si trovano a transitare su quel canale, perché la proprietà di sicurezza non è un attributo dei dati bensì un attributo del canale di trasmissione. Notiamo anche che essendo la sicurezza una proprietà del canale, una volta che i dati escono e arrivano al nodo destinazione ritornano ad essere dei dati non protetti e quindi con tutte le problematiche che conosciamo. In una situazione di questo tipo,abbiamo le seguenti possibilità:
autenticazione (singola o mutua, perché il canale si crea prima di trasmettere i dati quindi se una delle due parti non si autentica noi ci possiamo anche rifiutare di aprire il canale), integrità e segretezza solo durante il transito nel canale
nessuna possibilità di non ripudio, infatti il non ripudio è di solito qualcosa di inerente i dati. Notiamo che nel momento in cui il destinatario estrae i dati dal canale, avrà la certezza che arrivino dalla controparte, che siano integri ma non lo può provare a terzi!
richiede poca (o nulla) modifica alle applicazioni
Sicurezza di messaggio (o dei dati)
Questo approccio consiste nel prendere i dati che intendiamo proteggere ed incapsularli all’interno di una busta sicura. A voler dare un’idea pratica di quanto stiamo dicendo, potremmo dire che la prima soluzione vista la possiamo realizzare con un tunnel sicuro (quindi IPsec) mentre la soluzione corrente potrebbe essere realizzata sfruttando il formato PKCS‐7 che per l’appunto ci permette di realizzare una busta sicura. Il concetto che deve essere chiaro è che ogni singolo dato che deve essere protetto viene protetto singolarmente e deve essere protetto dal mittente. Quindi visto che il mittente opera in completa autonomia, andiamo a perdere l’autenticazione eventuale, cioè non è possibile alcuna negoziazione preventiva prima di iniziare la trasmissione. Abbiamo un vantaggio derivante dal fatto che proteggiamo solo quello che veramente ci interessa proteggere. A questo punto è veramente possibile il non ripudio, in quanto il mittente avrà preso i dati di partenza e li avrà trasformati applicando ad essi tutta una serie di attibuti sulla base delle esigenza che aveva (es. voleva riservatezza e li ha cifrati, voleva autenticazione ed integrità e avrà messo un keyed‐digest, voleva il non ripudio allora avrà apposto una firma digitale con tanto di certificato emesso da una CA ufficialmente riconosciuta). In questo senso i dati che arrivano al destinatario sono dei dati diversi rispetto a quelli di origine. Quindi volendo riassumere:
autenticazione (singola), integrità e segretezza auto‐contenute nel messaggio possibilità di non ripudio richiede modifica alle applicazioni : in quanto o modifichiamo l’applicazione in modo che applichi le misure di sicurezza che vogliamo o dovremo realizzare un applicativo che a partire dai dati di origine li incapsuli in una busta sicura seguendo il formato PKCS‐7 ad esempio
L’ultimo motivo, ovvero il fatto che richiede modifica alle applicazioni, è anche la motivazione base per cui questa soluzione non è quella diffusamente adottata. Ad oggi infatti, la tendenza diffusa delle aziende è quella di delegare la sicurezza ai livelli bassi, ovvero alla rete, quindi nonostante la prima soluzione on sia proprio quella ottimale in quanto non mi permette di avere il non ripudio, non mi permette di sapere se i dati sono stati protetti al livello applicativo, è comunque quella più usata. Ovviamente è anche possibile fare un mix delle due soluzioni appena viste.
Sicurezza interna alle applicazioni
Quindi in origine il problema ricadeva nelle mani degli sviluppatori, ovvero ogni sviluppatore che volesse integrare la sicurezza nell’applicazione che si accingeva a creare, doveva crearsi le proprie routine o le proprie classi per cifrare i dati e garantire determinate proprietà di sicurezza. Ovviamente, questa situazione veniva ad essere replicata per ogni sviluppatore, quindi la parte in comune che rimaneva era quella di rete, in quanto nessuno si sfruttavano i socket che costituiscono un’astrazione logica, e questo faceva sì che ci fosse qualcosa che venisse messo a fattor comune. Quindi tante persone si sono messe a cercar di risolvere questo problema pensando alla
loro singola applicazione e per qualche anno, gli sviluppatori delle singole applicazioni hanno pensato a dei metodi ad hoc per rendere sicura la loro applicazione. In questa situazione in cui la sicurezza è selezionata internamente ad ogni singola applicazione, abbiamo vantaggi e svantaggi. Il vantaggio è che ogni applicazione pensa da sé a realizzare la sicurezza e quindi il problema se così si può dire è demandato all’applicazione e quindi la parte comune è relativa a sua volta alla parte bassa dello stack di rete, ma fare sicurezza non è semplice e quindi sono possibili tantissimi errori di implementazione: infatti è possibile anche che qualcuno capisca la funzione ma sbagli a realizzarla. Altro grosso problema che per anni è stata una macchia nera nel campo della sicurezza è che questa strada non garantisce l’interoperabilità (a meno che non fosse stato lo stesso sviluppatore a realizzare entrambe le entità che dovevano comunicare tra loro). Quindi volendo riassumere in modo molto sintetico, per questa soluzione i seguenti punti sono fondamentali:
ogni applicazione implementa la sicurezza al proprio interno la parte in comune si limita ai canali di comunicazione (socket) possibili errori di implementazione (inventare protocolli di sicurezza non è semplice!) non garantisce l’interoperabilità
Si è quindi pensato di estendere il concetto di socket in modo da realizzare un canale logico sicuro. Sicurezza esterna alle applicazioni
La situazione è cambiata quando qualcuno ha avuto l’idea di seguire il concetto logico dei socket estendendoli in modo da realizzare un canale logico, ma sicuro. Quindi quelle applicazioni che vogliono dare un vero valore alla sicurezza e che riconoscono che ralizzare pratiche di sicurezza è un lavoro estremamente difficile, usano i socket sicuri. Ma a questo punto sorge un problema di carattere esistenziale: nel TCP/IP non esiste il livello sessione, infatti sono distinti il livelli fino al 4 (ricordiamo sono fisico (1), datalink (2), rete (3), trasporto (4) ) dopodiché il 5,6 e 7 sono fusi in un tutt’uno che poi è quello che viene trattato dalle applicazioni. Se uno esaminasse in dettaglio la pila ISO/OSI si accorgerebbe infatti che il livello sessione è quello in cui andrebbero concentrate la maggior parte delle funzionalità di sicurezza canale in quanto
una sessione altro non è che un canale logico! Quindi si è posto riparo a questo problema inventando un livello sessione sicura (perché di fatto la sessione non sicura non esiste) ed è una piccola estensione sopra i socket. Ovviamente, da questa scelta di proporre un livello “sessione sicura” derivano una serie di vantaggi:
abbiamo semplificato il lavoro degli sviluppatori applicativi (infatti cambia che nella fase di apertura del canale dovremo fornire alle primitive dei parametri aggiuntivi per dire quali funzionalità di sicurezza vengano aggiunte alla nostra applicazione, ma una volta fatto questo le write e le read funzioneranno in modo del tutto trasparente)
evitiamo possibili errori di implementazione poiché non abbiamo modificato lo stack (infatti quello che è stato fatto è creare un piccolo strato che copra il socket solo parzialmente), esiste ancora la flessibilità, in quanto la strada proposta non è detto che debba necessariamente essere scelta: la scelta è a discrezione dell’applicazione. Se qualcuno pensa infatti che la libreria che lui ha sviluppato in proprio per la sua applicazione è sicuramente migliore, potrà continuare ad usarla (caso dell’applicazione a destra in figura)
Questa ad oggi è la soluzione che va per la maggiore, e in particolare sono state sviluppate tre librerie o protocolli per implementare questo tipo di soluzione.
Protocolli di sicurezza orientati al canale di comunicazione Queste tre soluzioni le elenchiamo qui di seguito:
1. SSL / TLS o SSL, che è stato successivamente rinominato in TLS, è sicuramente il più diffuso al
mondo 2. SSH
o Il principale competitor di SSL è stato proprio questo, e ha avuto un momento di gloria soprattutto per quei problemi di politiche di esportazione che erano state imposte dagli USA. Infatti SSH è stato sviluppato in Finlandia, mentre SSL non si riusciva ad averlo in versione “forte”. Da quando le limitazioni sull’esportazione di materiale crittografico sono state rimosse, e anche SSL è stato liberalizzato, SSH è diventato una soluzione di nicchia
3. PCT o È stato proposto da Microsoft come alternativa a SSL o nessuno lo ha implementato tranne Microsoft stessa, quindi Microsoft stessa a partire
da Explorer 5 lo ha cancellato dai propri prodotti Di queste tre, iniziamo con SSL in quanto come già detto è la soluzione più diffusa al mondo. SSL (Secure Socket Layer)
Lo troviamo nella maggior parte delle applicazioni, e in tutte le salse, non soltanto collegato con il web. Come vediamo è stato proposto da Netscape Communications, ed implementa un protocollo di trasporto sicuro (circa livello sessione, non è infatti né un livello 4 né propriamente un livello 5 in quanto come già detto nella realizzazione dello stack TCP/IP non esiste, quindi siccome è comunque utile, sta lì, da qualhe parte). Quando apriamo un canale SSL o TLS quello che otteniamo sono le seguenti proprietà:
o autenticazione : va intesa come peer autentication, autenticazione delle parti che instaurano il canale. Infatti di default l’autenticazione è del server, mentre è opzionale che il server chieda l’autenticazione al client. Questo se ci pensiamo bene è qualcosa molto strano, in quanto le cose al livello logico dovrebbero essere invertite. In realtà, SSL è stato inventato per proteggere il commercio elettronico dove la cosa più importante è autenticare il server. E’ per questo che l’opzione di default è quella ed è irremovibile : non si può configurare SSL per non autenticare il server, in quanto quello è il default. Opzionalmente si può richiedere anche al client di autenticarsi
o riservatezza dei messaggi : tutti i canali che vengono trasmessi su un canale SSL sono cifrati. Nelle versioni più recenti la riservatezza può anche essere di soli zero bit, quindi è anche possibile NON AVERE RISERVATEZZA. Questo dipende dalla configurazione del cliente e del server, ed è stato fatto principalmente perché la parte di cifratura simmetrica è comunque pesante quindi per tutte le applicazioni che non necessitano di questa proprietà di sicurezza è anche possibile rimuoverla richiedendo di fare riservatezza usando l’algoritmo NUL che richiede una chiave da zero bit
o autenticazione ed integrità dei messaggi : questa è ancora una volta una proprietà inamovibile,
e sottolinea il fatto che autenticazione e integrità sono molto più importanti in generale della riservatezza (ricordiamoci quanto detto dai militari secondo i quali solo il 10%‐20% dei messaggi che loro trasmettono hanno bisogno si riservatezza, mentre il 100% hanno bisogno di autenticazione e integrità)
o protezione da replay e da filtering : trattandosi di un ambiente di rete e quindi fondamentalmente insicuro, si applica anche la protezione da replay (ritrasmissione di pacchetti) e da filtering (ovvero cancellazione dei pacchetti). Degno di nota è che nel caso venga rilevato un attacco di replay o di filtering, la reazione è quella di chiudere il canale con conseguente blocco dell’applicazione. Questo significa che chi ci fa un attacco di quel tipo non riesce a farci fare qualcosa che non prevedevamo, ma riesce sicuramente a farci un Denial‐of‐Service. Questa non è da considerare una nota di demerito di SSL, ma è un problema generale delle comunicazioni in rete: in ogni caso infatti chi gestisce l’infrastruttura di comunicazione potrebbe impedire le comunicazioni se solo lo volesse.
SSL essendo collocato a questo livello “4 e mezzo”, non dipende da una specifica applicazione. E’ stato pensato così bene che si adatta facilmente ad un qualunque protocollo applicativo che si basi su un canale affidabile. Notiamo che non c’è niente dentro SSL che dice che SSL si usa con TCP : se noi avessimo un altro protocollo al livello di trasporto affidabile lo potremmo usare anche con quello. Ovviamente oggi TCP va per la maggiore, quindi alla fine SSL è applicabile facilmente a tutti i protocolli applicativi basati su TCP, come ad esempio HTTP, SMTP, NNTP, FTP, TELNET. Ad es. famoso HTTP sicuro (https non è un protocollo, ma è una URL, una abbreviazione per dire che vogliamo http sopra SSL!!!), che opera alla porta 443/TCP. Porte ufficiali per applicazioni SSL Qui vedete l’elenco di tutte le porte ufficiali che sono state riservate per l’uso delle versioni protette con SSL dei maggiori protocolli, quindi esattamente come si ha per https 443/tcp, abbiamo smtps 465/tcp a posto della classica porta 25. Questo perché c’è differenza tra usare la versione normale e la versione sicura.
SSL ‐ autenticazione e integrità
Vediamo come SSL realizza le funzioni che abbiamo presentato. All’atto dell’apertura del canale viene fatta la peer authentication. Il server si presenta con un proprio certificato X.509 valido perché il client lo sottoporrà ad una sfida di tipo asimmetrico. Per quanto riguarda l’autenticazione e l’integrità, dobbiamo distinguere la peer authentication dalla data authentication:
1. Per la peer authentication siccome si deve autenticare prima il server, il server si autentica presentando la propria chiave pubblica all’interno di un certificato X.509:
o un server per essere un server SSL deve possedere chiave privata e chiave pubblica e deve avere la chiave pubblica certificata (le chiavi pubbliche non si possono mandare in giro così e devono essere all’interno di un certificato).
o Ovviamente al server non basta mandare il certificato per dimostrare la propria identità quando qualcuno manda ad un utente il proprio certificato, l’utente gli manda
una sfida asimmetrica per vedere che lui possiede la chiave privata corrispondente alla pubblica che gli ha fornito.
2. Il server una volta autenticatosi ha la possibilità di chiedere al client di autenticarsi: o questo step è opzionale ed è controllato dal server, infatti l’unico schema di
autenticazione supportato da SSL è quello dei certificati quindi può anche darsi che il client non possieda un certificato X.509, nel qual caso non sarebbe possibile per lui collegarsi al server.
quando ci colleghiamo al portale della didattica il server ci chiede di dargli il nostro certificato
noi non ce l’abbiamo e gli diciamo di andare avanti lo stesso e di conseguenza il server ci chiede username e password
per alcuni docenti che hanno il certificato è possibile entrare direttamente senza digitare username e password, poiché si viene riconosciuti direttamente dal certificato.
Quello del portale della didattica è un server web con client authentication. • Esso chiede se il client ha un certificato e se ha questo certificato gli fa la
sfida e se viene superata correttamente il client può entrare. • Questa fase è opzionale poiché la diffusione di certificati non è così
grande poiché vi sono problemi nell’utilizzarli. La gente ha difficoltà nel gestire correttamente le password, figuriamoci con le chiavi private che sono anche solo concettualmente più complicate.
o Una volta che un canale SSL è stato instaurato, abbiamo detto che altre due funzioni irremovibili sono autenticazione e integrità, quindi tutti i dati vengono protetti per autenticazione ed integrità tramite keyed digest. In particolare lo standard definisce MD5 o SHA1 come algoritmi di hash di base con una chiave simmetrica concordata tra server e client. In più per evitare la cancellazione e il replay ogni segmento SSL viene numerato tramite un MID, message identifier (quindi in questo modo non è possibile duplicare o cancellare i dati), un numero progressivo. Qui a differenza di quanto avevamo detto con IPsec in cui avevamo precisato che poiché IPsec lavora con IP (servizio best‐effort senza garanzie di consegna né sull’ordine) non aveva la necessità di andare a numerare i pacchetti con 1,2,3 … ma li potevamo anche chiamare pippo,pluto, paperino…, qui invece sfruttando un protocollo di trasporto affidabile che mi garantisce consegna e ordine di consegna ha importanza che siano numeri e che siano progressivi!
SSL – Riservatezza Per quanto riguarda la riservatezza, il client genera una session key quindi una chiave generata al volo possibilmente mai più riutilizzata. La chiave può essere comunicata al server cifrandola con la chiave pubblica del server e il server, che ha la chiave privata, provvederà a decifrarla e da lì in poi client e server useranno quella chiave per la cifratura simmetrica dei dati con uno degli algoritmi ammessi da SSL (RC2, RC4, DES, 3DES o IDEA). Lo scambio di chiavi può anche essere concordata sfruttando Diffie Hellman oppure Fortezza‐KEA (il sistema proprietario dei militari americani ed è una variante di Diffie Hellman). SSL
A questo punto vediamo come opera SSL, e l’esempio di applicazione pratica che si è deciso di usare è quello di un browser che desidera parlare con un server. In generale, vediamo a destra un client SSL e a sinistra un server SSL. Seguiamo a questo punto le interazioni:
1. Innanzitutto bisogna che il client dica al server che desidera parlare SSL; questo viene fatto con la url https.
2. Una volta che il client ha avvisato il server e sta parlando SSL, la prima operazione svolta dai due nodi è quella di scambiarsi la loro configurazione di sicurezza :
o Per configurazione di sicurezza si intende che ognuno dei due dichiara gli algoritmi che è in grado di supportare. Si tratta di una negoziazione: lo standard prevede che i due nodi scelgano l’algoritmo più forte in comune tra di loro (sia che si parli di riservatezza a sia che si parli di autenticazione e integrità). Quindi gli algoritmi sono stati messi in scala di preferenza.
o Può capitare che in questa fase i due nodi non trovino niente in comune fra di loro, quindi il collegamento si può interrompere già a questo livello.
3. Una volta che i sistemi hanno trovato una configurazione comune il primo passo è quello dell’autenticazione del server. Il server manda il proprio certificato che deve contenere come common name (CN) o come subject alternative name di tipo DNSname lo stesso identificativo dell’applicazione a cui mi sto collegando. Poiché mandare il certificato come detto non serve a niente perché essendo un dato pubblico chiunque può copiarlo, il client gli invia una sfida a cui deve rispondere correttamente. Se il server non risponde correttamente, il collegamento può essere interrotto a questo punto.
4. Opzionalmente (ecco il motivo della linea tratteggiata rappresentata in figura), il server può chiedere anche al client di mandare il certificato X.509 e di rispondere ad una sfida. Anche in questo caso se la sfida fallisce il collegamento viene interrotto.
5. Se tutti questi passi hanno avuto successo il client e il server sono in grado di crearsi un canale sicuro sul quale gli attacchi (frecce rosse) rimbalzeranno
Esistono varie versioni di SSL (SSL‐2, SSL‐3, TLS 1.0, TLS 1.1). Dal punto di vista architetturale il grosso cambiamento è stato introdotto quando si è passati da SSL‐2 a SSL‐3. Infatti SSL‐2 era un protocollo molto basilare, mentre SSL‐3 cominciava a diventare un protocollo strutturato, ben fatto. Infine il TLS aggiunge soltanto delle piccole modifiche e non cambia l’impianto. Architettura di SSL‐3
SSL‐3, come vediamo, è stratificato sopra un protocollo di rete affidabile, quindi sopra questo (che ad esempio, come detto non è un vincolo, può essere TCP) vediamo il cosiddetto SSL Record Protocol, ossia un formato per trasportare dati da un capo all’altro del canale. Questo Record Protocol di SSL serve per “imbustare” i dati applicativi una volta che il canale è stato creato, ma viene anche utilizzato dal protocollo SSL nella prima fase, che è anche detta fase di handshake che viene quindi veicolata sopra il Record Protocol di SSL: l’ SSL Handshake Protocol è il protocollo con il quale ci si mette d’accordo su quali algoritmi andare ad usare. Quando capita che si verifichi un attacco SSL prevede un piccolo protocollo che serve per comunicare che si è verificato un errore. Questo protocollo prende il nome di SSL Alert Protocol con cui client e server si scambiano gli allarmi. E’ anche possibile dirante una sessione SSL decidere di cambiare o gli algoritmi o le chiavi o entrambi, e questo lo si fa con l’SSL Change Cipher Spec Protocol. Architettura di SSL‐2 SSL‐2 come già detto è un protocollo estremamente più semplice in quanto non prevede gli allarmi e non prevede di cambiare in corso di trasmissione i parametri o gli algoritmi decisi in fase di scambi della configurazione di sicurezza.
Session‐id
Adesso consideriamo un piccolo problema. L’introduzione di SSL complica non poco una transazione Web.
1. open, 2. GET page.htm, 3. page.htm, 4. close 1. open, 2. GET home.gif, 3. home.gif, 4. close 1. open, 2. GET logo.gif, 3. logo.gif, 4. close 1. open, 2. GET back.jpg, 3. back.jpg, 4. close 1. open, 2. GET music.mid, 3. music.mid, 4. close
Infatti tipicamente aprendo con il server web una connessione alla porta 80 per ottenere la pagina page.htm, quello che viene fatto è che il server ci trasmette la pagina, e chiude (a meno di uso di http v1.1 che come sappiamo permette le connessioni persistenti). Nel momento in cui prova a visualizzare la pagina si accorge che manca l’oggetto home.gif, quindi aprirà una nuova connessione e richiederà l’oggetto home.gif, e anche lì una volta che il server ci ha fornito l’oggetto chiuderà la connessione. Questo discorso vale per ogni oggetto che compone la pagina. Ma se per ogni oggetto si devono rinegoziare parametri crittografici per SSL il collegamento si appesantisce molto. Infatti, la fase di negoziazione è l’unica in cui si utilizzano gli algoritmi asimmetrici che sono quelli più pesanti dal punto di vista computazionale, quindi andiamo a ripetere proprio la parte più pesante. Per evitare di rinegoziare ogni volta i parametri e rifare l’autenticazione, e quindi appesantire troppo i collegamenti, è stato introdotto il concetto di SSL Session Identifier. Si può cioè dire che ogni collegamento fa parte di una medesima sessione logica, ossia:
• quando mi presento il server mi fornirà un numero, che sarà il Session Identifier, sottolineando il fatto che ha concluso con successo la transazione con noi
• il client la volta successiva il client potrà fornire questo numero identificativo al server per sottolineare il fatto che già una volta hanno negoziato i parametri e si sono autenticati. Questa cosa è opzionale, nel senso che il server numera sempre tutte le sessioni,ma se vuole può rifiutare l’uso del Session Identifier. In particolare lo può rifiutare in assoluto, quindi rifiutarlo sempre, oppure anche nel caso di server che accetti di continuare la sessione precedente potrebbe non accettare il Session Identifier dopo un certo lasso di tempo. Infatti, i Session Identifier devono essere sempre mantenuti all’interno di una tabella, e questa potrebbe crescere molto in dimensioni qualora il server ricevesse tante richieste al secondo. Quindi il suggerimento è accettare il Session Identifier ma limitarne la validità nel tempo in modo da avere anche un meccanismo per poter sfoltire quella tabella. Lo scopo non è quello di evitare l’handshake nell’arco di giorni, o di un lungo periodo di tempo, bensì quando io mi presento a raffica come nel caso di una pagina web. Infatti quello che viene detto è che la vita di un session identifier dovrebbe essere limitata a qualche minuto.
Qui di seguito riportiamo la figura che mostra il modo in cui cambia la fase di handshake nel caso in cui il server accetti l’uso del Session Identifier:
SSL con session‐ID
Notiamo che i passi sono i seguenti:
1. Come sempre bisogna che il client dica al server che desidera parlare SSL; questo viene fatto con la url https.
2. A questo punto, ancora prima che inizi la fase di scambio della configurazione di sicurezza, il client fornisce al server il Session Identifier.
3. Il server a questo punto dirà che il client dichiara di avere il “lasciapassare”, ma potrebbe benissimo essere un impostore, che quindi ha scelto un numero a caso e ha indovinato, quindi se il client conosceva veramente il Session Identifier, e di fatto non ha solo avuto fortuna, allora puoi farmi le tue domande, ma me le dovrai fare su un canale sicuro! Il che significa che le domande devono contenere il keyed‐digest fatto con l’algoritmo giusto, con la chiave giusta, e i dati dovranno essere cifrati con l’algoritmo giusto e così via. Se il client era un impostore, allora non riuscirà a mettere i codici di protezione giusti e verrà quindi rifiutato.
Quindi ancora una volta questa cosa mi permette al più di fare un DoS, ovvero terrò temporaneamente impegnato il server per controllare i dati. Ma poiché il keyed‐digest è la prima cosa che viene controllata, ed è anche quello più veloce da calcolare e quindi verificare, non appena quello non torna si chiude!
Una piccola nota riguarda il fatto che lo scambio della configurazione di sicurezza avviene in chiaro, in quanto ancora non è stato creato il canale SSL, ma anche a voler conoscere gli algoritmi, non si sapranno comunque le chiavi da usare che verranno invece scambiate o concordate con uno degli algoritmi visti prima (RSA, DH o Fortezza‐KEA).
SSL‐3 record protocol Una volta che viene creato il canale, abbiamo detto che i dati verranno automaticamente protetti nel momento in cui l’applicazione farà una write su questo socket sicuro. Quindi a partire da uno stream di dati applicativi, io provvederò a scriverli sul canale senza alcuna particolare preparazione. Quello che SSL o TLS fa è prendere i dati applicativi e creare i cosiddetti fragment, ovvero i frammenti. SSL può trasmettere in un colpo solo fino ad un massimo di 214 byte, può anche trasmetterne di meno: quella è quindi la dimensione massima di un frammento. E’ importante notare che i frammenti SSL non hanno niente a che fare con i frammenti delle reti TCP‐IP. Ognuno di questi frammenti può essere opzionalmente compresso; la compressione non è obbligatoria ma è utile sia perché riduce la quantità di dati da trasmettere quindi migliora la velocità di trasmissione , sia perché tende a togliere le similitudini che ci sono all’interno dei dati ( e come già detto in passato cifrare dei dati compressi è meglio che cifrare i dati normali, non soltanto per una minore quantità ma anche perché si è già tolta una ridondanza nei dati di partenza e quindi si complica la vita agli eventuali attaccanti). Sul frammento, normale o compresso, viene calcolato un MAC tramite un keyed‐digest, e questo codice con doppia funzione di autenticazione e integrità viene aggiunto in coda. A questo punto se stiamo usando un algoritmo di cifratura a blocchi, viene fatto il padding , in modo da renderlo di dimensioni
opportune perché l’algoritmo possa cifrarlo, e questo viene cifrato, e gli si aggiunge un piccolo header (che dichiara che questo è un frammento SSL).
Questo viene consegnato al livello sottostante, tipicamente il TCP, perché possa essere trasmesso. TLS‐1.0 record format Questo pacchetto costituito da header insieme al payload cifrato corrisponde esattamente a questo formato.
Analizzandolo nel dettaglio, notiamo che l’header è costituito dai seguenti campi:
[uint8] type : può assumere i seguenti valori a seconda di quello che sta trasportando : change_cipher_spec (20), alert (21), handshake (22), application_data (23)
[uint16] version = major number[uint8] + minor number[uint8] , intesi come major e minor number di SSL, quindi vedremo una cosa curiosa che quando si è passati a TLS si è continuata la numerazione quindi nel TLS v1.0 in realtà noi troveremo 3.1 per dire che è il successore di SSL 3.0
[uint16] length: mi dicono quanti sono i dati che seguono. Anche se sono 16 bit, la lunghezza scritta qua dentro non può mai superare 214 . Notiamo che nel caso in cui si stia trattando un record compresso, allora al massimo la compressione può aggiungere 1024 byte al blocco base. In ogni caso, una volta decompresso, la quantità di dati DEVE STARE ALL’INTERNO DI UN BUFFER DA 214 BYTE. Quindi, per il campo length, i valori possibili sono:
<= 214 (record non compressi) per compatibilità con SSL‐2 <= 214 + 1024 byte (record compressi)
TLS ‐ calcolo del MAC Il calcolo del MAC viene fatto nel seguente modo. Si usa un algoritmo di digest (MD5 o SHA‐1), e viene usato nel seguente modo: MAC = message_digest( key, seq_number || type || version || length || fragment )
message_digest
dipende dall’algoritmo scelto key
vengono negoziate due chiavi che risponde alla direzionalità in cui sta avvenendo lo scambio dati, una dal client al server, l’altra dal server al client. Quindi bisogna usare la chiave giusta per la direzione a cui corrisponde questo flusso di dati
seq_number intero a 32 bit
Quindi il keyed‐digest viene calcolato sulla chiave e anche su tutto il pacchetto (header più payload) quindi non mi protegge solo i dati, ma anche tutti i campi dell’header. Viene protetto nella sua interezza tutto il record TLS. Notiamo inoltre che il campo dedicato al numero di sequenza è un campo a 32 bit, questo significa che una volta che quel campo arriva al suo valore limite 232 frammenti, il canale verrà automaticamente chiuso perché altrimenti potrebbe verificarsi un overflow su questo campo e non si riuscirebbe più a riconoscere correttamente il replay. E’ da notare inoltre che nelle ultime versioni sia di Firefox che di Internet Explorer, è stato rimosso SSL‐2 dall’elenco dei protocolli di sicurezza abilitati e questo perché SSL‐2 conteneva dei bachi di sicurezza.
SSL‐3: novità rispetto a SSL‐2 Vediamo quali novità ha introdotto SSL‐3 rispetto ad SSL‐2:
compressione dei dati: opzionale viene fatta prima della cifratura (in quanto se fatta dopo non servirebbe!! )
opzionalità della cifratura dei dati: per avere solo autenticazione e integrità
possibilità di rinegoziare la connessione: cambio periodico delle chiavi cambio degli algoritmi
SSL‐3 handshake protocol Concentriamoci a questo punto sull’Handshake Protocol. Questo è uno degli elementi caratterizzanti di SSL e lo usiamo come esempio per capire come operando su un canale insicuro si possa creare un’associazione sicura tra due nodi. In particolare l’Handshake Protocol assolve le seguenti funzioni:
concordare una coppia di algoritmi per confidenzialità ed integrità dei dati stabilire una chiave simmetrica tramite operazioni a chiave pubblica (RSA, DH o Fortezza‐KEA) scambiare dei numeri casuali tra client e server per la successiva generazione le chiavi che serviranno per confidenzialità ed integrità
negoziare il session‐id scambiare i certificati necessari
Confidenzialità dei dati
Ci sono un numero troppo elevato di chiavi. Infatti uno potrebbe essere portato a pensare che questo problema non sussista in quanto il client potrebbe inventare una chiave, comunicarla al server e il gioco è fatto. In realtà vengono messe dentro tantissime chiavi: ad esempio per il MAC usiamo la chiave e poi tutto il record costituito da header più payload. Il MAC lo mettiamo in coda al pacchetto, e tutto
questo viene cifrato con un algoritmo simmetrico che di solito richiede non solo un IV (ovviamente è necessario un vettore di inizializzazione se è stato scelto un algoritmo di tipo a blocchi) ma anche una chiave simmetrica che è diversa da quella che abbiamo utilizzato per calcolare il MAC.
Rapporto tra chiavi e sessioni
Ad ogni connessione (che è una cosa diversa dalla sessione ,infatti una sessione quella a cui fa riferimento il session‐id è costituita da più connessioni, mentre una connessione è un collegamento, un canale, un socket aperto e chiuso) il client e anche il server generano un numero casuale. Questi numeri serviranno per alterare in qualche modo quei segreti che invece saranno comuni a più connessioni. In particolare quello che
viene stabilito attraverso la crittografia asimmetrica (PKC) non è direttamente una chiave bensì il pre‐master secret, ovvero un segreto comune a client e server, quindi la prima volta se io non ho già un session‐id quello che viene scambiato è questo pre‐master secret: è questo quello che si mantiene quando viene riutilizzato un certo session‐id.
Dall’unione del pre‐master secret e dei numeri random viene generato un master secret. I numeri random (client random e server random) sono generati tra client e server ad ogni connessione:
la prima volta questi random sono usati per creare il master secret (solo la prima volta; per questo motivo la freccia è tratteggiata)
invece, ad ogni connessione, questi numeri random assieme al master secret vengono usati per una serie di algoritmi per generare le chiavi per il MAC, le chiavi per cifrare e il vettore di inizializzazione (IV) per cifrare. Queste chiavi qui sono diverse per ogni singola connessione, quindi ciò che un server si va a tenere in memoria assieme al session‐id quando accetta un session identifier è gli algoritmi che abbiamo scelto, il pre‐master secret ed anche il master secret. Quindi come chiavi sono queste due quelle che lui si tiene, le altre sono calcolate di volta in volta.
Le operazioni di chiave pubblica sono fatte solo quando si genera un master secret, e sono in questo modo ridotte.I meccanismi possono essere di due tipi: permanenti ed effimeri.
Meccanismi permanenti Il client decide una chiave simmetrica e la spedisce al server cifrandola con la chiave pubblica del server. Se qualcuno scopre la chiave privata del server è in grado di leggere tutte le informazioni generate (se si usa sempre la stessa chiave pubblica).
Meccanismi “effimeri” Si chiama meccanismo effimero un meccanismo che usa delle chiavi che non verranno mai più utilizzate. Quindi delle chiavi cosiddette usa e getta generate al volo. Al posto di avere delle chiavi asimmetriche permanenti può creare le chiavi al volo (e generando al volo la chiave pubblica vuol dire che non la potrò fare certificare dalla CA perché la procedura è troppo lunga, quindi il server si genera al volo la chiave pubblica e la chiave privata e se la autocertifica attraverso un certificato X.509. Inoltre se uso DH allora sarà adatto in quanto DH è veloce nella generazione delle chiavi, mentre RSA è lento, quindi se voglio usare RSA come compromesso dovrò riusare la stessa chiave
N volte (genererò una nuova chiave per il server dopo un certo lasso di tempo o dopo un certo numero di volte). Perché può essere utile il meccanismo usa e getta? Perché attraverso questo meccanismo si può garantire la perfect forward secrecy : noi sappiamo che il server ha una chiave pubblica e una chiave private. Immaginiamo di non usare la soluzione di cui abbiamo appena parlato, ma di usare sempre la stessa coppia chiave pubblica, chiave private. Vuol dire che il client inventerà questo pre‐master secret e lo manderà al server cifrato con la chiave pubblica del server. Tutti i client faranno questa operazione. In mezzo c’è un cattivo che sta facendo sniffing, e registra tutti i pacchetti e anche l’handshake. Se prima o poi nel future riesce a catturare la chiave private del server, allora sarà in grado di andare a cifrare tutti quei pacchetti. Viceversa, se la coppia chiave pubblica, chiave private viene cambiata frequentemente, allora il cattivom sarà in grado di decrifrare solo i pacchetti scambiati per quell’istante di tempo, non i pacchetti precedenti e nemmeno quelli futuri. Con i meccanismi effimeri la chiave privata del server viene usata non per ricevere il segreto cifrato bensì solo per la firma della chiave pubblica che verrà poi usata per lo scambio dei dati.
Il server SSL ha nel suo certificato essenzialmente 2 cose:
1. il bit di key usage che indica Digital Signature, per indicare che questo certificato può essere usato per fare firma digitale perché altrimenti lui non riuscirebbe a rispondere alla sfida asimmetrica
2. ha anche il bit di KeyEncipherment per poter ricevere il pre‐master secret crifrato dal client
Queste sono logicamente due funzioni diverse. Il discorso dei meccanismi effimeri è relativo alla seconda di queste, perché se io sto facendo sniffing di traffico cifrato non sono in grado di leggerlo ma se riuscissi a conoscere la chiave privata allora potrei ricostruire tutte le sessioni. In particolare, con la chiave usata per KeyEncipherment posso non solo ricostruire tutte le sessioni ma potrò avere in chiaro le sessioni future. Il meccanismo si chiama di perfect forward secrecy perché viceversa se io non ho usato la chiave del server per fare entrambe le cose ma io ho usato la chiave privata del server solo per digital Signature per firmare una seconda chiave che è quella con cui viene fatto lo scambio chiavi: è questa qui la chiave effimera che viene generata ad ogni connessione. In questo modo anche se qualcuno ne viene a conoscenza quella chiave sarà valida solo per quella connessione per cui non inficia la sicurezza delle prossime connessioni (per questo si chiama “forward” secrecy, sicurezza in avanti).
Questi sono esattamente i messaggi che vengono scambiati tra client e server durante la fase di handshake. Le linee in nero rappresentano i messaggi obbligatori ovvero quelli che vengono scambiati sempre a prescindere da quale siano gli algoritmi usati, quelle tratteggiate sono tipicamente delle cose opzionali. Vediamole in sequenza:
Innanzitutto il client manda il cosiddetto “client hello” a cui il server risponde con il suo “server hello”.
Se necessario il server invia il proprio certificato ed eventualmente una richiesta di un certificato al client
Segue una parte opzionale di scambio chiave Il client può mandare il suo certificato se ce l’ha l’unico passo obbligatorio è il “client key exchange”; il client deve promettere la verifica del certificato. Lo scambio termina sempre con un doppio handashake di basso livello, nel senso che sia il client sia il server mandano un comando “change cipher spec” (fino a questo punto tutto lo scambio è avvenuto in chiaro);
I messaggi di handshake vengono protetti a posteriori; col “change cipher spec” ci si accorda su come proteggere i dati da quel momento in
poi; col messaggio di finished sia in una direzione sia nell’altra viene mandato in modo protetto un digest di tutti i dati che ci si è scambiati.
quindi se qualcuno in mezzo (l’attaccante) aveva cambiato, per esempio, le dichiarazioni degli algoritmi del client viene fregato, dal momento che il server che riceve questi dati in modo sicuro (perché è stata già attivata la protezione), è in grado di confrontare il digest calcolato su tutti i dati che ha ricevuto con quello inserito all’interno del “finished”.
Quindi dentro il finished c’è un digest che non è un digest del singolo messaggio ma di tutta la sequenza di handshake.
Client hello Il client con questo messaggio dichiara le seguenti cose :
La massima versione di SSL che lui è in grado di supportare, quindi si assume che il client sia in gradi di usare anche le versioni precedenti. Questa sarà la versione preferita dal client
28 byte generati in modo pseudo‐casuale per la generazione delle chiavi con il server un identificatore di sessione (session‐id)
0 per iniziare una nuova sessione o se non lo vuole usare diverso da 0 per chiedere di riesumare una sessione precedente
elenco delle “cipher suite” (insieme degli algoritmi di cifratura, algoritmo di scambio chiavi e algoritmo per autenticazione e per integrità dei dati) supportate dal client
elenco dei metodi di compressione supportati dal client Quindi con questo messaggio il client sta dichiarando le proprie capabilities. Server hello Il server risponde anche lui con un messaggio di “server hello”, ma senza dichiarare nulla bensì effettuando direttamente le scelte. Quindi quelle che seguono, sono le scelte fatte dal server:
versione di SSL scelta dal server : il server dovrebbe scegliere sempre gli algoritmi più forti tra quelli in comune tra lui e il client
28 byte generati in modo pseudo‐casuale un identificatore di sessione (session‐id)
nuovo session‐id se session‐id=0 nel client‐hello oppure gli manda un nuovo session‐id se rifiuta il session‐id proposto dal client
rimanda indietro il session‐id proposto dal client se il server accetta di riesumare la sessione
“cipher suite” scelta dal server dovrebbe essere la più forte in comune col client
metodo di compressione scelto dal server Cipher suite Come già detto, la cipher suite altro non è che un nome per identificare la triade costituita da :
algoritmo di scambio chiavi algoritmo di cifratura simmetrico algoritmo di hash (per il MAC)
Le cipher suite sono definite negli standard e tipicamente hanno dei nomi come quelli riportati sopra:
SSL_NULL_WITH_NULL_NULL: cioè non viene protetto lo scambio delle scambio chiavi, la cifratura simmetrica con 0 bit, e l’hash non viene fatto
SSL_RSA_WITH_NULL_SHA: scambio chiavi con RSA, ma cifratura 0 e algoritmo di hash SHA. A cosa serve l’algoritmo di scambio delle chiavi se la cifratura è nulla? Anche se la cifratura è nulla la chiave simmetrica serve anche al digest quindi è necessario avere un algoritmo di scambio chiavi.
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5: questo è un esempio di algoritmi che si usavano quando c’erano dei limiti di esportazione
RSA versione export (RSA versione export: si hanno delle chiavi limitate a 512 bit se si usano per cifrare dei dati; in questo caso RSA è per scambio chiavi e quindi si deve cifrare la chiave; quindi al massimo la chiave sarà da 512 bit)
RC2 tagliato a 40 bit (perché più di questo non si poteva esportare). SSL_RSA_WITH_3DES_EDE_CBC_SHA:
scambio chiavi con RSA (pieno, non versione export), cifratura con 3DES in modalità EDE CBC, algoritmo di hash SHA che è SHA‐1 (in quanto SSL non ha ancora recepito le versioni successive di SSL).
Certificate (server)
Il messaggio certificate del server manda il certificato per la server authentication. Come già detto in precedenza, bisogna prestare attenzione al fatto che il campo subject o il campo subjectAltName deve coincidere con l’identità del server. Se abbiamo usato come URL l’indirizzo IP allora nel certificato deve esserci l’indirizzo IP. Inoltre il certificato può essere solo di firma o anche per la cifratura:
il certificato ha un campo particolare che si chiama keyUsage che dice per quali scopi il certificato può essere utilizzato
se in questo campo c’è scritto che è usato solo per la firma allora poi è necessaria la fase di server‐key Exchange, perché se è solo di firma allora vuol dire che questo certificato non può essere usato dal client al fine di inviare al server il pre‐master secret
Certificate request E’ quello con cui il server richiede l’autenticazione del client e nel richiedere l’autenticazione il server manda al client anche la lista delle CA che il server ritiene fidate : questo è importante in quanto il client può anche avere dei certificati, ma il server dichiara quali sono le CA che lui ritiene fidate quindi il client dovrà mandare il certificato solo se emesso da una delle CA che compare in quella lista. Qualora non ne abbia uno allora potrà fare a meno di inviarglielo.
Server key exchange
Come già detto questa fase è fondamentale se il certificato del server non è valido per fare la cifratura, quindi se il server ha un certificato RSA valido solo per fare la digital signature. Inoltre, è richiesto questo messaggio anche nei seguenti casi:
server ha certificato RSA solo per firma si usa DH anonimo o effimero per stabilire il master‐secret ci sono problemi di export e si devono usare chiavi RSA/DH temporanee Fortezza
Questo è l’unico messaggio con firma esplicita da parte del server , ovvero il server manda o i parametri
Diffie Hellman o la chiave che ha generato al volo e la manda firmata con la chiave presentata precedentemente. Questo è l’unico messaggio che richiede la firma da parte del server. Inoltre notiamo che in termini di prestazioni usare meccanismi effimeri richiede maggio tempo nella fase di handshake perché richiede una firma esplicita da parte del server : ricordiamo infatti che le verifiche RSA sono veloci, mentre le firme RSA sono lente. Certificate (client)
Come già detto, questo messaggio trasporta il certificato per la client authentication, e deve essere stato emesso da una delle CA fidate elencate dal server nel messaggio Certificate Request. Client key exchange Questo messaggio assume varie forme a seconda di quello che abbiamo scelto di fare. Può essere:
pre‐master secret cifrato con la chiave pubblica RSA del server (temporanea o dal certificato) parte pubblica di DH Fortezza
Per quanto riguarda lo scambio di chiavi può capitare che:
il client mandi un pre‐master secret cifrato con la chiave pubblica RSA del server (se si tratta di una chiave RSA temporanea oppure se il certificato permette crittografia con la chiave crittografica)
oppure se il server accetta una scambio Diffie Hellman allora il client gli manda la parte pubblica di Diffie Hellaman o i parametri di fortezza che sono analoghi ai parametri pubblici di DH.
Certificate verify Nella fase di certificate verify si fa la prova esplicita di firma; in particolare il client firma con la propria chiave privata l’hash calcolato su tutti i messaggi che precedono questo. Quindi questa è la parte di sfida nei confronti del client. Inoltre questa parte viene fatta solo se il client alla richiesta del certificato ha risposto con un certificato valido rispetto alla lista delle CA fidate che gli è stata comunicata dal server. Change cipher spec Questo messaggio provoca l’aggiornamento degli algoritmi da usare per la protezione, e permette di passare dai messaggi precedenti in chiaro all’uso nei messaggi successivi degli algoritmi appena negoziati. A rigore come visto prima fa parte di un protocollo specifico e non dell’handshake. Secondo varie analisi potrebbe anche essere eliminato, ma al momento questo resta. Finished Il finished è il primo messaggio protetto con gli algoritmi negoziati, ed è fondamentale per autenticare tutto lo scambio. Ricordiamo infatti che i messaggi scambiati prima sono in chiaro, e qualcuno potrebbe essersi messo in mezzo e quando si negoziavano gli algoritmi potrebbe aver forzato il client all’utilizzo di algoritmi poco efficaci. Il messaggio di finished evita che si vengano a creare queste situazioni perché contiene il MAC calcolato su tutti i messaggi di handshake precedenti (tranne il change cipher spec) tramite l’uso del master secret. Permette di evitare attacchi man‐in‐the‐middle di tipo rollback ( i rollback sono quelli che fanno scendere il livello di protezione che si è scelto). Sono necessari due messaggi di finished. Il messaggio di finished è ovviamente diverso per il client e per il server visto che conterrà il MAC calcolato sui messaggi che il client ha mandato al server, e che il server ha mandato al
client, e poiché questi sono diversi anche i finished saranno diversi. TLS Quando si decise di standardizzare SSL e quindi quando SSL è stato aperto all’IETF, ne fu cambiato il nome in TLS (Transport Layer Security): il cambio del nome è stato politico, poiché Microsoft non voleva accettare di implementare una cosa con un nome creato da un concorrente.Esistono due versioni TLS 1.0 del gennaio 99 e il nuovissimo TLS 1.1 (dell’aprile 2006). Al 99% TLS‐1.0 coincide con SSL‐3. Una cosa su cui si è messo particolare accento è stata la scelta di algoritmi non proprietari, quindi algoritmi su cui non fosse necessario pagare le royalty. La cipher suite che è stata scelta è stata la seguente:
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA : quindi scambio chiami con DH effimero, firma DSS e cifratura 3‐DES EDE CBC con SHA per integrità.
L’unica differenza sostanziosa è che il key digest non è più un keyed digest generico, inventato da Netscape, ma un digest HMAC. TLS‐1.1 In realtà il TLS 1.1 coincide dal 99% con la versione 1, ma corregge soltanto un paio di piccoli bachi che permettevano degli attacchi contro le varie versioni di TLS. In particolare c’erano alcuni attacchi contro il CBC. Quindi l’IV implicito è stato rimpiazzato da IV esplicito il che ha comportato che la dimensione dei pacchetti sia un pochettino cresciuta. Inoltre in caso di errori di padding ora usano il messaggio di alert bad_record_mac (invece di decryption_failed): può sembrare un dettaglio, ma questo forniva dei dettagli all’attaccante attraverso cui quest’ultimo poteva risalire alla chiave. Infine:
1. In più sono stati definiti dei registri che tiene l’organizzazione IANA per definire quali sono i numeri di protocollo
2. Se si chiude il canale prima che la sessione sia conclusa, il session‐id non viene cancellato; questo viene fatto per migliorare le performance
3. Poi ci sono tutta una serie di note che spiegano l’interpretazione di TLS nei confronti di vari attacchi possibili
Evoluzione di TLS TLS continua ad evolversi e ci sono delle RFC che documentano delle aggiunte
Kerberos si può usare per la parte di autenticazione Si possono usare anche AES o algoritmi a curva ellittica qualcuno ha anche inventato algoritmi tipo Camelia (che è un altro algoritmo simmetrico) oppure è possibile avere una chiave cifrata a mano e precondivisa.
Queste diversità sono dovute al fatto che si possono avere ambienti con capacità computazionali differenti e quindi si deve avere il massimo della flessibilità. Si hanno anche diversi metodi di compressione, infatti in SSL‐3 era stata definita la possibilità di negoziare gli algoritmi di compressione ma non era stata fatta menzione di quali algoritmi di compressione specificare. E’ stato quindi inserito LSZ che è l’algoritmo di compressione alla base dello ZIP, e inoltre sono state aggiunte anche delle estensioni application‐specific. DTLS (Datagram Transport Layer Security) TLS ha avuto un così positivo impatto nell’ambito della sicurezza che si è deciso di sviluppare anche una
versione per datagrammi. Notiamo che come già detto per SSL/TLS è necessario che il protocollo di trasporto sia affidabile, quindi si può applicare solo a TCP, però ci sono tantissimi protocollo applicativi che vengono veicolati su UDP. Ovviamente non si può trasporre direttamente SSL/TLS su UDP, perché vengono a cadere tutta una serie di fattori, e allora è stato sviluppato appositamente il DTLS ovvero il Transport Layer Security orientato ai datagrammi, riconoscendo che alcuni servizi di sicurezza non possono essere offerti. Il DTLS è una versione che cerca di applicare gli stessi concetti del TLS alla sicurezza dei datagrammi, quindi per esempio UDP, ma non offre tutti i servizi di sicurezza di TLS. Il DTLS è attualmente in competizione con altre due soluzioni : se noi abbiamo un’applicazione basata su UDP abbiamo due scelte:
IPsec : uso IPsec, quindi faccio sicurezza al livello sottostante rispetto a UDP TLS : fare sicurezza applicativa (dei messaggi o dei dati securizzando il payload) DTLS : securizzare UDP stesso
Se ad esempio trattiamo SIP, abbiamo 4 scelte possibili :
1. con IPsec 2. con TLS (solo per SIP_over_TCP) 3. con DTLS (solo per SIP_over_UDP) 4. con secure SIP
notiamo che se scelgo IPsec o secure SIP sono indipendente dal livello di trasporto che è stato scelto per SIP. Detto questo, andremo ad analizzare alcuni problemi applicativi per securizzare le applicazioni e in particolare visto che oggi la maggior parte delle applicazioni sono veicolate sopra http, cominceremo proprio da questo protocollo. All’interno di HTTP‐1.0 sono già definiti dei meccanismi di sicurezza, e sono i seguenti:
“address‐based” = il server controlla l’accesso in base all’indirizzo IP del client “password‐based” (o Basic Authentication Scheme) = accesso limitato da username e password, che vengono trasmessi codificati con Base64, quindi NON SONO CIFRATI, infatti Base64 è una funzione perfettamente invertibile
Ovviamente entrambi gli schemi sono altamente insicuri , ma è da notare che nell’RFC dell’HTTP si dichiara di usare HTTP solo su canali sicuri. HTTP/1.1 migliora un po’ la situazione in quanto introduce la “digest authentication” con cui si continua ad usare la password ma la si utilizza per una sfida simmetrica, quindi la fase di autenticazione è diventata un po’ più robusta. Nell’RFC‐2617 “HTTP authentication: basic and digest access authentication”, vengono riassunti entrambi i meccanismi. HTTP ‐ basic authentication scheme
Consideriamo adesso il meccanismo di Basic Authentication. Abbiamo aperto un canale HTTP e stiamo facendo una domanda al server, quindi la GET di una pagina. Questa pagina che stiamo richiedendo è protetta, ma di fatto non c’è alcun modo per saperlo, infatti non esiste un meccanismo per dichiarare
nella URL che una pagina sia protetta. Quello che ci capita, è beccarci una errore 401, che è l’unico caso in cui anche nella versione HTTP 1.0 il server non ci chiude la connessione, in quanto lui sa benissimo che l’utente fosse ignaro che la pagina richiedesse autenticazione. Quindi, gli da il suggerimento, se veramente l’utente vuole accedere a quella pagina, di autenticarsi, e lo richiede facendo seguire all’errore HTTP anche l’header: WWW‐Authenticate: Basic realm="RealmName" dove richiede di autenticarsi in questo caso con il meccanismo Basic Authentication per il dominio “RealmName”. Non bisogna fare tra questo reame e il reame di Kerberos, infatti mentre il reame di Kerberos è costituito da tutte le macchine che si sottomettono al sistema di autenticazione di Kerberos, questo qui invece è solo un nome di fantasia, ed è quello che viene usato dal Pop‐Up per dire all’utente che deve immettere Username e Password per il reame specificato (altrimenti l’utente non capirebbe quail credenziali usare se solo non sapesse il reame nei confronti del quale è richiesta l’autenticazione). Il popup non è applicativo, e quindi non è bloccante, ed è una reazione automatic del browser non disabilitabile. Inviando le credenziali, riceviamo un altro header che dice che sta provando ad autenticarsi con quell meccanismo (Basic) seguito da username e password codificati in Base64: quindi chi fa sniffing sulla rete li può leggere e ottenerli, inoltre poichè il server dovrà autenticare l’utente dovrà conoscere username e password in chiaro, e se il calcolo fatto dal server va a buon fine, visto che il canale è ancora aperto ci manderà header e body della pagina HTTP. Ovviamente fare queste operazioni su un canale non cifrato mette a serio rischio di intercettazione di username e password, ed ecco quindi l’interesse ad usare HTTP sopra un canale SSL o TLS dirsi voglia. HTTP e SSL/TLS Abbiamo due alternative in questo caso:
“TLS then HTTP” (RFC‐2818 – HTTP over TLS) – url https : implica che io prima apro un canale sicuro e poi sopra questo veicolo il protocollo HTTP
“HTTP then TLS” (RFC‐2817 – upgrading to TLS within HTTP/1.1) : apro il canale HTTP non sicuro, ed esiste un commando dentro il protocollo HTTP per richiedere di securizzare il canale
Notiamo che “SSL then HTTP” è largamente usato, ma in realtà coincide con la prima solo che si usa SSL e non TLS, ma non è documentato. Inoltre, la prima soluzione è ad oggi quella largamente usata, ma si assiste a continue pressioni da parte di IETF e W3C al fine di usare la seconda soluzione : PER QUALE MOTIVO? A loro non piace il fatto che esistano due URL diverse, ovvero l’http e l’https. Qualcuno obbietta al fatto che http non sia sicuro, infatti se stiamo usando http su IPsec allora è sicuro, mentre altri obbiettano al fatto che https sia sicuro infatti data l’esistenza delle ciphersuite con algoritmi NUL in quel caso di sicurezza ce n’è ben poca. Quindi la tendenza è quella di avere http e poi se si vuole rendere sicuro il canale allora lo si rende sicuro. Come è chiaro, le due forme non sono assolutamente equivalenti ed hanno un grosso impatto sulle applicazioni finale, sul firewall ed in generale sull’IDS. Infatti se io ho fatto TLS then HTTP, quando un firewall si vede arrivare un traffico cifrato non può più decidere in base al protocollo applicativo se lasciarlo passare o meno, infatti può anche darsi che sulla porta TCP 443 sia stato installato un servizio diverso e il firewall lo lasci passare. Stessa cosa con l’IDS. Viceversa se io ho HTTP e poi TLS, il firewall può vedere se quello è un canale HTTP , può vedere quando viene richiesto di rendere sicuro il canale. Anche sull’applicazione c’è un notevole impatto, infatti se io faccio TLS then HTTP allora il mio server può ignorare il fatto che ci sia SSL, mentre se faccio http then TLS allora il server dovrà riconoscere il comando per richiedere di securizzare il canale e poi implementare le dovute misure di sicurezza. E’ da notare che più in generale si può estendere il discorso anche ad altri protocolli applicativi,non solo ad http, quindi sebbene l’RFC faccia riferimento ad http di fatto il discorso che stiamo facendo risulta estendibile anche ad altri protocolli applicativi.
Sicurezza del WWW Conviene usare il canale SSL, per i seguenti motivi:
protegge le transazioni protegge le password applicative
Notiamo che la password per Basic/Digest Authentication non è ancora la password che io uso dentro un form, perchè questa autenticazione è fatta prima ancora che sul browser mi arrive la pagina web. Quindi come discuteremo meglio dopo con il web io ho almeno tre livelli di autenticazione:
1. Posso mettere le password applicative (dentro i form) 2. Posso avere la password al livello di Basic Authentication 3. Posso avere autenticazione al livello SSL con la Client Authentication
Se abbiamo scelto di usare password per la Basic o la Digest Authentication abbiamo due scelte:
Creare delle password apposite del servizio http, ovvero delle password per accedere al servizio http
il server starà su un certo S.O. e l’utente dovrà pure essersi loggato sul sistema operativo, quindi si può anche richiedere la password del S.O. che ospita il server (es. NT o UNIX). Questo è molto comodo soprattutto quando abbiamo un dominio perché ho un dominio e uso la password di dominio anche per questi scopi, ma non è una bella cosa, perché se per caso viene intercettata sul canale la coppia username e password, quella non servirà solo per loggarsi col server ma conterrà delle credenziali valide per il dominio.
Quindi anche se è più comoda la seconda strada, si consiglia sempre di seguire la prima creando delle password apposite per il servizio http. Esisteranno inoltre delle ACL che determineranno in funzione dell’autenticazione che diritti si hanno sulle varie risorse , quindi sono utili per regolare l’accesso ai documenti. Client authentication SSL a livello applicativo Abbiamo detto che usando SSL è anche possibile chiedere la Client Authentication, quindi esiste la possibilità che il server chieda al client di mostrargli un certificato valido per autenticarsi nei confronti del server. Questo viene fatto al livello SSL, quindi prima ancora che venga creato il canale HTTP. In realtà qualcuno dice anche che questa cosa non ha molto senso, in quanto comunque al livello applicativo si dovranno comunque richiedere username e password per poter capire quale utente è, ma in realtà non è così : infatti SSL esporta al livello applicativo alcuni paramteri caratteristici tra cui anche i dati con cui l’utente si è autenticato. Quindi con questa soluzione c’é la possibilità di fare mapping automatici o semi‐automatici tra la credenziale estratta dal certificato e quella fornita ai livelli superiori. Il fatto che l’autenticazione sia stata fatta ad un livello più basso non preclude che questa rimanga nota al livello applicativo, inoltre è completamente trasparente per l’utente ma non gli permette di fare “giochetti strani”. Autenticazione nelle applicazioni web Quindi riassumendo abbiamo 3 scelte :
1. autenticazione al livello di canale SSL 2. autenticazione al livello di canale http (Basic/Digest Authetication) 3. autenticazione applicativa
Queste tre soluzioni non sono equivalenti. In figura sono stati forniti dettagli su quale sia il software responsabile dell’autenticazione:
canale SSL : ci sarà un’apposita libreria che permette di fare SSL canale http : è compito del software server web (Apache o IIS) applicazione : sarà l’application server o le pagine che abbiamo scritto
tipicamente queste tre cose sono organizzate a piramide, infatti SSL è una quantità di sotware piccola in quanto deve occuparsi solo di fare SSL, mentre il demone http deve fare tutto http. Infine l’applicazione sarà qualcosa di ancora più grosso. Il concetto è quindi prima si fa l’autenticazione e meno software stiamo esponendo agli attacchi, quindi “più in basso si fa il controllo e meno parti si espongono agli attacchi” . Questo si correla con un concetto che fa parte di quei tentativi di misurare quando un sistema sia sicuro o insicuro, che si chiama ATTACK SURFACE : dato un attaccante, qual è la superficie di attacco che lui ha a disposizione? Infatti più ristretta sarà la superficie, più bassa sarà la probabilità che l’attaccante trovi un attacco efficace.
Quindi se possiamo, facciamo la Client Authentication, ma anche se non possiamo farla è sempre meglio fare la Basic/Digest Authentication piuttosto che ritardare il controllo fino al livello applicativo facendo quindi l’autenticazione applicativa, perché c’è molta più probabilità di aver commesso errori nella parte applicativa piuttosto che nel demone del server web. Notiamo che le frecce in blu indicano il mapping, ovvero l’autenticazione fatta ad un certo livello può essere trasferita come minimo con delle variabili di ambiente,ma molto spesso esiste la possibilità di fare dei mapping automatici. Come introdurre username e password Vediamo di toccare con mano la situazione che si viene a creare. Supponiamo di trovarci su un sito di Internet Banking, e di dover introdurre le credenziali di accesso, ovvero username e password. A questo punto guardiamo il form di login, e vediamo che in fondo alla pagina stessa c’è un lucchetto aperto. A questo punto l’utente si incuriosisce : ma il lucchetto non dovrebbe essere chiuso per fornirmi sicurezza? La risposta che gli viene fornita è che in realtà metterlo chiuso prima o dopo è la stessa cosa. In realtà i conti non tornano, perché scegliendo questa strada username e password verranno trasmessi in modo INSICURO! Ma questa cosa è vera? No, in quanto tutto dipende da cosa viene fatto dopo che si clicca sul bottone “GO”, che corrisponderà ad una certa action e sarà la ACTION a dire se andiamo su http o https. Ma così è un casino : perché l’unico modo per sapere come veramente verranno trattate le mie credenziali di accesso al servizio è andare a guardare la URI, e se nella URI c’è https per trasmettere i dati. Quindi la sicurezza effettiva dipende dalla URI del metodo usato per inviare username e password al server :
tecnicamente, non importa la sicurezza della pagina in cui si introducono i dati ma psicologicamente è importante la sicurezza della pagina in cui si introducono i dati perché pochi utenti hanno le conoscenze tecniche necessarie a verificare la URI del metodo usato per l’invio
Quindi, seguendo la strada dell’esempio che abbiamo posto, noi stiamo disabituando gli utenti, e gli stiamo dando un cattivo esempio perchè così facendo apriamo la strada per degli shadow server. Quindi
l’utente dovrebbe essere abituato a vedersi richiedere le credenziali per autenticarsi solo su una pagina con un bel lucchetto.
S‐HTTP
Non è https, bensì una modifica del protocollo HTTP 1.0 sviluppata da EIT‐Terisa. Ogni commando ed ogni risposta (quindi request e response) vengono incapsulate in una busta sicura, che può essere di vari tipi : PEM, PGP o PKCS‐7. E’ obsoleta, e non dobbiamo lasciarci ingannare dal fatto che ci siano delle RFC che documentano questo protocollo in quanto sono delle RFC experimental che sono stati scritti a futura memoria per documentare una cosa che per un certo periodo di tempo è esistita. S‐HTTP è stata la contromossa di IBM, infatti Netscape ha avuto l’idea di SSL, Microsoft ha inventato PCT, IBM ha inventato S‐HTTP ma anche questo è naufragato.
Coesistenza di SSL con altri protocolli SSL estende ad un livello inferiore gli altri protocolli di sicurezza, e può coesistere con altri protocolli di sicurezza che possono essere collocati a livelli diversi anche. Con la stratificazione è possibile avere misure di sicurezza addizionali una sopra l’altra, nel senso che sopra TCP‐IP è possibile decidere di implementare SSL, il quale può essere usato o non usato da un protocollo che di per sé sarebbe insicuro:
Per esempio si può usare telnet sicuro con SSL o telnet normale, oppure SMTP con SSL o normale (perché la posta è già sicura se si è ad esempio adottato lo standard di posta S/MIME).
Quindi attenzione a come SSL si combina con la sicurezza applicativa:
la sicurezza applicativa sta a livello 7 e magari anche 7 e mezzo, l’SSL è più a livello 4‐5 e quindi si può combinare con la sicurezza applicativa.
SSH (Secure SHell)
Per un certo periodo di tempo una delle alternative a SSL è stato SSH. SSH è stato sviluppato da uno studente finlandese che nell’ambito di un corso di sicurezza ha sviluppato come tesina la riscrittura completa dei comandi R (rsh, rlogin, rcp) per renderlo sicuro. Lui ha sviluppato una soluzione che poi fu fondamentalmente utile anche in ambiti diversi da quello per cui fu sviluppato. Che cosa ci fornisce SSH? Vediamo:
crittografia del canale
utilizza DES, triplo DES, RC4, IDEA oppure ISS (algoritmo specifico finlandese) la chiave di cifratura è una chiave di sessione scambiata in fase di connessione
vari tipi di autenticazione:
indirizzi IP (= rlogin + crypto) : questo vuol dire avere lo stesso tipo di autenticazione di rlogin con in più la parte di protezione dei dati trasmessi
chiave RSA di host : sfida asimmetrica con chiave assegnata a ciascun host della rete, quindi ciò che viene identificato è l’host, ma non l’utente
chiave RSA di utente : è possibile assegnare chiavi RSA anche ai singoli utenti e quindi fare anche una sorta di client authentication
Per quanto riguarda le implementazioni, è public‐domain per UNIX, mentre è commerciale per Windows anche se è in corso di sviluppo anche un’implementazione public domain per Windows. Infine, il protocollo in corso di pubblicazione come RFC.
SSH – certificazione Abbiamo detto che SSH usa ampiamente le chiavi RSA, il maggior problema è che SSH usa nella sessione base chiavi RSA ma non usa certificati di alcun tipo! Usare le chiavi pubbliche senza certificati induce problemi per la sostituzione delle chiavi pubbliche : ovvero se qualcuno riesce a sostituirmi la chiave pubblica io non ho alcun modo di accorgermi di questa sostituzione in quanto la chiave pubblica non è certificata in alcun modo. La certificazione o la garanzia delle chiavi è affidata interamente al File System, quindi si assume che il file system sia adeguatamente protetto da intrusioni. In particolare :
la chiave pubblica, non essendo associata ad un certificato di una CA, deve essere nota alla controparte per poter essere verificata:
i client tengono la chiave pubblica dei server in: ~/.ssh/known_hosts
i server tengono le chiavi pubbliche dei client in:
~/.ssh/authorized_keys Il server manda la propria chiave pubblica, e a quell punto se era un server sconosciuto SSH avverte che è stata ricevuta una nuova chiave, nel qual caso ci chiede se la vogliamo memorizzare. Però già solo averla ricevuta così pone molti dubbi. Viceversa i server tengono le chiavi pubbliche dei client nel file authorized_keys, quindi la sicurezza di queste chiavi pubbliche è affidata interamente alla sicurezza del File System e al fatto che nessuno possa manipolare queste cartelle e questi file.
SSH ‐ protezione delle chiavi private La chiave privata del server è conservata in chiaro in un file, e come sappiamo la cosa è estremamente pericolosa. Anche in questo caso ci si affida pienamente alla protezione del file System lato server. Si suggerisce anche di tenere nascosto questo file (quindi un po’ di security through obscurity), e bisogna anche ricordarsi di cancellare il file di configurazione che dice qual è il file in questione. La chiave privata del client è conservata crittografata con un passphrase P. La passphrase viene richiesta all’utente quando occorre, ed esiste un programmino (infatti SSH è costituito da una miriade di programmini) che si chiama ssh‐agent e che è una sorta di proxy, al quale noi comunichiamo la password che rimuove la protezione della chiave privata, e ci penserà lui a dialogare con tutti gli altri programmi della suite SSH trasmettendola quando necessario.
SSH ‐ autenticazione dei client Per l’autenticazione dei client abbiamo detto che uno dei meccanismi è quello dell’autenticazione basata sull’indirizzo IP, quindi il server va a controllare quali sono gli IP autorizzati. Nello standard dei comandi “r”, questi definiscono degli host che sono equivalenti, ovvero se si fa il login su una certa macchina allora è possibile collegarsi a tutte le altre senza dover più fare login. Questo è definito al livello di sistema globale se questi host vengono elencati nel file /etc/hosts.equiv, oppure al livello individuale (di singolo utente) se nella nostra home abbiamo messo questi altri calcolatori nel file denominato ~/.rhosts. Come già ditto è anche possible fare autenticazione standard + RSA challenge:
il client deve rispondere ad una sfida crittografica di tipo asimmetrico (verificabile dal server perché conosce le chiavi pubbliche dei client)
il server verifica comunque ~/.rhosts e /etc/hosts.equiv SSH ‐ autenticazione dei client Per autenticare i client ho diverse possibilità:
uso di login+password Unix all’interno di un canale crittografato challenge RSA puro, ossia senza controllo dell’indirizzo IP
SSH ‐ autenticazione dei server Viene fatta solo ed esclusivamente mediante challenge RSA.
K‐commands In quei sistemi in cui è implementato Kerberos può essere interessante utilizzare i cosiddetti k‐commands, ossia tutte quelle applicazioni che sono state modificate per utilizzare Kerberos. Questi comandi sono:
K‐telnet, K‐ftp, Klogin, Kcp, Ksh, K‐POP
Notiamo che Kerberos serve in due sensi:
1. serve innanzitutto nella fase di autenticazione in cui Kerberos è in grado di fornire mutua autenticazione del client e del server
2. visto che tra client e server Kerberos stabilisce un segreto condiviso, questo segreto condiviso può essere usato per la cifratura simmetrica e il keyed‐digest, e quindi per proteggere successivamente l’applicazione
La parte di crittografia del canale con DES è opzionale. Non dobbiamo farci fuorviare nei k‐commands dal fatto che si usi Kerberos e che questo sia usato solo per autenticazione, in quanto come visto può anche essere utilizzato per scambio chiavi. Di solito non si mette in piedi Kerberos per utilizzare questi comandi, al più si va nel viceversa, ovvero se ho già Kerberos allora posso prendere in considerazione l’idea di usare questi comandi.
SSL‐telnet, SSL‐ftp, SSL‐rsh Allo stesso modo, se abbiamo usato servizi come telnet, ftp ed rsh con SSL allora possiamo ripiegare sull’uso di SSL‐telnet, SSL‐ftp, SSL‐rsh. Si tratta di applicazioni standard modificate con trasporto SSL, e si appoggia sulla libreria OpenSSL. Ovviamente usa certificati X.509. E permette anche la modalità di funzionamento fall‐back, ovvero se l’autenticazione SSL fallisce si può:
rifiutare la connessione ricadere all’indietro (fall back) , e collegarsi col protocollo standard
SSL‐x: autenticazione
In tutti questi programmi tipicamente l’autenticazione consiste nel:
il server è sempre autenticato:
chiave privata in chiaro in un file chiave privata conservata in un file cifrato con l’uso di una passphrase, che sarà richiesta all’avvio per aprire il file che contiene la chiave privata
per default, il client è autenticato tramite login+password Unix ma su un canale crittografato
opzionalmente si può usare la client authentication di SSL; in questo caso la passphrase che protegge la chiave privata è richiesta all’utente
Uno dei più comuni modi di usare SSH (di tunnellizzare un’applicazione), è per la protezione di X‐Windows, quindi adesso spendiamo due paroline su X‐Windows.
Il sistema X‐windows (X11)
X‐Windows è il sistema grafico del mondo Unix e possiamo vederlo come una applicazione, con i suoi requisiti di sicurezza (e sono dei forti requisiti di sicurezza). Notiamo innanzitutto l’inversione di terminologia, infatti:
client : sono i nodi di rete che svolgono l’elaborazione, perché il sistema X‐Windows è un sistema Client/Server che serve a fornire il servizio di Input e Output grafico a dei programmi che stanno svolgendo elaborazione. Quindi i client sono dei programmi che stanno svolgendo elaborazione e che hanno bisogno di dialogare con degli utenti in rete
Quindi la nostra macchina è un X‐server, perché offre i servizi di video, tastiera e mouse ad un’applicazione che gira da qualche parte in rete
Si tratta di sistemi eterogenei, come messo in luce dal fatto che sull’X‐Server abbiamo due finestre corrispondenti a due sistemi diversi tra loro. La sicurezza intrinseca di X‐Windows è molto bassa. Al livello di autenticazione tipicamente si basa sugli indirizzi IP. Vediamo tutti i meccanismi possibili di autenticazione:
indirizzi IP ( xhost +host ) cookie : a partire da X11R4 è possibile usare i cookie, che sono un segreto condiviso con i quali è possibile poter fare una sfida di tipo simmetrico
Kerberos V5 : a partire da X11R6 Notiamo che queste sono opzioni, ovvero, come già detto il default è l’indirizzo IP, ma avere autenticazione debole significa che con le primitive di X11 (es. xwindump) posso catturare tutto l’I/O del
terminale grafico (sia parte grafica che parte testuale) senza bisogno di fare sniffing! Per questo motivo ad oggi si tende a non usare più X‐windows senza i dovuti meccanismi di protezione al livello inferiore, ma lo si appoggia a IPsec o come minimo su SSH (la cui caratteristica è quella di creare un tunnel su cui veicolare protocolli di livello superiore). Protezione della chiave private
Il problema della protezione della chiave private l’abbiamo già citato prima, ma adesso lo riesaminiamo in questo contesto. Tipicamente il problema della protezione della chiave private è grosso quando deve essere usata automaticamente da un qualche processo come ad esempio capita nel caso dei server. Il modo più facile è quello di lasciarla in chiaro dentro un file : è molto facile ma richiede la protezione complete del server. La seconda possibilità è lasciare questa chiave in un file criptato con una poassword, vuol dire che nel momento in cui si f ail boot del server deve essere presente una persona per l’immissione da console una passphrase che permetta di decifrare questo file e di mettere la versione decifrata non su disco, bensì in RAM. La cosa è un pochettino meglio, ma se qualcuno riesce ad avere i privilegi di sistema può esaminare tutta la memoria RAM (non solo quella del suo processo) e quindi andarsi a leggere la chiave. In particolare ci sono dei piccolo programmi che analizzano tutto il contenuto della RAM e beccano a colpo sicuro dove sono le chiavi. La cosa può sembrare strana in quanto in RAM non c’è un’indicazione esplicita di dove si trovino le chiavi. In realtà le chavi sono random, mentre tutto il resto che si trova in RAM ha una sua regolarità, quindi semplicemente analizzando la distribuzione casual e facendo un raffronto si può andare a reperire in RAM la chiave. La soluzione migliore è che le chiavi non vengano date ma vengano memorizzate su un dspositivo sicuro e poi sarà lui ad occuparsi di fare le dovute operazioni crittografiche (ovvero il concetto di SMART‐CARD che abbiamo già visto).
Sicurezza degli accessi remoti a DBMS
Dipende fortemente da come noi andiamo a sviluppare la nostra applicazione. Quindi:
Se usiamo ancora il vecchio stile, ovvero collegarci in emulazione di terminale, cosa che chi sviluppa un sistema modern non usa più ma che in realtà è ancora presente in tantissimi sistemi per eredità dei vecchi sistemi, allora faremo emulazione di terminale su canale protetto (quindi SSL‐telnet, SSH, e così via)
Se accediamo al DB tramite interfaccia WWW, anche qui la soluzione è abbastanza semplice in quanto dovremo applicare la protezione del Web (SSL), più sarà un nostro pensiero vedere come il server web si college al database
Il vero problema degli accessi a database è in modalità client‐server. Ossia quando al client è permesso fare direttamente via rete delle query al server, come ad esempio si fa sfuttando JDBC o ODBC. Qui la soluzione non è banale infatti JDBC o ODBC sono API, non sono un protocollo di rete, perchè non esiste l’SQL via rete. Non esistendo un protocollo via rete, non esiste nemmeno un metodo standard per renderlo sicuro. Ecco quindi che in questa situazione ci sono due approcci:
Approccio Microsoft : facciamo sicurezza ad un livello inferiore, quindi si usa IPsec su qualunque canale verso un database. In questo modo qualunque cosa ci passi sopra sarà sicuro
Chi controlla l’applicazione, dirà di usare le estensioni che rendano sicuro il dialogo client‐server indipendentemente dalla rete su cui il dialogo sta avvenendo
Entrambe le cose hanno una loro validità. Nell’approccio di Microsoft si vede l’ottica di chi ha il controllo forte e sistemistico dell’intera struttura, che quindi vuole potersene fregare di quello che fanno le applicazioni in quanto Microsoft ha l’Active Directory con cui lui stabilisce le policy, e tutti i nodi della rete andranno su IPsec . Invece nell’approccio dello sviluppatore applicativo che è responsabile solo dell’applicazione, ma non sella configurazione sistemistica, risente tantissimo di quell’ottica, e quindi tende ad una sicurezza auto‐consistente all’interno dell’applicazione. Entrambe le strade hanno dei pro e dei contro. Sulla parte IPsec in questo momento non ci soffermiamo, consideriamo invece ina delle soluzioni proposte da Oracle per rendere sicuri i propri dialoghi. Questa è ovviamente una soluzione custom.
Oracle SNS
Oracle offre un servizio che si chiama SNS, che è un add‐on per la sua parte di rete. E’ da notare infatti che ogni fornitore di database ha anche un suo sistema per veicolare l’SQL di rete, quindi Oracle ha il suo sistema SQL*NET e sopra questo ci può anche metter sopra SNS. Permette di autenticare client e server e protegge i dati (query, update, risposte) da intercettazione (data encryption), modifiche (data integrity) , cancellazione (data filtering). L’SNS come soluzione di sicurezza risulta applicabile a:
DB Oracle centralizzato/distribuito DB federato con parti non Oracle : ricordiamo che un DB federato è un DB distribuito tra nodi di diversi produttori
Alcuni vantaggi insiti nell’uso di SNS sono:
non richiede modifiche alle applicazioni esistenti non richiede dispositivi hardware
Quindi è un po’ il concetto di SSL applicato al mondo dei database.
SNS ‐ schema funzionale
Noi abbiamo la nostra applicazione che già usa SQL*NET, e quello che facciamo è introdurre tra lo strato SQL*NET e la rete lo strato SNS. Notiamo che questa parte SNS ha due interfacce:
da un lato verso SQL*NET, quindi la libreria applicativa dall’altra parte verso Oracle NPA, network protocol adapter, l’altro strato di libreria di Oracle per permettere di fare query su qualunque tipo di rete
Nel passaggio da sopra a sotto i dati diventano da non protetti a protetti. Ovviamente in ricezione ci sarà il duale. Se vogliamo applicarlo anche elementi non Oracle il vincolo è che bisogna avere SQL*NET: quindi io posso anche avere un PC Windows con Foxpro o Access, ma devo avere la libreria SQL*NET e
anche SNS. Analogamente potrei anche avere un mainframe IBM con sistema operativo MVS e un certo database, in questo caso dovrò avere un modulo aggiuntivo chiamato “Oracle Open Gateway” per permettere al database con formato diverso da quello standard Oracle di parlare con SNS, quindi anche qui sono richiesti SNS e SQL*NET, quindi questo è quello che serve per le parti federate.
SNS ‐ supporto cross‐protocollo
SNS non è specifico per un protocollo di rete. Visto che SNS si appoggia su NPA, analogamente può essere usato su qualunque tipo di rete. NPA supporta quasi 50 tipi di rete diversi. Grazie a questa proprietà, SNS funziona anche cross‐protocollo. Notiamo i due tipi di rete che sono diversi. Nel qual caso SNS creerà un canale logico sicuro, ma di fatto poiché in termini di pacchetti di rete ci saranno due formati diversi, ci dovrà pur essere in mezzo tra queste due reti un modulo che faccia le dovute conversioni tra i due formati di rete diversi. Questo modulo lo si indica in figura con il nome di Oracle Multiprotocol Interchange. SNS è integrato in Oracle MultiProtocol Interchange, che fa da gateway. SNS lavora quindi al livello di payload applicativo ed è per questo che è indipendente dal livello rete sottostante. Oracle MultiProtocol Interchange permette di avere un cambio di protocollo senza rimettere i dati in chiaro, il che si traduce in velocità e soprattutto inattaccabilità.
Crittografia in SNS Per la parte di crittografia, viene negoziato l’algoritmo all’apertura della connessione tra client e server:
ce n’è uno di default nel caso in cui il default sia diverso tra client e server, allora si ricorre alla negoziazione possibile rifiuto della connessione,nel caso in cui il livello di sicurezza non sia ritenuto sufficiente
Si può richiedere l’attivazione automatica della sicurezza ma bisogna fare attenzione in quanto il campo dei database è il campo in cui si presta attenzione alle prestazioni fino al centesimo di secondo, quindi avere tutta la parte di sicurezza produce un calo di prestazioni. Ecco perché l’attivazione automatica della sicurezza:
per default può essere disattivata attivazione automatica e trasparente quando ci si collega ad un server che la richiede
Vantaggi di SNS Già a partire da Oracle 7 non venivano mica trasmessi in chiaro username e password ma si usava un sistema a sfida, però c’è un problema. Infatti molti server lasciano in chiaro i cambiamenti di password,perché il server deve conoscere la password in chiaro, e in ogni caso viene lasciato in chiaro la trasmissione dei dati quindi abbiamo bisogno di un qualche meccanismo per proteggere le trasmissioni. SNS crittografa tutta la sessione e quindi elimina questi problemi
SNS ‐ identificazione ed autenticazione degli utenti Per quanto riguarda l’ identificazione e l’autenticazione degli utenti, SNS è neutrale e supporta tantissimi sistemi di autenticazione tramite accordi esclusivi , questa è una delle potenze quando uno è veramente leader di mercato, perché io accetto il tuo sistema ma tu non puoi darlo a nessun altro venditore di database. Ecco le soluzioni:
Banyan ‐ Universal StreetTalk login singolo di rete
Bull ‐ Integrated System Management SESAME identificazione basata su token
CyberSAFE – Challenger Kerberos V5 (V4, DCE) applicativi kerberizzati GSS‐API
ICL – AccessManager login singolo di rete A: RACF, ACF2, TopSecret, DCE, Kerberos I: SDI SecurID, PCSL StopLockV, RACF Passticket
Identix – TouchSafeII verifica delle impronte digitali interfaccia ISA
Security Dynamics Technologies – SecurID autenticatore hardware PIN + numero casuale (cambia ogni minuto)
SNS ‐ integrità dei dati
Per garantire integrità (e quindi anche autenticazione) dei dati, SNS usa MD5 come checksum (basata anche sulla chiave), checksum che normalmente non è inserita ed è inseribile a richiesta. SNS opzionalmente:
numera i pacchetti controlla che non ne manchino e non ci siano duplicati arresta il sistema in caso di attacco
Per la protezione del canale invece si utilizzano algoritmi standard.
Sistemi di pagamento elettronico
Si intende quindi il modo in cui noi possiamo sviluppare delle applicazioni che permettano di pagare merce che noi abbiamo acquistato su Internet. Inizialmente era stato proposto un tentativo di creazione della moneta elettronica, tentativo fatto da DigiCash e che si è tradotto in un fallimento forzato per problemi tecnici e normativi , perché c’erano molte paure sul fatto che con la moneta elettronica fosse più semplice fare riciclaggio di denaro sporco. Quindi nonostante il sistema dal punto di vista tecnico fosse valido, è stato distrutto. Attualmente il metodo più usato è trasmissione del numero di carta di credito su canale SSL, che però non garantisce contro le frodi: VISA Europa dichiara che il 50% dei tentativi di frode nascono da transazioni Internet, che però sono solo il 2% del suo volume d’affari! Questo non perché Internet è il posto in cui si rubano le carte di credito, ma perché Internet è il posto dove più facilmente posso utilizzare le carte di credito che ho rubato, perché se vado in un negozio devo
avere con me la carta di credito,ma se io ho sbirciato i numeri allora posso usarli più facilmente su Internet.
Sicurezza delle transazioni basate su carta di credito
Inizialmente c’erano due standard in competizione tra loro:
STT (Secure Transaction Technology) VISA + Microsoft
SEPP (Secure Electronic Payment Protocol) Mastercard, IBM, Netscape, GTE, CyberCash
SET = STT + SEPP (Secure Electronic Transaction) Poi era stato creato uno standard comune chiamato SET. Lo standard SET è un bellissimo caso di studio per far vedere come non si realizza una soluzione di sicurezza. E’ un protocollo che è morto e sepolto. La sua sperimentazione fu fatta per la prima volta alle Olimpiadi di Atlanta e da allora non ha più avuto alcuna applicazione pratica. Non si tratta di problem tecnici, quanto più di problem organizzativi. SET (Secure Electronic Transaction)
SET non è un sistema di pagamento ma un insieme di protocolli per usare in rete aperta in modo sicuro un’infrastruttura esistente basata su carte di credito. SET usava certificati X.509v3 dedicati esclusivamente alle transazioni SET, quindi avevano dei key usage per indicare che quel certificato poteva essere usato specificatamente con SET. Era stato pensato bene dal punto di vista tecnico, perché assicurava la privacy degli utenti perché mostra a ciascuna parte solo i dati che le competono, senza permettere a chi intercettava i dati di leggere né i dati del certificato né i dati della carta di credito. Caratteristiche di SET
versione 1.0 (maggio 1997) digest: SHA‐1 crittografia simmetrica: DES scambio chiavi: RSA firma digitale: RSA con SHA‐1 www.setco.org : fino all’anno scorso esisteva questo sito, adesso non esiste più
Architettura di SET
Dal punto di vista architetturale, SET era fatto nel seguente modo. Innanzitutto, quando noi ci rechiamo in un negozio e vogliamo pagare con carta di credito ,esiste già la rete che verrà usata per effettuare il pagamento e mettersi quindi in contatto con chi ha emesso la carta. I vari fornitori (Visa, Mastercard..) si chiamano Issuer. Però tipicamente non si chiede direttamente all’issuer, bensì all’acquirer (es. la banca), ovvero colui che procaccia clienti per conto dell’Issuer, e l’acquirer sarà il mediatore tra il negoziante e
gli issuer, perché il negoziante ospita o direttamente nelle linee telefoniche o nell’architettura di SET IL payment gateway, ovvero il punto di scalo tra la rete non protetta e la rete protetta per pagare. Il merchant deve essere dotato del software SET, e dall’altra parte c’è invece un card holder ovvero colui che possiede una carta di credito e vuole effettuare il pagamento.
Attori in SET
cardholder legittimo possessore di una carta di credito aderente a SET, e deve quindi possedere il SET wallet (borsellino SET). Questo è un software particolare che deve essere installato sulla macchina da cui il card holder sta effettuando il pagamento
merchant venditore di un prodotto via Internet (Web o email), sul suo sito web ci deve essere il software SET
issuer istituto finanziario che ha emesso la carta di credito dell’utente
acquirer organizzazione finanziaria che stabilisce un rapporto col mercante e lo interfaccia con uno o più circuiti di pagamento. Devono generare certificati X.509 per il merchant,per il card holder, e per il payment gateway, quindi deve esistere tutta l’insfrastruttura di certificazione che distribuisce i certificati a questi attori
payment gateway sistema che traduce transazioni SET nel formato richiesto dal circuito di pagamento dell’acquirer
certification authority emette certificati X.509v3 e CRL X.509v2 per tutti gli altri attori di SET
Doppia firma SET
Il punto che protegge la privacy è la cosiddetta doppia firma. In questo modo, quando io faccio un acquisto al merchant non vengono fatti sapere gli estremi del pagamento, quindi il negoziante non verrà mai a sapere qual è il mio numero di carta di credito (quindi la situazione è completamente diversa rispetto ai pagamenti fatti con SSL). Alla banca non viene mai fatto sapere quale merce si è acquistata. Ecco quindi come si implementa questo concetto di doppia firma :
al merchant non vengono fatti sapere gli estremi del pagamento alla banca non viene fatto sapere quale merce si è acquistata solo l’utente può dimostrare l’associazione tra merce e pagamento in caso di contestazione
Ma come si realizza l’ultimo punto? Come può l’utente dimostrare l’associazione tra merce e pagamento?
Doppia firma SET: dettagli
Indichiamo con PI (Purchase Information) i dati di pagamento, e con OI (Order Information) le informazioni relative alla merce che sto acquistando. La firma digitale SET è fatta nel seguente modo:
io calcolo l’hash dei dati di pagamento, e l’hash dei dati relativi alla merce che sto acquistando
queste due cose le concateno e ne calcolo ancora l’hash, e di questo hash ne faccio la cifratura con la mia chiave privata
o DS = E ( H( H(PI),H(OI) ), Ukpri)
A
Al merchan(DS+H(PI)), oH(H(PI),H(OI
t comunico ovvero PI (il m)) verificand
la firma dmerchant noo che corrisp
igitale appeon ha i dati dponda al valo
ena calcolatdi pagamentoore estratto
a e l’hash o PI, ma condalla firma)
dei dati di osce l’OI e p
pagamentouò calcolare
o e
A
f
Allo stesso m(DS+H(OI)), ma conosce firma)
modo, all’acqovvero OI (l’PI e può cal
quirer comu’acquirer nocolare H(H(P
nico la firmaon conosce i PI),H(OI)) ver
a digitale e l’dati riguardrificando che
’hash delle ido la merce e corrisponda
nformazioni che sto acqa al valore e
sulla merceuistando OI,stratto dalla
e , a
Soltantodati vendimostra
Problem
A questoInnanzitimmotivelettronfrenato mAltro protutti quaPoi l’altrcompatibackup dEcco qul’utente ambito aCon la sfacendo messi suproblem2.0 non
o chi ha fattongono manteare l’associaz
mi di SET
o punto vediutto il softvatamente mico, si chiedemolto la partoblema è chanti i loro cliero incubo erbilità sia al del SET walleindi la granddeve installaaziendale poeconda versa meno delu un wallet ma… chi contrha mai visto
o questa firmenuti all’intezione tra me
ma, può far verno del SETerce e pagam
vedere che iT wallet, quimento, come
i dati PI e Ondi sul nostgià detto.
I collimano etro PC: noi s
e vanno insisaremo gli u
eme. Questiunici a poter
i r
amo di capirre perché SETT è fallito. tware necemolto caro: evano cifre atenza di que
essario erasiccome ne
assurde per esto sistema.
molto carel 1996‐97 iniziare a lav
ro, ma la c’era la fidvorare con i
cosa più pducia nel bl commercio
particolare usiness del o elettronico
è che eracommercio : questo ha
a o a
he le bancheenti, e le ban
e dovevano fnche non ave
fungere da Cevano nessun
CA, perché dna intenzion
dovevano me di fare que
ra nel SET wlivello di S.Oet per evitarede lezione care un softwsso ancora ssione (2.0) h SET wallet eserver, e l’rolla il walletla luce ed è
wallet, un soO. che degli e di perderlache stiamo iware specificosperare nell’oanno cercate rimpiazzan’utente si cot server? Risstato definit
oftware da inapplicativi tra traccia di tuimparando: o diventa unomogeneità o di risolverndolo con unollegava colposta: nessutivamente so
nstallare a cra loro. Inoltutti gli acquisqualunque sn incubo se ndi configurae questi pron browser. O browser : uno voleva aoppiantato.
casa del clietre chi insegsti fatti. soluzione dinon è in ambzione delle poblemi e renOssia i walletma a questssumersi qu
ettersi loro esto lavoro.
a certificaree
nte: è un ingnava all’ute
ncubo per laente a fare il
a l
sicurezza cbito aziendalpostazioni di
che dica chee! Perché inlavoro.
e n
dere SET piùt venivano vto punto c’eesto onere,
ù appetibile,irtualizzati eera un altroe quindi SET
, e o T
Architettura di pagamento via Web
Abbiamo detto che l’alternativa è il pagamento via web. Vediamo ora uno schema di cosa avviene all’interno di un’architettura di pagamento via web:
Il cliente ha selezionato la merce, e l’ha messa in uno shopping chart (carrello virtuale) e a questo punto fa il check‐out. Facendo il check‐out il merchant ci invia un’offerta (1) che è il riassunto della merce che vogliamo acquistare, alla quale il cliente (cardholder) risponde con un ordine (2)
In teoria se il merchant è un tipo che fa le cose per bene, non dovrebbe chiedermi lui i dati della carta di credito, ma dovrebbe reindirizzarmi verso un payment gateway con cui lui ha fatto un accordo. Il payment gateway attiverà un canale SSL verso di me per chiedermi i dati della carta di credito (4 e 5), garantendoci rispetto ad eventuali buchi di sicurezza del mercante
Il payment gateway attiverà su di sé un software noto come POS virtuale che a partire dai dati della carta di credito mi ricrea tutti quei dati che effettivamente verrebbero prodotti se solo si strisciasse la carta di credito in un vero e proprio POS. Inoltre il POS virtuale dialogherà con la rete di pagamento usando i protocolli propri del mondo finanziario, non è detto che sia TCP/IP, ottenendo un OK (6 e 7)
Solo se tutto va a buon fine invierà un feedback al merchant per indicare la buona riuscita del pagamento (8) e il mercante può spedire l’oggetto.
Notiamo che questa soluzione si presta ad una serie di problemi: innanzitutto non mi garantisce la privacy, perché il payment gateway tipicamente fa un brutto lavoro di tenere traccia di quali sono le mie preferenze di acquisto (e rivende questi dati a terzi). La seconda cosa è che nel momento in cui faccio l’acquisto ci sono dei merchant che chiedono loro la carta di credito, la memorizzano localmente e poi provvedono a trasmetterla via FAX o altro. Quindi c’è un grosso problema di come viene gestito il dato della carta di credito. Quindi di per sé l’architettura va bene, il vero problema è come sono gestiti i dati della carta di credito.
Pagamento con carta di credito via Web
Quindi in caso di pagamento con carta di credito via web, le ipotesi base sono:
l’acquirente possiede una carta di credito l’acquirente ha un browser con SSL
in base a quanto abbiamo detto oggi, la sicurezza effettiva dipende dalla configurazione sia del server sia del client perché in SSL c’è una negoziazione, quindi il lucchetto scatta anche quando abbiamo negoziato la cifratura a zero bit quindi c’è un problema di educazione degli utenti. Non deve bastare la sola visione del lucchetto, ma bisogna vedere innanzitutto chi ha autenticato il server, e poi qual è il livello effettivo di cifratura in termini di bit. Inoltre, l’utente non gode di privacy.
Requisiti di sicurezza per SI di e‐commerce
Questo problema del fatto che sempre più spesso oggi viene attaccato non il canale SSL, ma il payment gateway, nel caso che questo conservi in modo insicuro i dati delle carte di credito, ha fatto sì che Visa per prima e poi tutti gli altri grossi produttori di carte di credito abbiano attivato dei programmi di certificazione per tutti coloro che vogliono attivare dei payment gateway. Quindi Visa non permette di attivare un payment gateway se non dopo il conseguimento di una certificazione. Ogni issuer però faceva la sua certificazione, quindi stava per diventare un casino:
Visa: (2000) Account Information Security (AIS) program for EU and the Cardholder Information Security Program (CISP) for USA
(2001) programs mandatory for all members, merchants and service providers other security programs:
MasterCard requires Site Data Protection (SDP) American Express requires DSOP Discover requires DISC …
ecco perché alla fine si sono accordati ed esiste uno standard molto importante che si chiama PCI‐DSS (Payment Card Industry – Data Security Standard). Oggi è richiesto da tutte le carte di credito per tutte le transazioni in Internet, quindi chiunque voglia mettere in piedi un payment gateway deve avere questa certificazione altrimenti non potrà collegarsi alla rete finanziaria.
PCI DSS
Rispetto ad altri standard che esistono in giro e che dicono come implementare la sicurezza nel SI, questo standard è molto più prescrittivo, ovvero indica proprio quali sono le soluzioni da adottare.
Requisiti PCI DSS
Al fine di far capire cosa si intenda per “standard prescrittivo”, vediamo quali sono le regole
costruire e mantenere una rete protetta: o R1 = installare e mantenere una configurazione con firewall per proteggere i dati dei
titolari delle carte (non ci limita sul produttore, ma ci dice che ci deve essere!) o R2 = non usare password di sistema predefinite o altri parametri di sicurezza impostati
dai fornitori (in passato con Oracle erano state mantenute all’atto dell’installazione le password di default…alla fine tutti si facevano le copie dei database)
proteggere i dati dei titolari delle carte: o R3 = proteggere i dati dei titolari delle carte memorizzati (quindi se li manteniamo noi,
dobbiamo garantire che il File System sia sicuro o che i sistemi che mantengono quei dati non siano manipolabili)
o R4 = cifrare i dati dei titolari delle carte quando trasmessi attraverso reti pubbliche aperte (incluse qualunque rete wireless, qualunque cosa vada su onde radio!)
rispettare un programma per la gestione delle vulnerabilità o R5 = usare e aggiornare con regolarità l’antivirus o R6 = sviluppare e mantenere applicazioni e sistemi protetti
implementare misure forti per il controllo accessi
o R7 = limitare l’accesso ai dati dei titolari delle carte solo se effettivamente indispensabili per lo svolgimento dell’attività commerciale (principio del need to know: un operatore dovrebbe avere accesso alla minima quantità di dati necessaria per lo svolgimento delle sue mansioni. Purtroppo per semplicità sempre più spesso a seguito dell’autenticazione si da accesso al database direttamente.)
o R8 = dare un ID univoco ad ogni utente del SI (quindi NO AGLI ACCOUNT DI GRUPPO, ognuno deve essere responsabile delle proprie azioni)
o R9 = limitare la possibilità di accesso fisico ai dati dei titolari delle carte monitorare e testare le reti con regolarità
o R10 = monitorare e tenere traccia di tutti gli accessi effettuati alle risorse della rete e ai dati dei titolari delle carte (vogliono un elenco di chi sta facendo cosa sulla rete)
o R11 = eseguire test periodici dei processi e dei sistemi di protezione adottare una Politica di Sicurezza
o R12 = adottare una Politica di Sicurezza (documentata, perché questa è anche una cosa che vedranno all’atto della verifica per ottenere la certificazione)
Questi punti vanno rispettati tutti e 12, non in parte!