Virtual Private Networks per Security Context Aware System 14 / 07

Transcript

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-
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-
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-
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-
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-
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-
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-
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-
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
•
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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://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 -
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 -

Virtual Private Networks per Security Context Aware System 14 / 07

Transcript

Documenti analoghi

La VPN SSL di Juniper in 6 slide

SSL_Presentazione Aziendale

Titolo: Configurazione del client TGB (TheGreenBow - Atlantis-Land

TAVOLA DEGLI SVILUPPI DI TAYLOR DELLE FUNZIONI

VPN acronimo di Virtual Privat Network. VPN, che

Scarica la scheda tecnica

Distanze? Le aziende si collegano in rete con le loro

Politica per la Salute e Sicurezza sul lavoro

La INNSE-BERARDI Spa pone tra i propri obiettivi prioritari al pari