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 -


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 -


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 -


- 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 -


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 -


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 -


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 -


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 -


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 -


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 -


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 LAN-

to-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-to-

Site), 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 -


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 -


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 -


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 -


(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 -


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 -


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 -


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 -


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 (one-

time-password) per l'utilizzo con smartphones e PDA.

- 20 -


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 -


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 -


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 -


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 -


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 Crittografia a Stream

AlgoritmoDimensione della

chiaveAlgoritmo

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 -


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.

- 26 -

Immagine 3: Handshake SSL.


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


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 -


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 -


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 -


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) e-

mail; 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 -


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 -


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-to-

LAN, 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 SSL-

Explorer. 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 -


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 -


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

Mode ESP

3DES/SHA-1

Transport

Mode ESP

AES/SHA-1

Transport

Mode AH

SHA-1

Tunnel Mode

ESP

3DES/SHA-1

Tunnel

Mode ESP

AES/SHA-1

Tunnel

Mode AH

SHA-1

46 61% 70% 43% 104% 113% 87%

512 5% 6% 4% 9% 10% 8%

1500 2% 2% 1% 3% 3% 3%

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 -


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 -


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 -


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

l'Adaptive Security Appliance serie

5500 della Cisco: nelle ultime versioni

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 -

Immagine 8: "Magic Quadrant for SSL, North

America", Gartner.


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-over-

IPSec (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 -


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 -


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 -


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 -


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 -


• 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-vpn-

compatibility.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 -

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

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

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

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


• "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

Documents

Transcript of Virtual Private Networks per Security Context Aware System