Virtual Private Networks Per Security Context Aware System

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTÀ DI INGEGNERIA DIPARTIMENTO DI ELETTRONICA E TELECOMUNICAZIONI ___________________________________

CORSO DI LAUREA IN INGEGNERIA DELLE TELECOMUNICAZIONI Elaborato per il corso di Sistemi Telematici A.A 2007/2008

Virtual Private Networks per Security Context Aware System

14 / 07 / 2008

Candidato Lapo Cioni [email protected]

Tutor Matteo Bandinelli [email protected]

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

-2-

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

Indice generale 1

Introduzione al Security Context Aware System ........................................4

2

VPN: Virtual Private Networks ........................................................................7 2.1 Cos'è una VPN ...................................................................................................7 2.2 Classificazione delle VPN ...............................................................................8 2.2.1 IPSec ..........................................................................................................11 2.2.2 PPTP ..........................................................................................................11 2.2.3 L2TP ...........................................................................................................12 2.2.4 SSL/TLS .....................................................................................................12 2.3 Mobile VPN ......................................................................................................14 2.4 Confronto critico: SSL vs. IPSec .................................................................15 2.5 Tipologie di VPN SSL ....................................................................................17 2.6 La gestione dell'autenticazione....................................................................18

3

SSL: Secure Socket Layer .................................................................................21 3.1 Caratteristiche principali di SSL ................................................................21 3.2 La sicurezza in SSL .........................................................................................22 3.3 Le sessioni SSL ................................................................................................24 3.4 I parametri di interesse in SSL ....................................................................28

4

VPN SSL ...................................................................................................................29 4.1 I servizi delle VPN SSL ..................................................................................29 4.2 Gestione della VPN e definizione delle caratteristiche .........................31 4.2.1 Private Network e User remoto ..............................................................31 4.2.2 Soluzioni VPN SSL ...................................................................................32 4.2.3 L'utilizzo delle risorse................................................................................34 4.2.4 Compatibilità: alcuni esempi....................................................................38

5

Conclusioni..............................................................................................................41 Bibliografia..............................................................................................................43 -3-

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

1.  Introduzione al Security Context Aware  

System Lo scenario dei servizi telematici interattivi è sempre più complesso: aumenta il numero di devices di interazione e di contesti d'uso delle applicazioni; è quindi necessario lo sviluppo di sistemi consapevoli delle informazioni che si stanno trattando, dell'interazione che sta accadendo e del contesto in generale. Per "contesto" si intende qualsiasi informazione che possa essere usata per caratterizzare la situazione di un'entità, ovvero qualsiasi informazione possa essere rilevante per caratterizzare l'interazione fra l'utente e l'applicazione. Quindi un Sistema è 'Context Aware' se esso fa uso del contesto per fornire informazioni rilevanti e servizi utili all'utente, dove il grado di rilevanza e utilità dipende dalle richieste dell'utente e dalle informazioni che esso ha fornito al sistema. La Context Awareness viene differenziata in: - Context Awareness Attiva: dove un'applicazione si adatta automaticamente ai cambiamenti del contesto; - Context Awareness Passiva: dove l'applicazione presenta all'utente la possibilità di scegliere se effettuare un cambiamento di comportamento in funzione di una avvenuta mutazione del contesto. Un sistema Context Aware deve: - raccogliere informazioni relative al contesto - elaborarle - produrre un risultato in maniera autonoma (active) o dopo una scelta dell'utente (passive) I tipi di contesto possono essere: - Fisico (spazio,tempo, posizione geografica) - Ambientale (clima, illuminazione...) - Informativo (listino azionario, notizie del giorno...)

-4-

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

- Personale (profilo dell'utente, salute, umore...) - Sociale (relazione, co-presenza...) - Applicativo (e-mail, siti Web visitati...) - di Sistema (stato delle periferiche, stato delle connessioni, elenco hw e sw in uso e quelli disponibili...) - etc... Fra le informazioni del contesto più rilevanti, per la trattazione che faremo, ci saranno sicuramente: l'identità, le informazioni spaziali e temporali, le risorse accessibili e la conoscenza della tipologia di rete. Un concetto che è inscindibilmente associato alla Context Awareness è l'Ubiquitous Computing, cioè la possibilità di accedere ad un servizio e fruire di una risorsa indipendentemente dal posto in cui ci troviamo; inoltre un requisito che ancora chiediamo a questo scenario è l'indipendenza dalla piattaforma hw e sw di utilizzo; abbiamo quindi definito uno scenario di Ambient Intelligence (AmI). Appare chiaro come in un contesto di questo tipo il lato della sicurezza sia particolarmente delicato: rischia di immobilizzare il paradigma che abbiamo visto, se viene forzatamente applicato sul sistema senza un opportuno adeguamento, oppure, di contro, può aprire falle pericolose se lasciato troppo blando. Abbiamo bisogno di strumenti intelligenti, cioè strumenti che: - abbiano al loro interno capacità computazionali (Embedded), - riconoscano l'utente e il contesto in cui si trovano (Context-Aware), - si adattino all'identità e alle scelte dell'utente (Personalizzati), - attuino azioni al mutarsi del contesto in funzione delle prevedibili esigenze dell'utente (Proattivi). Nell'intento di definire un'architettura di questo tipo, cioè di tipo user-friendly, context aware, persistente e sicura, dobbiamo sicuramente considerare un altro requisito fondamentale delle connessioni che andiamo a trattare: l'aspetto di comunicazione Seamless, ovvero una comunicazione nella quale gli aspetti non rilevanti per l'utente siano ad esso trasparenti; in quest'ottica, ad esempio, se ci troveremo ad utilizzare apparati mobili avremo l'intenzione di -5-

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

offrire un servizio di handoff seamless (sia esso orizzontale, ad esempio fra celle diverse, oppure verticale, ad esempio fra devices diversi), che dovrà quindi essere trasparente all'utente, di tipo Soft (cioè senza perdita di connessione) e Lossless (senza perdita di pacchetti). Di questo aspetto ci interessa particolarmente la palese necessità di integrazione nel sistema di apparati di diversa natura; al momento di una modifica del contesto si potrebbe avere la necessità di effettuare un adattamento sulla struttura hw/sw che stiamo utilizzando ad un livello qualsiasi della struttura: chiamiamo questo requisito di sitema Handoff CrossLayer. Nel passaggio, quindi, da un device ad un altro o da un applicativo ad un altro o ancora da un protocollo di trasporto ad un altro, ci troveremo ad avere a che fare con caratteristiche strutturali diverse ed è proprio qui che dovremo cercare la soluzione migliore del nostro problema a livello di sicurezza. Poichè l'architettura Context Aware fa uso delle informazioni sopra elencate per definire il contesto e agire di conseguenza, essa possiede un elevato numero di dati sensibili, il nostro obiettivo è quindi quello di applicare un certo grado di sicurezza al paradigma della Context Awareness, sostenendo la caratteristica di facilità di switching degli elementi architetturali, in modo da mantenere efficiente il modello. In particolare ci occuperemo di valutare quali possano essere le migliori soluzioni per l'instaurazione di connessioni sicure utilizzando la tecnica delle Virtual Private Network, volendo determinare, fra le possibili implementazioni, quelle che ci permettano un utilizzo più adeguato in ambito di sistemi Context Aware.

-6-

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

2.  VPN: Virtual Private Networks 2.1 Cos'è una VPN Con VPN si intende un concetto di rete esteso: con l'utilizzo di soluzioni tecnologiche eterogenee si intende rendere un'associazione di nodi di rete, che possono far parte di reti diverse, come virtualmente appartenenti alla stessa rete logica. I requisiti fondamentali affinchè un'associazione di nodi sia una Virtual Private Network sono quindi: - ogni nodo deve vedere l'altro come se questo appartenesse alla sua stessa rete; - la comunicazione deve essere privata, cioè sicura. Una VPN può portare molti benefici in una comunicazione in rete, fra i quali: - estendere la connettività geografica - aumentare la sicurezza - ridurre i tempi di trasmissione e i costi di trasporto per gli utenti remoti - aumentare la produttività - semplificare la topologia di rete - permettere un accesso sicuro ad aree riservate di una LAN da remoto. Una VPN può essere utilizzata per estendere una rete privata a due o più reti private remote (LAN-to-LAN o Site-to-Site), tramite il passaggio attraverso internet e i rispettivi Gateway delle reti (concentratori di traffico o firewall); può inoltre anche essere utilizzata per collegare un singolo host ad un server VPN (Host-to-LAN o Remote Access), utilizzando un client vpn che verrà configurato con le credenziali di accesso sull'ip pubblico del Gateway vpn, sul Gateway verranno poi definite le policy di sicurezza per filtrare il traffico, cosicchè questo host remoto risulti virtualmente sulla rete locale, componendo un Circuito Virtuale che risulterà equivalente ad una connessione fisica dedicata; infine una terza tipologia di utilizzo di VPN è definita Host-to-Host, dove i due endpoints del tunnel sono appunto singoli host. Il passaggio attraverso internet è trasparente ai terminali, che interagiscono come se fossero collegati tramite una linea diretta. Una VPN può avere performance di tipo Best Effort, oppure il servizio può essere definito da una SLA (Service Level Agreement) stipulata fra l'utilizzatore e l'ISP. -7-

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

Per garantire che solo gli utenti autorizzati accedano alla Rete Privata Virtuale, le VPN utilizzano sistemi di autenticazione, mentre per garantire la sicurezza utilizzano metodi di crittografia. Esistono vari organismi indipendenti, largamente riconosciuti, che certificano interoperabilità e sicurezza dei sistemi informatici, come ad esempio ICSA Labs. Un apparato o un software, che riporti il marchio di ICSA Labs per le VPN IPSec, ha sicuramente superato una serie di test oggettivi e replicabili, che garantiscono la compatibilità con tutte le altre implementazioni certificate ed un adeguato livello di sicurezza. Una VPN porta con sè come dote implicita l'ubiquità in termini di utilizzo: gli host connessi potranno infatti agire come se fossero all'interno di una rete locale, anche se effettivamente potrebbero trovarsi su reti distinte; nel nostro studio, allora, gli utenti che utilizzeranno il sistema saranno supposti dei Road Warriors, cioè utenti mobili. Quello che chiediamo alle VPN operanti in sistemi Context Aware è sicurezza e al tempo stesso interoperabilità e semplicità. Il metodo con il quale implementare una VPN non è univoco, ma dipende dalle scelte che si vogliono fare: esistono vari protocolli che lavorano a livelli diversi e che compongono suite di sviluppo; la scelta della strada migliore da percorrere deve essere fatta anche in base a questa considerazione.

2.2 Classificazione delle VPN Le connessioni VPN si distinguono in 3 grandi gruppi: - Trusted VPN (gestite da un provider) - Secure VPN (gestite dal customer) - Hybrid VPN Una classificazione dettagliata delle Reti Private Virtuali può essere ricavata dal seguente schema:

-8-

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

Immagine 1: Classificazione VPN.

Le Trusted VPN offrono la garanzia che il circuto utilizzato dal cliente non sia accessibile a terzi, garanzia che viene offerta dagli ISP. La loro caratteristica è che non utilizzano un tunnel crittografico, perchè la sicurezza della comunicazione è basata sull'esclusività del circuito di comunicazione, ovvero l'ISP riserva dei canali logici dedicati. La rete privata, in questo caso, non può essere propriamente definita virtuale, le trusted VPN vengono infatti anche dette APN (Actual Private Network) o Tunnel-Based VPN. Si distinguono in: Layer 2 Trusted VPN: - circuiti ATM - circuiti Frame Relay - trasporto del layer 2 sopra l’MPLS Layer 3 Trusted VPN: - MPLS con distribuzione limitata delle informazioni del percorso attraverso il BGP(Border Gateway Protocol).

-9-

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

Le Secure VPN utilizzano invece dei metodi crittografici che permettono di creare un tunnel virtuale isolato dal resto del traffico IP in rete: vengono anche dette Encrypted VPN. I metodi di sicurezza utilizzati intendono offrire i servizi di: confidenzialità, autenticazione, integrità del messaggio e privacy. I protocolli e le suite che implementano le secure VPN sono molti, fra i più importanti ci sono: - IPSec (IP Security) - SSL/TLS - L2TP/v3 (Layer 2 Tunneling Protocol /version 3) - PPTP (Point-to-Point Tunneling Protocol) - OpenSwan (derivato dall'obsoleto FreeSwan) - Altre soluzioni poco utilizzate o obsolete, come: Cipe, Tinc, Vtun, Vpnd... Il terzo macrotipo di VPN è composto dalle Hybrid VPN: si tratta di reti create in parte con Trusted VPN e in parte con Secure VPN. Questo tipo ti reti compongono i pregi e i difetti delle Secure e delle Trusted VPN, infatti: •

Le Secure VPN danno sicurezza, ma non assicurano i percorsi.

•

Le Trusted VPN assicurano le proprietà dei percorsi come QoS, ma non la sicurezza da intrusioni.

Le prospettive che propongono le Hybrid VPN sono molto interessanti, tuttavia la loro implementazione richiede di risolvere una complessità realizzativa piuttosto elevata. Il gran numero di standard e raccomandazioni usati per implementare le reti virtuali private sono codificati dall' IETF (Internet Engineering Task Force). La soluzione delle Trusted VPN è estremamente statica ed è diventata obsoleta, se non per le aziende o le compagnie che abbiano la necessità di ottenere un persorso dedicato per i loro dati; non è questa comunque una soluzione che possa essere adottata in uno scenario dinamico e interattivo come quello che abbiamo descritto, con gli utenti che spesso sono, come detto, dei Road Warriors. - 10 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

Concentriamo il nostro interesse sulle Secure VPN o Customer Provisioned VPN: questo è lo scenario nel quale dovremo infatti muoverci, ovvero un sistema in cui il tunnel possa essere instaurato in maniera dinamica, senza avere vincoli di routing predefiniti in modo che l'accesso alla rete sia semplice e multifunzionale, inoltre ci possiamo limitare a considerare la gestione di VPN di tipo Remote Access, sempre per le considerazioni sul sistema di utilizzo che abbiamo fatto; affinchè una VPN possa essere definita Secure deve garantire: - un sistema di autenticazione - i dati devono viaggiare criptati - il livello di cripting dei dati deve essere elevato e modificabile nel tempo. Analiziamo schematicamente le caratteristiche dei protocolli più utilizzati nelle Secure VPN:

2.2.1 IPSec - IPSec (IP Security): protocollo di livello Rete, standard IETF, parte integrante di IPv6, estensione per IPv4; per l'autenticazione utilizza il protocollo ESP (Encapsulating Security Payload) o l'AH (Authentication Header), fornisce anche il servizio di crittografia dei dati e utilizza IKE (Internet Key Exchange) per lo scambio delle chiavi. E' lo standard più diffuso, generalmente non semplice da configurare ma supportato da molti vendor e sistemi operativi. Su sistemi Linux una delle implementazioni di IPSec si chiama OpenSwan.

2.2.2 PPTP - PPTP (Point-to-Point Tunneling Protocol): è un protocollo di livello DataLink sviluppato dal PPTP Forum, formato da Microsoft, 3COM, US Robotics e altre importanti compagnie, assicura autenticazione, crittazione e compressione dei dati. PPTP lavora instaurando delle sessioni PPP (Point-to-Point Protocol, del quale è un adattamento) con l'ausilio del protocollo GRE (Generic Routing Encapsulation). Nei sistemi Unix si sono sviluppate soluzioni parallele, come il server PPTP chiamato PoPTop. Generalmente PPTP è considerato più insicuro di IPSec, ma più facile da configurare. - 11 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

2.2.3 L2TP - L2TP (Layer 2 Tunneling Protocol): protocollo di livello Sessione, che agisce come uno di livello DataLink, si basa sul L2F (Layer 2 Frowarding) di Cisco e sul PPTP. Il pacchetto L2TP viene incapsulato in un pacchetto UDP (si utilizza la porta 1701), ma questa struttura non comprende meccanismi di sicurezza; allora viene spesso utilizzato in aggiunta al L2Tp l'IPSec, per introdurre confidenzialità, autenticazione e integrità dei dati, formando così la suite L2TP/IPSec. I due endpoints del tunnel L2TP sono detti AC (Access Concentrator) e NS (Network Server). Una delle caratteristiche che rendono piuttosto adattabile questo protocollo è l'assenza di metodi di sicurezza integrati, cosicchè sia possibile aggiungerli sopra di esso (come IPSec) mantenendo un certo grado di indipendenza dalla piattaforma utilizzata. La versione 3 di questo protocollo è stata proposta nel 2005 e ha introdotto nuove caratteristiche di sicurezza metodi di incapsulamento e datalink supportati.

2.2.4  SSL -SSL/TLS (Secure Sockets Layer/Transport Layer Security): SSL è un protocollo progettato da Netscape Communications Corporation ed è stato utilizzato anche come base di sviluppo per il TLS, che è standard IETF (RFC 2246); lavora sotto al livello applicativo e sopra al livello trasporto, composto da due strati, per interfacciarsi ad esempio con HTTP verso l'alto (formando HTTPS) e con un protocollo di trasporto affidabile come TCP verso il basso. Forse è questa la tecnologia più adatta per l'utilizzo delle VPN che stiamo ipotizzando: riconsiderando infatti i tre tipi di utilizzo per una rete privata virtuale visti in precendenza, possiamo pensare che (sempre in ambito di Secure VPN) un'implementazione con IPSec o FreeSwan sia più adatta, o comunque generalmente più diffusa, per collegamenti di tipo LANto-LAN o Host-to-Host, mentre l'utilizzo di SSL può risultare maggiormente efficiente e meno complesso nella configurazione di una VPN di tipo Host-to-LAN (detto anche Host-toSite), che è appunto quella che vogliamo trattare con maggiore attenzione, trattando direttamente la situazione di utente in mobilità e permettendo la semplicità di handoff che abbiamo descritto. Con SSL è possibile instaurare una VPN Host-to-Site utilizzando un normale browser web che lo supporti; l'instaurazione di VPN IPSec richiede invece - 12 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

l'installazione di particolari client software. Configurare una VPN SSL è sicuramente più facile e veloce rispetto ad una VPN IPSec: lato client richiede solo l'utilizzo di una applicazione che integri SSL (può appunto essere un browser web) e il supporto di Java; questa sembra la soluzione più adatta per un sistema scalabile e distribuito come quello in esame. Nel fare queste considerazioni abbiamo ipotizzato che fossero fondamentali i seguenti criteri di valutazione: - Disponibilità della soluzione: facilità nel reperire e distribuire il 'pacchetto soluzione', di integrarlo nelle piattaforme hw/sw - Sicurezza: livello offerto di confidenzialità, autenticazione, sicurezza, nell'ipotesi di trattare reti insicure come internet - QoS: possibilità di priorizzare il traffico in base al tipo - Scalabilità: possibilità di adattare la larghezza di banda offerta al livello di connettività richiesto/necessario - Facilità di gestione nell'implementare la soluzione in maniera distribuita, permettendo di accedere a siti e contenuti informativi diversi. La soluzione più comunemente utilizzata per VPN di tipo Remote Access è stata IPSec VPN; in una rete così composta, le SSL VPN sono state dapprima utilizzate in configurazione SSL over IPSec, ma questa è stata una fase transitoria, per andare incontro sia alle esigenze dei vendor, che hanno avuto bisogno di tempo per poter sviluppare soluzioni all-SSL adeguate, sia alle esigenze dei clienti, molti dei quali stavano già utilizzando VPN IPSec.

- 13 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

2.3 MobileVPN

Uno scenario che può essere utile analizzare è quello delle Mobile VPN (MVPN): si tratta di un particolare scenario di accesso remoto sicuro in cui il dispositivo deve essere in grado di cambiare il proprio indirizzo IP senza perdere la connettività con la propria rete aziendale. Quello che stiamo considerando è lo sviluppo di sistemi che permettano, ad esempio, di accedere alla rete aziendale mediante una connessione Wi-Fi, disponibile presso un albergo o in aeroporto e, senza mai disconnettersi, mantenere l'accesso attraverso la rete UMTS o la rete GPRS (per esempio viaggiando in taxi). Lo scenario MVPN comprende sia le problematiche connesse alla sicurezza dell'accesso remoto attraverso Internet sia quelle della mobilità. I requisiti che impone sono molteplici: si va dalla gestione dinamica dell'autenticazione dei due interlocutori (l'utente che richiede l'accesso e il gateway della rete aziendale) all'instaurazione di un canale sicuro, dalla configurazione di policy di sicurezza alla gestione automatica ed efficiente della mobilità. Le Mobile VPN permettono all'utente di spostarsi senza perdite (seamlessy) fra reti IP-based senza perdere le sessioni applicative o di sicurezza. L'analisi di alcune soluzioni studiate per un contesto MVPN può quindi essere utile per estendere alcuni concetti anche al sistema della Context Awareness, dove mobilità e sicurezza sono senz'altro fra i protagonisti. Utilizzando IPsec per la connessione sicura, un cambiamento dell'indirizzo IP dell'utente remoto, causato da un suo spostamento, provoca un 'disallineamento' tra le security association (nelle due direzioni della comunicazione) presenti tra l'host remoto e il gateway, impedendo la corretta comunicazione tra i due. Un primo modo per permettere la mobilità dell'utente è rinegoziare il tunnel IPSec ad ogni cambiamento di indirizzo IP: sarà sufficiente avviare un nuovo handshake IKE ogni volta che il terminale si sposta da una rete all'altra; un problema che ne deriva è il considerevole Overhead Computazionale derivante dalle ripetute operazioni crittografiche, particolarmente problematico nel caso di utilizzo di dispositivi che non abbiano un'elevata capacità di calcolo come PDA o Smartphone. Altra soluzione basata su IPSec è quella di scindere la gestione della sicurezza dalla gestione della mobilità: una soluzione in questo senso può essere l'utilizzo di IPSec+MobileIP; questa tecnica porta però alla costruzione di un doppio tunnel e quindi ad un Overhead che stavolta è sui pacchetti dati, oltre ad un livello di protezione non molto elevato. Altre soluzioni proposte sono di utilizzare - 14 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

la versione 2 del protocollo IKE, che lascia comunque il problema della mobilità, oppure integrare la gestione della mobilità dentro IKE. Alle questioni finora descritte va aggiunta un'ulteriore limitazione per l'IPSec: sul dispositivo dell'utente che vuole instaurare il tunnel deve essere installato e configurato un client VPN. I motivi, invece, per cui le soluzioni VPN basate su SSL sono più adatte alle esigenze dell MVPN sono molteplici e fra i principali ci sono: - indipendenza dalla piattaforma - client VPN non necessario - gestione delle connessioni in mobilità più semplice, grazie al fatto che SSL è un protocollo di alto livello (liv. Sessione della pila OSI) - semplicità di installazione del tunnel - servizio personalizzabile - minori problemi dovuti alla traduzione del NAT

2.4 Confronto critico: SSL vs. IPSec

Un ulteriore elemento che rende le SSL VPN particolarmente adatte all'utilizzo che ne dobbiamo fare nel nostro contesto di lavoro è il fatto che la rete privata virtuale basata su SSL è in grado di riconoscere il contesto in cui l'utente si trova a tentare l'accesso alla rete, ad esempio se l'utente sta cercando di accedere dall'interno della LAN stessa o dall'esterno; in base a questo possono essere applicate policy di sicurezza distinte: l'accesso può essere concesso, limitato o negato, le autorizzazioni possono essere fatte ad personam e possono riguardare applicazioni specifiche, URL o semplici file. Il livello di sicurezza offerto da SSL può sembrare più scarso di IPSec se ci si basa solo su identificativo e password, ma viene incrementato notevolmente se si affiancano meccanismi di 'Strong Authentication', quali: certificati, smart card o token card. Come inciso, dobbiamo dire che talvolta le aziende possono essere interessate ad ottenere un tipo di connettività data dalla composizione di VPN IPSec e SSL, in modo da suddividere topologicamente la propria rete di comunicazione e distinguere in maniera forte l'accesso, ad esempio LAN-to-LAN rispetto a quello Remoto - 15 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

(Host-to-LAN); ma una trattazione di questo specifico problema esula dagli obiettivi che ci siamo posti. Le convinzioni che finora ci siamo fatti devono però fare i conti con varie realtà: ad oggi esistono comunque molte soluzioni di Mobile VPN montate su IPSec o Free/OpenSwan: - TheGreenBow VPN Mobile (http://www.thegreenbow.com/mobile.html) - Nokia VPN Mobile (http://www.business.nokia.it/A4293201) - Symantec Mobile VPN (http://www.symantec.com/it/it/business/products/overview.jsp? pcid=2241&pvid=mobile_vpn_1) - ... Inoltre OpenSwan offre nativamente ("out of the box") un'estensione molto interessante: la Opportunistic Encryption (OE): permette a due macchine (verosimilmente Host e GW VPN, per l'analisi della configurazione Remote Access) di instaurare una comunicazione cifrata (IPSec) senza che si siano scambiati alcuna informazione precedente; OE sfrutta due strumenti principali: - le chiavi di crittazione asimmetriche (o pubbliche) - un'estensione del DNS, detta DNS Security Extension (DNSSEC). Con OE è possibile andare a prendere la chiave pubblica del destinatario dal server DNSSEC, instaurando così una SA (Security Association) fra gli interlocutori. In OpenSwan OE è settata nella configurazione base e deve essere esplicitamente disabilitata se non si vuole utilizzare i DNS come database delle chiavi pubbliche. Per utilizzare OE devono essere opportunamente configurati i record DNS: il record KEY viene utilizzato per inserire nel DNSSEC le chiavi pubbliche, nel record TXT si indica invece il proprio Security Gateway. La Opportunistic Encryption è particolarmente utile quando le due macchine agli estremi del tunnel non si conoscono e permette loro di instaurare ugualmente un tunnel sicuro. Nonostante la OE sia una soluzione interessante da utilizzare anche in situazioni di utenti in mobilità, restano consistenti i vantaggi che si possono ottenere dall'utilizzo di VPN SSL in ambito Context Aware System, primi fra i quali ci sono sempre l'assenza della necessità di un client, la facilità di installazione, i minori costi implementativi, la miglior integrazione con firewall e NAT, soprattutto in caso di configurazioni di reti dinamiche, in cui le regole di filtering variano spesso. Come detto, uno dei punti di forza delle VPN SSL è che non è necessario installare e - 16 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

configurare un software su ogni endpoint: SSL utilizza un browser web standard e instaura una connessione a livello applicativo, anzichè a livello rete come succede con IPSec. L'utilizzo di SSL è ideale per gli utenti mobili perchè: •

non necessita di essere scaricato sul device che viene usato per accedere alle risorse

•

non necessita di essere configurato dall'utente finale

•

è disponibile ovunque ci sia un web browser standard ed è indipendente dal Sistema Operativo.

Poichè SSL opera a livello applicativo, è possibile offrire controlli di accesso alle applicazioni granulari, rendendo questa tecnologia una buona soluzione anche per gli utenti che accedono da reti non sicure; la flessibilità di SSL permette di accedere da ovunque e di modificare i metodi di accesso e le risorse accedibili agli utenti quando il contesto cambia. A livello di sicurezza, inoltre, IPSec e SSL sono molto simili: entrambi supportano metodi per la crittazione, il controllo d'integrità e l'autenticazione (3-DES, RC4, AES, MD5 o SHA-1).

2.5

Tipologie di VPN SSL

La nostra scelta per l'implementazione di VPN in ambito Security Context Aware System cade quindi decisamente sulle VPN SSL, avendo anche ipotizzato che la maggior parte del traffico di rete nel contesto generale analizzato si adatti meglio al paradigma Client-Server e sia quindi adattabile al modello Remote Access, anzichè a quello Site-to-Site, che è indicativo di connessioni di tipo Peer-to-Peer; fra le VPN SSL esistono varie tipologie, che andiamo a descrivere: le VPN SSL si dividono in tre gruppi fondamentali: - WebVPN (o clientless VPN): l'utente ha bisogno solamente di un browser web abilitato SSL per accedere ai server http o https della LAN, il client è remoto; con queste VPN si può anche accedere ai file Windows con CIFS (Common Internet File System); - Thin Client SSL VPN (Port Forwarding): l'utente deve scaricare una Java applet per l'accesso sicuro ad applicazioni TCP-based che utilizzano porte statiche, mentre UDP non è - 17 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

supportato. Esempi sono l'accesso con POP3 (Post Office Protocol), IMAP (Internet Message Access Protocol), SMTP (Simple Mail Transfer Protocol), SSH (Secure Shell) e Telnet. L'utente ha bisogno del supporto della piattaforma Java (una JRE) e dei privilegi di amministratore in locale, poichè l'applet deve essere installata sulla macchina locale; - SSL VPN Client (SVC Tunnel mode): si scarica un client sulla workstation, che permette un accesso completo e sicuro alle risorse della rete privata remota. Le considerazioni fatte finora, ricordando anche le prerogative fondamentali di un sistema Context Aware (Mobilità, Interoperabilità, QoS, Adattabilità, Sicurezza...), ci portano ad escludere come soluzione ottima l'adozione di VPN di tipo SVC, così come abbiamo fatto per le VPN IPSec; quindi prenderemo in considerazione in maniera più approfondita sistemi che utilizzino VPN clientless e thin-client.

2.6 La Gestione dell'autenticazione Uno degli elementi fondamentali nella definizione di un sistema di sicurezza è l'autenticazione, vediamo quindi quali sono i più comuni sistemi per l'autenticazione usati nelle implementazioni di VPN: indichiamo quattro elementi fondamentali: AD (Active Directory), LDAP (Lightweight Directory Access Protocol) e la sua implementazione open source OpenLDAP, Radius (Remote Authentication Dial In User Service) e la sua implementazione open source FreeRadius, Kerberos. Il problema dell'autenticazione consta in sostanza nell'associare ad una identità verificata una serie di permessi, che riguardano specifiche applicazioni e risorse; inoltre ogni utente sarà associato a determinate impostazioni di configurazione, che gli permetteranno di accedere alle applicazioni e alle risorse in modo funzionale alla propria identità. Per fare questo è necessario un sistema di autenticazione e quello che ci auspichiamo è che questo sistema sia distribuito, ma anche sincronizzato, ottemperando alla politica di autenticazione detta Single-Sign-On (SSO): autenticarsi una sola volta per accedere a tutte le risorse e applicazioni disponibili per quella specifica identità. Una gestione delle identità di questo tipo richiede l'utilizzo di strumenti detti Directory Service, che possono essere server AD: questi sono database di oggetti strutturati gerarchicamente, suddivisi in tre principali categorie: Risorse, Servizi e Utenti. Su ogni oggetto vengono settati - 18 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

i controlli di accesso e le politiche di sicurezza e questo oggetto viene identificato dal suo nome di dominio (UNC, URL o LDAP-URL) e gestito tramite il DNS dell'AD. Il processo di autenticazione in un AD è gestito dal protocollo Kerberos (tramite specifiche librerie, come GSS-API, Kerberos riesce anche a gestire lo scambio di credenziali tra applicazioni, di fondamentale importanza per la politica SSO), che si basa sulla crittografia simmetrica; mentre la gestione e la modifica degli oggetti è generalmente demandata al protocollo applicativo LDAP. Radius, infine, è un protocollo di livello rete che si occupa anch'esso di gestire l'accesso centralizzato alla rete: al server Radius vengono inoltrate le richieste di accesso che gli utenti fanno al NAS (Network Access Server), ovvero il punto di accesso della rete; queste vengono processate utilizzando schemi di autenticazione quali il PAP e l'EAP, infine il server Radius elabora ed inoltra una risposta che manderà al NAS, nella quale specifica se la richiesta di connessione può essere accettata. Al server Radius vengono inoltrate le informazioni necessarie per l'autenticazione, quali username e password o certificati, ma possono essere trasmesse anche informazioni aggiuntive come l'indirizzo IP dal quale l'utente sta tentando l'accesso; possiamo pensare di estendere questa serie di informazioni aggiuntive, trasmettendo ad esempio la propria locazione geografica attuale, informazioni che identificano il dispositivo di accesso come il sistema operativo utilizzato (utili per definire politiche di sicurezza più o meno stringenti specifiche per la sessione) e lo stato dell'utente sulla macchina (amministratore o semplice utente, queste informazioni potrebbero essere utili anche per definire il tipo di VPN). Per decidere se la richiesta di accesso possa essere accettata, il server Radius deve consultare una serie di informazioni quali lo stato e il tipo di account dell'utente sulla rete locale e i suoi permessi di accesso spefifici per le risorse di rete; per fare questo il Radius si appoggia generalmente all'AD, sfruttando quindi il lavoro di LDAP e Kerberos. Dopo questa breve descrizione, facciamo alcune osservazioni più generali: un sistema di comunicazione sicuro ha bisogno di almeno tre elementi fondamentali: Crittazione, Integrità dei messaggi e Autenticazione dell'utente. Nelle nostre valutazioni riguardo le necessità che ha un sistema Context Aware, abbiamo scelto di implementare le VPN con il protocollo SSL, selezionando in tal modo il pacchetto per la sicurezza e l'integrità dei messaggi che SSL comporta. Per il processo di autenticazione dell'utente sarà invece necessario utilizzare una struttura aggiuntiva: la serie di informazioni aggiuntive di cui abbiamo accennato può essere processata da un sistema distribuito come appena descritto per la gestione dell'identità, dando - 19 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

la possibilità di sfruttare al meglio le potenzialità dell'accesso granulare permesso da SSL e permettendo di definire delle policy di sicurezza per sessione oltre che per utente. Riteniamo che questa tecnica di strutture distribuite per la gestione degli accessi sia una buona soluzione, ma non è l'unica per una VPN SSL; altri metodi di gestione degli accessi sono infatti: - un sistema proprietario di gestione del database degli utenti e dei permessi gestito direttamente dal Gateway VPN (Built-In User Database): sistema potenzialmente poco sicuro e poco scalabile; - un server NIS (detto anche Yellow Pages) per la gestione del database: soluzione poco usata e specifica per l'ambiente Unix; - autenticazione basata su token e su smart-card: si crea la dipendenza da un device fisico. Va inoltre aggiunto che i sistemi Unix si integrano nativamente ("out of the box") con le Active Directory (tecnologia sviluppata da Microsoft, quindi perfettamente compatibile con i suoi OS), supportando sia Kerberos che OpenLDAP e rendendo questa soluzione ancora più vantaggiosa. Dopo questo breve inciso sulla gestione dell'Identità, riteniamo che il supporto di Directory Services sia un requisito fondamentale nel contesto di un sistema sicuro come quello trattato; il nostro sistema di sicurezza dovrebbe supportare strumenti di autenticazione quali AD, LDAP, Kerberos, RADIUS, Certificati SSL, autenticazione a Chiave Pubblica, autenticazione tramite username-password e PIN, autenticazioni volatili tramite SMS (onetime-password) per l'utilizzo con smartphones e PDA.

- 20 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

3.  SSL: Secure Sockets Layer  Dopo aver proposto una classificazione delle più comuni soluzioni VPN ed aver confrontato i metodi a nostro avviso più adatti al problema da affrontare, la scelta è caduta sulle VPN SSL; intendiamo adesso, quindi, approfondire le conoscenze sul protocollo SSL e, successivamente, analizzare in dettaglio le due tecniche VPN che abbiamo indicato come soluzione: WebVPN e Thin-Client VPN.

3.1 Caratteristiche principali di SSL

Come abbiamo visto anche in precedenza, SSL è un protocollo progettato dalla Netscape Communications Corporation; si tratta di un protocollo modulare crittografico interlivello (lavora fra il livello trasporto e il livello sessione) di cui è stata rilasciata la versione 3 nel 1996 e da questa è derivato il suo successore: il TLS (Transport Layer Security, standard IETF (Internet Engineering Task Force), RFC2246/4346), essenzialmente molto simile all'SSL. I principali obiettivi di SSL sono: l'Autenticazione di client e server (tramite crittografia a chiave pubblica, ad esempio), assicurare l'Integrità dei Dati (utilizza strumenti quali HMAC), assicurare la Privacy. La gestione di sicurezza e integrità dei dati è compiti del sottolivello SSL Record Protocol, mentre i sottolivelli superiori (detti protocolli ausiliari) sono designati a stabilire la connessione SSL.

Immagine 2: SSL, sottolivelli. - 21 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

SSL è appunto un protocollo stratificato, ad ogni livello i messaggi possono includere campi per la lunghezza, la descrizione e il contenuto; SSL prende i messaggi che devono essere trasmessi, frammenta i dati in blocchi, opzionalmente può comprimerli, applica un MAC (Message Authentication Code), li critta e trasmette il risultato. I dati ricevuti vengono decrittati, verificati, decompressi e riassemblati, quindi consegnati al livello superiore della pila protocollare. Gli obiettivi ai quali SSL va incontro sono: - autenticazione del server: un browser SSL-enabled mantiene un elenco di CA (Certification Authorities), insieme alle loro rispettive chiavi pubbliche; quando un client, attraverso il suo browser, vuole instaurare una connessione sicura con un server SSL, il browser ottiene un certificato dal server, contenente la sua chiave pubblica; il certificato è rilasciato e firmato digitalmente da una CA che compare nella lista delle Trusted CA del browser. - autenticazione del client: funziona in maniera complementare all'autenticazione del server, ma è opzionale. - crittazione della sessione SSL.

 3.2 La sicurezza in SSL

Le operazioni crittografiche sono raggruppabili in: firma digitale (Digital Signing), crittazione a stream (Stream Cipher Encryption), crittazione a blocchi (Block Cipher Encryption), crittazione a chiave pubblica (Public Key Encryption). •

Nella Firma Digitale viengono utilizzate funzioni non invertibili (di Hashing) e algoritmi di crittazione: si crea un checksum di lunghezza fissa dividendo il messaggio in blocchi, i due Hash Values, o Digest Messages (un SHA da 20 bytes e un MD5 da 16 bytes) vengono crittati con una chiave privata (RSA) in una struttura a 36 bit. In alternativa si può utilizzare il DSS (Digital Signing Standard): il Digest Message SHA dal 20 bytes viene direttamente crittato con DSA (Digital Signing Algorithm).

•

Nella crittazione a stream i dati in chiaro vengono processati in xor simbolo per simbolo con uno stream (Keystream) generato da un PRNG (Pseudo Random Number - 22 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

Generator) e detto Keystream Generator, funzione di una chiave iniziale, detta Seed. •

Nella crittazione a blocchi viene crittato un blocco alla volta (di lunghezza fissa); il Seed è qui detto IV (Initialization Vector) ed i blocchi possono essere strutturati in vario modo (concatenati, in razione..).

•

Nella crittazione a chiave pubblica (detta tecnica a chiave asimmetrica) si utilizzano funzioni trapdoors: il messaggio viene crittato con la chiave pubblica e risulta difficile decrittarlo se non si conosce la chiave privata corrispondente. Si rendono 'disponibili' le proprie chiavi pubbliche e queste possono essere utilizzate anche per assolvere al compito dell'identificazione

Le firme digitali vengono utilizzate per l'autenticazione, le tecniche di crittazione per la segretezza e le chiavi pubbliche per l'identificazione. Dato il duplice utilizzo delle chiavi asimmetriche (crittazione e autenticazione), la distribuzione delle chiavi pubbliche risulta essere un anello particolarmente importante della catena di sicurezza: la distribuzione deve essere pubblica e consultabile da tutti gli utenti/utilizzatori che desideriamo, ma la pubblicazione deve anche essere controllata, poichè dalla chiave dipende la nostra autenticità e si deve fare particolare attenzione nell'evitare che questa venga manomessa. Esistono vari metodi di distribuzione delle chiavi pubbliche comunemente utilizzati: - Distribuzione pubblica: ad esempio in broadcast allegando le chiavi PGP (GPG è l'implementazione open source, utilizza il tool OpenPGP) alle e-mail; - Tramite Libreria Pubblica: gli utenti che hanno il permesso dispongono di un account (username e password) per la consultazione; - Tramite Libreria gestita da una Authority (si deve conoscere la chiave pubblica della Authority); - Tramite Certificati di Chiavi Pubbliche: si introduce la doppia crittazione: il mittente critta il messaggio con la propria chiave privata e la chiave pubblica del destinatario, inoltre invia il proprio Certificato di identità, che può essere verificato dal ricevente sempolicemente riferendosi alla Certification Autority. Con questo metodo è possibile unire i due meccanismi di crittazione e autenticazione. Dopo una negoziazione sui parametri da utilizzare si instaura una Sessione SSL (che può - 23 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

essere composta da più connessioni sicure), in cui gli stati degli host (endpoint del tunnel) devono essere coordinati; il controllo degli stati è demandato al sottolivello SSL Handshake Protocol: si occupa di verificare che i due terminali abbiano 'stati paralleli'. Facciamo quindi una distinzione fra Connessione (collegamento logico fra i due nodi di rete client e server) e Sessione (l'associazione fra un client e un server che definisce un set di parametri di sicurezza). Lo stato della sessione include i seguenti parametri: •

Identificatore della sessione (Session ID): un numero casuale definito dal server;

•

Peer Certificate: generalmente certificato X.509;

•

Metodo di Compressione (utilizzata prima della crittazione);

•

Cipher Spec: specifica l'algoritmo di crittazione (es. DES, RC4..), l'algoritmo MAC (come MD5 o SHA) e alcuni attributi crittografici, come la dimensione dell' Hash;

•

Master Secret: 48 bytes segreti, condivisi dal client e dal server;

•

Is Resumable: è un flag che indica se la sessione può essere usata per iniziare nuove connessioni.

3.3 Le Sessioni SSL

Senza entrare in dettagli tecnici che in questo contesto d'analisi sarebbero superflui, vediamo le caratteristiche principali dei sottostrati dell'SSL e i passi fondamentali di una connessione SSL: il protocollo comincia con una fase di Handshake, dove si accorda su di un algoritmo di cifratura e sulle chiavi, quindi autentica il server al client e, opzionalmente, viceversa. Completato l'handshake, inizia la trasmissione di dati crittati tramite la chiave di sessione concordata. SSL Record Protocol è responsabile della crittazione e dell'integrità dei dati, inoltre è utilizzato per incapsulare i dati trasmessi dagli altri sottolivelli SSL. Handshake Protocol, Change Cipher Spec Protocol e Alert Protocol si occupano invece di gestire la sessione, i parametri crittografici e il trasferimento dei messaggi fra client e server. SSL Record Protocol: si occupa di gestire la segretezza (tramite la conoscenza condivisa di - 24 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

due chiavi di cifratura) e l'integrità dei messaggi (mediante tecniche di hashing per la generzione di codici MAC). Quando i dati, dal livello superiore, arrivano al Record Protocol, questi vengono - frammentati in blocchi (di dimensione massima 214 byte), - compressi (opzionale), - vi viene aggiunto un codice MAC, - vengono cifrati, - viene aggiunto l'header SSL, - infine i pacchetti vengono consegnati al livello sottostante (TCP generalmente). In ricezione si effettuano le operazioni inverse. I metodi di crittazione supportati da SSL sono: Crittografia a Blocchi

Algoritmo

Crittografia a Stream

Dimensione della

Algoritmo

chiave

Dimensione della chiave

AES

128, 256

RC4-40

40

IDEA

128

RC4-128

128

DES

56

3DES

168

FORTEZZA

80

RC2-40

40

DES-40

40 Tabella 1: Algoritmi di crittazione in SSL.

- 25 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

SSL Change Cipher Spec Protocol: usato per il setting dello stato della sessione, comprese le specifiche per la cifratura da utilizzare. SSL Alert Protocol: utilizzato per messaggi di allarmi SSL, che possono essere di tipo warning o fatal; questi sono utilizzati in caso di errori, quali: codice MAC errato, errore di decompressione, suite di sicurezza non negoziabile, errori relativi al certificato (scaduto, revocato, non supportato..) ed altri. SSL Handshake Protocol: consente al client e al server di autenticarsi l'un l'altro e di negoziare la suite di sicurezza (algoritmi di cifratura e MAC), attraverso lo scambio di alcuni messaggi, ognuno dei quali composto dai campi: - Type (Hello_Request, Client_Hello, Server_Hello, Certificate, Certificate_Request...) - Length: lunghezza del messaggio in byte - Content: parametri associati al messaggio Per instaurare una connessione logica fra client e server sono necessarie 4 fasi: inizializzazione delle funzionalità di sicurezza, autenticazione del server e scambio delle chiavi, autenticazione del client e scambio delle chiavi, terminazione.

Immagine 3: Handshake SSL.

- 26 -

Sistemi Telematici A.A. 2007/2008

•

Lapo Cioni

Inizializzazione delle funzionalità di sicurezza: lo scambio è iniziato dal client, che manda il messaggio client_hello, che comprende i seguenti parametri: Version (versione SSL più elevata disponibile al client), Random (un timestamp più un valore creato da un CSPRNG: Cryptographically Secure Pseudo Random Number Generator), Session ID (identificatore di sessione), Cipher Suite (elenco di algoritmi crittografici supportati dal client in ordine decrescente di preferenza; ogni elemento della lista definisce sia un algoritmo di scambio delle chiavi che un CipherSpec), Compression Method (lista di metodi di compressione supportati). Il server risponde con un server_hello, dove sono specificati gli stessi campi e le scelte sulla suite di sicurezza; il primo elemento del campo CipherSuite rappresenta il metodo per lo scambio delle chiavi di sessione (per la crittografia e per il codice MAC), le opzioni possibili sono principalmente: RSA (la chiave segreta di sessione viene crittata con la chiave pubblica del destinatario) o Diffie-Hellman (permette di scambiarsi solo le chiavi pubbliche e di calcolarsi indipendentemente la chiave di sessione).

•

Autenticazione del server e scambio delle chiavi: la seconda fase è iniziata dal server, che manda il proprio certificato con il messaggio certificate (generalmente un X.509); se necessario il server manda separatamente la propria chiave pubblica nel server_key_exchange e richiede il certificato del client con il certificate_request; tale messaggio è composto da due parametri: certificate_type (indica il tipo di algoritmo a chiave pubblica e la scelta è fra RSA e DSS) e certificate_authorities (contiene la lista delle CA accettate). Infine il server chiude la seconda fase con un server_done.

•

Autenticazione del client e scambio delle chiavi: il client verifica la validità del certificato del server la compatibilità coni parametri inviatigli nel server_hello, dopodichè, se è stato richiesto, invia al client il proprio certificato nel messaggio certificate o, se non disponibile, invia il messaggio no_certificate, quindi il client manda il client_key_exchange, che può essere composto dalla chiave di sessione crittata con la chiave pubblica del server se si utilizza lo scambio di chiavi di tipo RSA, oppure dai parametri Diffie-Hellman. Il client invia poi il certificate _verify per fornire una verifica esplicita del proprio certificato.

•

Terminazione: il client invia un messaggio change_cipher_spec e copia il Cipher - 27 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

Spec temporaneo su quello corrente, per confermare la stabilita suite di sicurezza, infine trasmette il messaggio finished per comunicare la terminazione della fase di setup della connessione SSL.

3.4 I Parametri di interesse in SSL

Dopo aver visto schematicamente come si comporta e di quali parti è composta una connessione SSL, ci appare chiaro che il sottolivello di maggiore interesse per il nostro studio sia l'SSL Record Protocol: è questo infatti che si occupa delle operazioni computazionalmente gravose: della crittazione, della compressione, dell'autenticazione e della frammentazione. SSL permette nativamente la scelta di alcuni parametri in fase di negoziazione fra client e server, questi parametri determinano la suite di sicurezza che sarà caratteristica della sessione SSL. I parametri di cui stiamo parlando indicano: - il metodo di compressione - la tecnica di hashing (MD5 o SHA) - il metodo di scambio delle chiavi (RSA o Diffie-Helmann nelle sue varianti) - il tipo di algoritmo a chiave pubblica (RSA o DSS nelle varie composizioni, per lo scambio delle chiavi di sessione) - l'algoritmo di crittografia a chiave simmetrica (DES, 3DES, AES, IDEA, FORTEZZA e RC2 come metodi a blocchi e RC4 come metodo a stream) Ogni metodo porta con se la propria complessità computazionale, che si traduce in utilizzo delle risorse e tempo di calcolo su un device; conoscendo la particolarità del nostro ambiente di studio, dovremo riuscire ad adattare i precedenti parametri alle necessità di un Security Context Aware System.

- 28 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

4.  VPN SSL 4.1  I servizi delle VPN SSL

Le WebVPN e le Thin-Client VPN, nell'insturare un tunnel cifrato di comunicazione, integrano anche altri servizi, quali: •

l'estensione della rete: è possibile creare configurazioni di rete di tipo Mesh, facendo risultare più reti private dislocate in punti geograficamente e strutturalmente diversi come un'unica rete privata; per l'utente, tutta questa rete Mesh privata potrà essere vista come un'unico server remoto (connessione sicura seamless, prerogativa che avevamo anticipato), con il quale scambiare informazioni rese sicure dall'intermediario VPN (VPN Gateway); la rete così formata può allora essere schematizzata come:

Immagine 4: Modello di connessione in VPN. •

Web Proxying: il client fa una richiesta HTTP per una web application al VPN Gateway, questo contatta il server (in questo caso un Web Server) e scarica l'oggetto richiesto con HTTP, dopodichè lo passa al client con una connessione sicura (in HTTPS); questo è propriamente il funzionamente di una VPN SSL clientless: sulla macchina client viene utilizzato solo un web browser, possono essere trattate in questo modo le applicazioni web-enabled:

- 29 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

Immagine 5: Web Proxying. •

Application Translation: il client fa una richiesta per un'applicazione che richiede un protocollo non-HTTP, fra VPN Gateway e Server (Application Server) vengono scambiati i messaggi utilizzando il protocollo nativo, questi saranno poi tradotti in HTML e trasmessi su HTTPS al client, che sta infatti utilizzando un Web Browser:

Immagine 6: Application Translation. •

Port Forwarding: questa tecnica può essere utilizzata per fingere sul client di instaurare una comunicazione non HTTPS: il client vuole accedere con il protocollo nativo al server della rete privata; un thin-client installato sulla macchina dell'utente si occuperà di filtrare questi pacchetti (es: POP3), redirigendo il traffico all'interfaccia di rete logica (localhost); i pacchetti punteranno quindi alla porta 110 (POP3) del localhost, quindi il thin-client agirà da proxy locale (PFL: Port Forwarding Listener) e reindirizzerà il traffico sulla porta 443 (HTTPS) del VPN Gateway, il quale si occuperà, attraverso il PFR (Port Forwarding Receiver) di inoltrare i pacchetti sulla porta 110 dell'Application Server sulla rete privata; in questo caso è necessario un software lato client: sulla macchina dell'utente verrà scaricata ed installata un'estensione ActiveX o Java detta Thin Client o Shim (il PFL), che tradurrà il traffico del client in html crittato con SSL e agirà da proxy locale; il VPN Gateway avrà bisogno di conoscere a quale porta redirigere il traffico, quindi questo tipo di VPN non - 30 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

può essere usato con protocolli che utilizzano porte dinamiche (ad esempio: può essere sfruttato per SFTP, che utilizza la porta 22, ma non con FTP passive mode, che utilizza la porta 21 per il controllo e porte dinamiche >1024 per i dati):

Immagine 7: Port Forwarding. Una VPN che lavori strettamente clientless ha accesso a Web servers, applicazioni Citrix, Common Internet File System (CIFS) file shares, Microsoft Outlook Web Access (OWA) email; il port forwarding (che comporta l'utilizzo di un Thin-Client) permette invece di estendere l'accesso ad altre applicazioni TCP-based, quali SSH e Telnet. Per poter utilizzare una qualsiasi applicazione IP (ad esempio il VoIP) e quindi anche UDP, però, è necessario montare una VPN SSL Tunnel Mode, ovvero di installare un client sulla macchina di ogni host remoto, ad esempio utilizzando OpenVPN.

4.2  Gestione della VPN e definizione delle  

caratteristiche 4.2.1 Private Network e User remoto Come abbiamo visto, le VPN SSL permettono un gestione granulare degli accessi e un'elevata flessibilità nel controllo del grado di sicurezza richiesto per ogni singolo accesso. Per ottimizzare questa flessibilità, anche in funzione del sistema che stiamo analizzando, ovvero un sistema sensibile ai cambiamenti di contesto, possiamo pensare di spezzare la nostra connessione VPN in due parti: una esterna ed una interna al Gateway VPN (sul quale gira il - 31 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

SSL VPN Appliance). Internamente riteniamo giusto fare una partizione delle informazioni, in modo che queste possano essere gestite in modo autonomo: una suddivisione fisica (server distinti gestiscono e forniscono applicazioni distinte) e logica (una possibilità è quella di suddividere la rete privata in più Virtual LAN); questa partizione interna delle informazioni non comporta di per se un maggior grado di sicurezza, ma permette, attraverso l'interfaccia fisica e logica fornita dal VPN Gateway, una gestione delle politiche di sicurezza più mirata. Possiamo pensare di suddividere la parte interna della rete in almeno 3 macrogruppi, con gestione degli accessi diversificata: 1. Web Based Applications; 2. File Sharing; 3. Thin Client/Server Appications.

In tal modo abbiamo già identificato 3 distinte Policy di sicurezza da definire. Esternamente alla LAN (sull'interfaccia esterna del VPN Gateway) avremo gli utenti che vorranno accedere alla rete privata. Almeno tre condizioni possono caratterizzare l'accesso: 1. il Punto di accesso (la rete di accesso: IP Address...); 2. il Dispositivo di accesso (OS, piattaforma hw...); 3. l'Identità e stato dell'utente (LDAP, Radius, tokens, username e password...).

4.2.2 Soluzioni VPN SSL

Per ogni situazione è quindi possibile definire delle policy di sicurezza adeguate al contesto: si possono creare delle Group Policy, aggiungere gli utenti (che faranno riconoscere la loro identità) alla lista delle Group Policy e definire un diverso grado di sicurezza per le diverse aree interne alle quali l'utente vuole accedere. Il requisito più stringente, che ci ha indirizzato verso la scelta di utilizzare VPN SSL è quello - 32 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

della portabilità: non avere necessità di un client installato sul terminale dell'end-user è fondamentale per l'utilizzo in sistemi Context Aware; questa prerogativa ci ha chiaramente spinti ad escludere, dalla famiglia delle VPN SSL, le SVC (SSL VPN Client). Vogliamo quindi utilizzare WebVPN e Thin-Client VPN: questo significa restringere il raggio alle sole VPN browser-based; il nostro VPN Gateway dovrà essere un Web Application Proxy (Web Proxying + Application Translation), che fornisca anche la funzione di Port Forwarding. Esistono numerose soluzioni per VPN SSL con software proprietario (AEP Networks, Array Networks, Astaro, Check Point Software, Cisco Systems, F5, Juniper Networks, Netgear, Nokia, Nortel, Safe Net, SonicWall, Stonesoft, Sun...); volendo però lavorare, a scopo di ricerca, con soluzioni open source, una soluzione comune per le VPN SSL si chiama OpenVPN: è usata per creare tunnel crittati per connessioni di tipo Remote Access e LAN-toLAN, non è però un Web Application Proxy e non prevede un utilizzo attraverso un web browser. Fra le soluzioni clientless che possiamo trovare, ci sono invece SSLBridge e SSLExplorer. WebVPN e Thin-Client VPN sono due tecniche di fare VPN molto simili, ma che differiscono tuttavia in un punto fondamentale: per le prime l'accesso alla VPN è garantito attraverso l'utilizzo di un semplice browser, mentre per le seconde è necessario scaricare un thin-client, appunto, detto anche Shim o Dissolvable Java/ActiveX Agent, che verrà temporaneamente installato sulla macchina dell'utente; qui nasce un vincolo legato ai permessi dell'utente: per installare il thin-client, infatti, sarà necessario che l'utente abbia i permessi di aministratore sulla macchina dalla quale intende accedere alla rete privata e la detenzione di questi permessi potrà essere un punto critico in scenari di spinta mobilità, come per utenti di tipo roadwarrior. Abbiamo indicato due soluzioni Open Source: SSLBridge e SSL-Explorer; SSLBridge è definito come un Browser Samba: è un applicazione web sviluppata in AJAX (Asynchronous JavaScript and XML) e DHTML (Dynamic HTML) che permette di accedere a files condivisi in una rete, creando un tunnel VPN attraverso internet utilizzando SSL e Samba. SSLBridge permette di utilizzare un semplice browser web per accedere alle risorse della rete privata, fornendo sicurezza (crittazione) attraverso SSL e autenticazione attraverso Samba, con l'utilizzo di Active Directory (AD) Server. SSL-Explorer è una soluzione VPN SSL open source sviluppata in java e distribuita in due edizioni dalla compagnia inlgese 3SP Ltd: l'edizione Community e quella Enterprise; l'edizione Community viene distribuita gratuitamente sotto licenza GPL; permette di creare tunnel cifrati tramite VPN SSL Clientless attraverso l'utilizzo del browser, l'unica dipendenza - 33 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

di SSL-Explorer sui client è una JRE (Java Runtime Environment); supporta il directory service. Le soluzioni possibili per l'implementazione di una VPN sono quindi molte e spesso molto simili; riteniamo, comunque, che la scelta dell'adeguata VPN SSL debba essere fatta tenendo in considerazione quei requisiti che nel corso del lavoro si sono dimostrati fondamentali, ovvero la VPN dovrebbe: - essere basata su SSL; - supportare clientless e thin-client; - permettere una gestione molto flessibile delle politiche di sicurezza; - essere platform independent; - permettere una connessione sicura il più possibile IPSec-like (accesso alla maggior parte delle risorse); - supportare l'utilizzo di un proxy fra il Gateway VPN e la rete esterna; - compatibile con i più diffusi web browser.

4.2.3 L'utilizzo delle risorse

Dopo aver identificato le caratteristiche generali che vorremmo la nostra VPN avesse, dedichiamo la nostra attenzione a definire le specifiche tecniche richieste per un sistema che dovesse implementare una VPN di questo tipo: creare un tunnel cifrato vuol dire aggiungere sicurezza alla comunicazione, quindi introdurre ridondanza; utilizzare tecniche quali IPSec o SSL per creare una trasmissione sicura comporta un overhead nei pacchetti trasmessi: più questo overhead è percentualmente basso rispetto alle dimensioni dei pacchetti, più il throughput relativo al carico utile aumenta. Un fattore da considerare nella scelta dell'implementazione della VPN e nella definizione delle specifiche dei sistemi di rete è quindi il numero di bytes di overhead introdotti dalla tecnica stessa. Questo valore va comunque mediato da altri fattori, primo fra tutti il livello di sicurezza ottenibile dal tunnel VPN: avendo a che fare con un sistema Context Aware, il nostro obiettivo non sarà quello di definire una soluzione univoca, ma, piuttosto, una famiglia di soluzioni che potranno essere - 34 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

utilizzate in funzione della situazione applicativa; ad esempio possiamo immaginare che un accesso in VPN da parte di un utente connesso ad una rete particolarmente insicura, potrà valere l'utilizzo di metodi crittografici più robusti al prezzo di un carico sulle risorse della macchina e della rete, nonchè di un overhead, maggiori. Prendiamo come esempio comparativo rispetto ad SSL il competitor che avevamo scartato, IPSec: facendo un analisi del caso peggiore, IPSec introduce i seguenti overhead in termini di bytes in funzione del modo (Trasporto o Tunnel) e cifratura (3DES/AES):

Packet Size

Transport

Transport

Transport

Tunnel Mode

Mode ESP

Mode ESP

Mode AH

ESP

Tunnel Tunnel

Mode AH

46

61%

70%

43%

3DES/SHA-1 Mode ESP SHA-1 AES/SHA-1 104% 113% 87%

512

5%

6%

4%

9%

10%

8%

1500

2%

2%

1%

3%

3%

3%

3DES/SHA-1 AES/SHA-1 SHA-1

Tabella 2: Overhead di bytes per IPSec.

Prendendo come riferimento un pacchetto medio di 512 bytes e il Tunnel Mode ESP AES/SHA1 come tecnica più comune, IPSec introduce un overhead del 10%, quindi circa 50 bytes di overhead medio, comprensivi di header e trailer ESP più il nuovo header IP. SSL, invece, introduce un overhead molto minore: solamente 21 bytes aggiuntivi se viene utilizzata MD5 come funzione di Hash o 25 bytes se si utilizza SHA-1; se quindi vogliamo gestire l'overhead di una comunicazione SSL (ad esempio siamo in condizioni in cui la rete ci offre una banda limitata e vogliamo ottimizzarne l'utilizzo in termini di throughput, oppure, al contrario, si ha un eccesso di banda a disposizione e possiamo permetterci di avere anche un elevato overhead pur di aumentare il livello di sicurezza), allora uno degli elementi da definire è, come visto, la scelta dell'algoritmo di hashing; oltre a questo, ed ancora più rilevante per la gestione dell'overhead, deve essere individuato il giusto algoritmo di crittazione: la crittazione incide in larga parte sul carico computazionale che grava sugli endpoint ed introduce, inoltre, una rilevante ridondanza. L'overhead introdotto dagli algoritmi di crittazione è funzione del tipo di algoritmo utilizzato: utilizzando algoritmi a blocchi, ad esempio, i messaggi vengono divisi in blocchi di dimensioni fisse, prima di essere crittati (ad esempio: DES e 3DES: 64 bit; - 35 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

AES: 128 bit); è proprio durante la fase di crittazione che viene introdotta ridondanza: generalmente la dimensione dei messaggi che giungono al sottolivello SSL Record Protocol non sarà un multiplo della dimensione dei blocchi dell'algoritmo e dovremo aggiungere dei bit (di Padding) per effettuare la crittazione. Questo overhead può essere anche molto significativo (fino a circa il 50% del pacchetto) soprattutto per pacchetti di piccole dimensioni; nella scelta dell'algoritmo da utilizzare va quindi considerato questo inconveniente introdotto dagli algoritmi di crittazione a blocchi, a differenza del comportamento degli algoritmi a stream. Come visto, DES e 3DES utilizano blocchi più piccoli di AES, quindi introdurranno percentualmente meno overhead. Altro fattore da considerare nella valutazione della nostra VPN è il carico di lavoro computazionale richiesto alle macchine del sistema: uno dei passaggi più onerosi è la fase di de/crittazione; ogni messaggio SSL viene autenticato andando a creare un MAC (Message Authentication Code): a differenza di IPSec, SSL crea prima il MAC, lo inserisce nel pacchetto, poi critta tutto il messaggio; questo può rappresentare uno spreco delle risorse, in quanto la CPU sarà accupata nell'opera di decrittazione anche per i pacchetti che dovranno essere poi scartati. Per quanto riguarda la fase di handshake, durante l'instaurazione di una sessione SSL, una delle operazioni più complesse è la definizione della chiave segreta: questa può essere calcolata utilizzando lo schema di Diffie-Hellman, che permette ai due endpoint del tunnel di determinare la chiave in maniera indipendente; il costo di questa operazione è porporzionale al numero di bit con il quale si vuole effettuare l'algoritmo di Diffie-Hellman, che, a sua volta, sarà definito dal livello di sicurezza che si vuole raggiungere. SSL si dimostra generalmente più sensibile, in termini di prestazioni, al Diffie-Hellman piuttosto che all'RSA, quando si va ad incrementare il numero di bit; d'altra parte l'utilizzo del D-H comporta una maggiore sicurezza, evitando di trasmettere le chiavi di sessione. Un ulteriore elemento che incide fortemente sull'utilizzo delle risorse e sul throughput effettivo è l'algoritmo di compressione utilizzato: IPSec utilizza il protocollo IPComp, che supporta vari algoritmi (Deflate, LZS, LZJH); SSL, invece, non fa grande utilizzo della compressione ed uno dei pochi toolkit che implementano la compressione in SSL è OpenSSL. L'algoritmo di crittazione è forse la scelta più delicata e l'applicazione più onerosa a livello di risorse computazionali in un sistema sicuro; SSL supporta DES, 3DES, AES, RC4, RC2 e altri meno comuni. L'utilizzo della CPU varia a seconda del protocollo utilizzato, ad esempio: - 36 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

3DES e RC2 impegnano generalmente più a fondo le risorse della macchina di quanto non facciano DES e RC4, a scapito del livello di sicurezza: 3DES è ritenuto infatti un algoritmo più sicuro del DES, ad esempio. Molto spesso i web browser sono configurati per utilizzare di default RC4 come algoritmo di crittazione (sappiamo che gli algoritmi a stream sono più performanti in fatto in overhead sui bytes), quando però si vuole un maggior grado di sicurezza è scelta comune utilizzare un algoritmo a blocchi come il DES, o il 3DES per una sicurezza ancora maggiore. RC4 permette quindi un rate di crittazione molto elevato, mentre con DES il rate si abbassa di circa 1/4 e con 3DES di circa 1/8 rispetto a RC4. Appare chiaro come una macchina dotata di risorse computazionali limitate (come possono essere dispositivi quali smartphone e PDA, che non montano solitamente processori particolarmente prestanti) potrebbero avere bisogno di adattare l'algoritmo di crittazione alla loro capacità di calcolo, decrementando però, in tal modo, il livello di sicurezza; questa condizione dovrebbe poi essere accompagnata da una riformulazione dei permessi di accesso alle aree della rete privata, mantenendo inaccessibili, ad esempio, servizi che offrono dati particolarmente sensibili. Le funzioni di hashing, che producono i Digest Messages per la creazione del MAC, sono a loro volta algoritmi particolarmente impegantivi per le risorse computazionali delle macchine: in particolare SSL supporta MD5 e SHA; questi algoritmi sono molto più sensibili alle dimensioni dei pacchetti da elaborare di quanto non lo siano gli algoritmi di crittazione. Generalmente MD5 è settato come funzione di hashing di default nei più comuni web browser, perchè permette un rate maggiore nella creazione e verifica dei Digest Messages; SHA permette, d'altro canto, una sicurezza maggiore (per le hash functions si parla di "collision resistance": la probabilità che due diversi blocchi di bit in ingresso non vengano mappati nello stesso digest message), al costo di un abbattimento medio del rate di circa 1/3 e di un maggior consumo di energia. A livello temporale, inoltre, l'overhead è particolarmente influenzato dalla procedura di Handshake dell'SSL: la fase di setup della connessione SSL, come l'abbiamo vista precedentemente, richiede molto più tempo di quanto lo richieda la procedura di de/crittazione di un messaggio di medio-grandi dimensioni; questa valutazione è particolarmente importante per situazioni in cui la connessione sicura porterà all'instaurazione di più sessioni SSL nel tempo, scenario quantomeno probabile in sistemi Context Aware. La soluzione a questo problema coincide evidentemente con la soluzione dei problemi legati all'handhoff crosslayer, - 37 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

come avevamo accennato: il riuso degli stati delle sessioni SSL, ad esempio, porterebbe ad un drastico abbattimento dei costi delle connessioni SSL.

4.2.4 Compatibilità: alcuni esempi

In ultima analisi, siamo interessati a fare una ricerca sui principali fattori di compatibilità proposti dalle più comuni soluzioni VPN SSL: per individuare i maggiori vendor di soluzioni VPN SSL confrontiamo il rapporto "Magic Quadrant for SSL, North America, 3Q07" della compagnia Gartner: fra i maggiori produttori indicati ci sono Juniper Networks, Citrix, F5 e Cisco. Questi vendor propongono soprattutto piattaforme di sicurezza basate su VPN installate su unità indipendenti; sappiamo come le SSL-based siano le VPN maggiormente felssibili, ma una breve ricerca fra i datasheet dei prodotti di punta di punta proposti da questi vendor ci potrà dare alcune indicazioni su quali siano i reali vincoli di compatibilità nella strutturazione di una VPN SSL. Come esempio prendiamo Immagine 8: "Magic Quadrant for SSL, North

l'Adaptive Security Appliance serie 5500 della Cisco: nelle ultime versioni

America", Gartner.

dell'Appliance non è più previsto l'utilizzo di un client SSL Cisco, riducendo l'utilizzo della VPN SSL ai soli metodi clientless e thin-client (port-forwarding) ed evitando la ridondanza che si sarebbe venuta a creare con gli altri due metodi VPN supportati dalla macchina: IPSec e L2TP-over-IPSec; l'analisi di compatibilità riguardo i sistemi operativi comprende MS Windows Vista 32 e 64 bit, MS Windows XP 32 e 64 bit, MS Windows 2K 32 bit, MAC OS X 10.4 e 10.5, sistemi Linux 32 bit; l'autenticazione tramite certificati e smartcard è garantita per piattaforme Linux solo con l'utilizzo di VPN SSL clientless; per tutte le piattaforme è - 38 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

previsto il servizio Cache Cleaner: permette di pulire completamente la cache del browser una volta terminata la sessione, ottenendo un ulteriore grado di sicurezza; la funzione di Port Forwarding è compatibile con tutte le piattaforme in analisi, con l'indicazione specifica di utilizzare la JRE della Sun: in effetti questa restrizione è piuttosto comune ed è presente anche nei datasheet di SSL-Explorer. Per estendere le funzionalità della VPN SSL, oltre al Port Forwarding Cisco utilizza una tecnica chiamata Smart Tunnel, che promette le stesse funzionalità senza l'onere di dover installare una applet Java/ActiveX; questa tecnologia non è però supportata per MAC OS X e Linux. Il mobile support è piuttosto ristretto per le connessioni IPSec (solo alcuni vendor forniscono client compatibili con ASA) e L2TP-overIPSec (compatibile solo con Apple iPhone e MS Windows Mobile 2003 e 5.0), mentre non è prevista alcun tipo di restrizione per Pocket PC, PDA o Smartphone su VPN SSL clientless, a meno dell'utilizzo di un web browser java-enabled. Nonostante ciò, Cisco si è riservata di certificare quattro mobile devices per connessioni VPN SSL connectionless: HTC p3600 , HP iPAQ hx 2495b e HP iPAQ h4150 con l'utilizzo del browser Pocket IE, iPhone con browser Safari. Per quanto riguarda i browser compatibili, infine, Cisco ne indica tre: Internet Explorer (v.6+), Firefox (v.1.5+) e Safari (v.2+). Come possiamo notare, SSL è l'implementazione VPN effettivamente più flessibile, nonostante ciò sono evidenti alcuni vincoli di compatibilità che in letteratura parrebbero non esistere. In aggiunta a questi tipi di dispositivi hardware, è possibile implementare VPN utilizzando piattaforme software costruite come veri sistemi operativi: alcuni esempi sono i prodotti di Astaro e Sun Microsystems; con questi esempi possiamo infine definire alcuni ordini di grandezza riferiti alle specifiche tecniche generiche necessarie per una macchina sulla quale si volesse installare una suite di applicativi necessari ad implementare una VPN SSL. Per la piattaforma Astaro Security Gateway Software (si tratta di un vero e proprio sistema operativo), ad esempio, viene consigliata l'installazione su sistemi con processore Intel; per un'utenza medio-bassa (meno di 50 utenti) vengono definiti come requisiti minimi una frequenza di clock della CPU di 800 MHz, una memoria RAM di almeno 512 MB ed un HardDisk di almeno 20 GB; per un'utenza media (fino a 600 utenti), vengono invece consigliati CPU con frequenza di clock di almeno 2.4 GHz, RAM da 1024 MB e HardDisk da almeno 80 GB; per un'utenza elevata (fino a 2500 utenti), inoltre, si consigliano frequenze di clock di almeno 3.5 GHz, Ram minima di 4096 MB e HardDisk da almeno 120 GB. Il Sun Java System Portal Server Secure Remote Access è invece una suite di applicativi, da installare su un sistema operativo preesistente e permette anch'esso di - 39 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

implementare VPN SSL; in questo caso le specifiche tecniche rischieste sono meno stringenti al livello hardware (almeno 512 MB di RAM e 1 GB di harddisk, CPU con frequenza di clock di almeno 450 MHz), mentre a livello software sono supportati solo i sistemi Solaris 8+ e Red Hat Enterprise ed indicati i browser Netscape (v.6.2+), MS IE (v.5+) e Mozilla (v.1.7+).

- 40 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

5.   Conclusioni

Con questo elaborato abbiamo cercato di determinare le caratteristiche generali che una Virtual Private Network dovrebbe avere affinchè essa possa fornire un adeguato livello di sicurezza a connessioni remote che vengano instaurate in scenari di tipo Context Aware. Nella scelta delle caratteristiche tecniche della nostra VPN abbiamo voluto considerare un ampio spettro di soluzioni, cosicché ogni tecnologia concorresse alla ricerca della soluzione, apportando i propri vantaggi e svantaggi. Uno scenario di Security Context Aware è estremamente complesso ed articolato e meriterebbe una trattazione approfondita per poterne comprendere la vera essenza; ciononostante, un approfondimento di questo tipo esula dagli obiettivi prefissi durante la stesura di questo lavoro, del quale la prima fase è consistita di fatto in un'opera di ricerca e di cernita della tecnologia più appropriata. Fin dall'inizio è apparso evidente come la selezione non si potesse basare solamente sulle prestazioni promesse da uno standard o da un protocollo, ma dovesse fare i conti con l'effettiva possibilità di implementazione, con le necessità di compatibilità e di portabilità. Fra le possibili soluzioni, come concorrenti più adatti si sono mostrati IPSec (OpenSwan) ed SSL. Il primo ha fra i suoi punti di forza la grande popolarità, il livello di sicurezza e le prestazioni; SSL è però stata da subito la tecnologia vincente: facilità d'uso, portabilità e adattabilità sono caratteristiche estremamente importanti in un sistema Context Aware e queste sono i fondamenti delle VPN basate su SSL; non per caso queste VPN stanno letteralmente conquistando il mercato. All'interno della famiglia delle VPN SSL abbiamo indicato le clientless e le thin-client come soluzioni più adatte, per i motivi suddetti; in aggiunta alla fondamentale assenza di un client da configurare, queste VPN permettono una gestione delle policy di sicurezza granulare, quindi i metodi di crittazione, autenticazione e controllo dell'integrità potranno effettivamente essere gestiti in funzione del contesto, come era desiderato fare all'interno del sistema studiato. La Security Context Awareness, come detto, propone situazioni di connessione estremamente diversificate; non è quindi stato nostro obiettivo proporre una soluzione di sicurezza univoca, nè sarebbe adeguato a trattare il sistema considerato. Va sottolineato che una buona implementazione di sicurezza adattiva tramite VPN SSL non prevede solamente la scelta e la configurazione adeguate dell'opportuna

- 41 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

VPN, ma anche una strutturazione ben fatta e funzionale di tutta la rete privata, come abbiamo precedentemente visto. Inoltre, molte strutture VPN permettono di utilizzare tecniche diverse, fra le quali sia SSL sia IPSec; in una rete privata distribuita secondo i criteri sopra citati, entrambe le soluzioni dovrebbero trovare spazio, andando ad utilizzare l'una e l'altra (ad esempio: IPSec per connessioni sicure 'statiche' di tipo LAN-to-LAN e SSL per connessioni 'dinamiche' di tipo Remote Access) nelle diverse situazioni. In questo lavoro abbiamo definito alcune caratteristiche che ci sono sembrate importanti per una VPN in ambito Context Aware; alcune prerogative si sono delineate in maniera ben definita (che la VPN sia SSL-based, supporto clientless e thin-client, supporto di più metodi di autenticazione come descritti...), mentre altre caratteristiche dovrebbero essere ricavate in funzione della situazione specifica di utilizzo della VPN, riflettendo sulle valutazioni fatte in questo elaborato; in questo lavoro di adattamento ad-hoc della soluzione VPN, devono essere valutate almeno sei aree funzionali per la sicurezza, come definite nello standard FIP-191 (Federal Information Processing): l'Autenticazione, il Controllo degli accessi, la Confidenzialità, l'Integrità dei messaggi, il Non ripudio, il Monitoraggio. Un sistema sicuro deve assolvere a tutti questi compiti e, all'interno dello scenario considerato, lo deve fare mantenendo un alto livello di adattabilità al contesto; applicando queste ipotesi al sottoinsieme del sistema sicuro che abbiamo analizzato, ovvero le Virtual Private Network, ci è apparso chiaro come solamente SSL, fra le tecnologie qui prese in considerazione, potesse assolvere a questi compiti, permettendo di connettere in modo sicuro ogni host non con un'intera rete, ma con singole applicazioni.

- 42 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

Bibliografia: •

http://www.siti.disco.unimib.it/didattica/sistemica

•

'Privacy In Context', Mark Ackerman, Trevor Darrell, and Daniel J. Weitzner, work supported by the Oxygen Alliance partners at MIT

•

'Tutorial Context-Aware Computing', Christian Becker, Universität Stuttgart, Institute of Parallel and Distributed Systems (IPVS)

•

'Supporto per la gestione dell'handoff verticale per sistemi multimediali', Veljko Vuković, Università degli studi di Bologna, Facoltà di Ingegneria

•

http://www.vpnlabs.org/

•

http://openskill.info/

•

http://www.networkworld.com

•

Review: Joel Snyder, Network World, 05/10/99

•

'Soluzioni VPN per Road Warriors' Alessandro Brunego, per il gruppo VPN del Netgroup, http://www.infn.it/netgroup

•

http://www.vpnc.org

•

http://www.cnaponline.com, Cisco Networking Academy Program

•

http://www.cisco.com

•

http://www.cisco.com/warp/public/732/L2F/

•

http://computer.howstuffworks.com/vpn.htm

•

http://tools.ietf.org/html/rfc2246

•

http://www.cisco.com/en/US/products/ps6120/products_configuration_example 09186a00806ea271.shtml

•

http://lists.openswan.org - 43 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

•

http://wiki.openswan.org/index.php/OE/Quickstart

•

'VPN Decision Guide, IPSec or SSL VPN decision criteria', Roslin Rissler, Sarah Sorensen; Juniper Networks

•

http://www.cisco.com/en/US/docs/security/security_management/cisco_security _manager/security_manager/3.2/user/guide/webvpnpg.html

•

http://www.centrocomputer.it/INTERNA/PRESENT.nsf/4d1800f63ae559cb4125 67520051e059/203a439796a1dfe7c12570900035899e/$FILE/Citrix%20Access %20Gateway.pdf

•

http://tools.ietf.org/html/rfc2246

•

http://tools.ietf.org/html/rfc4346

•

http://infocom.uniroma1.it/alef/cisterna/4-sicurezza/sicurezza.html

•

http://infocom.uniroma1.it/alef/cisterna/esercitazioni/sicurezza.html#mozTocId 773864

•

http://lagash.dft.unipa.it/AL/al290.htm

•

http://wp.netscape.com/eng/ssl3/draft302.txt

•

http://www.dmoz.org/Computers/Security/Public_Key_Infrastructure/PKIX/Too ls_and_Services/Third_Party_Certificate_Authorities//

•

http://www.windowsecurity.com/articles/Secure_Socket_Layer.html

•

http://www.guruatwork.com/index.php? option=com_content&task=view&id=210&Itemid=33

•

http://www.cisco.com/en/US/docs/security/asa/compatibility/asa-vpncompatibility.html

•

http://www.sun.com/software/products/portal_sra/index.xml

•

"A technical comparison of IPSec and SSL", AbdelNasir Alshamsi & Takamichi Saito, Tokyo University of Technology - 44 -

Sistemi Telematici A.A. 2007/2008

Lapo Cioni

•

"Analysis of Enterprise VPNs", Arif Basha, George Mason University

•

Astaro Security Gateway v7, sizing guideline (www.astaro.com)

•

G. Apostolopoulos, V. Peris, P. Pradhan, and D. Saha, “Securing Electronic Commerce: Reducing the SSL Overhead,” IEEE Network

•

Ramesh Karri, Piyush Mishra, "Minimizing Energy Consumption of Secure Wireless Session with QoS Constraints", Wireless Internet Center for Advanced Technology

•

Nachiketh R. Potlapally, Srivaths Ravi, Anand Raghunathan and Niraj K. Jha, "Analyzing the Energy Consumption of Security Protocols", Princeton University

- 45 -