1 Differenze di funzionalità

IPsec e TLS sono strutturati in maniera molto diversa: TLS è un singolo protocollo descritto da un unico RFC, ed ha una struttura lineare e relativamente semplice, IPsec al contrario ha un'architettura molto complessa e formata da elementi diversi (i protocolli AH, ESP e IKE³⁴, i database SPD e SAD) specificati in documenti diversi. Questa grande complessità determina probabilmente varie difficoltà nell'implementazione e nell'utilizzo di IPsec, ed è secondo alcuni (si veda [11]) una debolezza anche dal punto di vista della sicurezza crittografica. Le funzionalità ``ad alto livello'' sono abbastanza simili: sia IPsec che TLS offrono servizi di riservatezza, integrità e autenticazione, e nessuno dei due offre il non ripudio³⁵. Inoltre, sono entrambi flessibili per quanto riguarda la scelta degli algoritmi di cifratura e di hash, ma IKE di IPsec offre diversi meccanismi di autenticazione dell'identità dell'interlocutore mentre TLS utilizza solo i certificati. D'altra parte TLS permette anche un'autenticazione asimmetrica dell'identità, ovvero permette di autenticare il server senza autenticare il client, mentre IKE di IPsec, essendo un protocollo peer-to-peer e non client-server, non fornisce questa possibilità per cui o si autenticano entrambi gli interlocutori oppure non si autentica nessuno dei due. Descrivendo la sequenza delle trasformazioni applicate da TLS si è visto inoltre che è esplicitamente prevista la compressione dei dati prima della cifratura: questa funzione non è propriamente presente in IPsec, ma è comunque realizzabile attraverso il protocollo IPComp [9]. Vale la pena di notare che la sequenza delle operazioni di cifratura e autenticazione è diversa nei due casi: in TLS prima si calcola il MAC e poi si cifra il tutto, MAC compreso, mentre in IPsec prima si cifra e poi si aggiungono i dati di autenticazione, che vengono quindi calcolati sul messaggio cifrato e non su quello in chiaro. Quello di TLS è in effetti l'ordine usuale in cui vengono applicate autenticazione e cifratura; la ragione per cui IPsec compie queste operazioni in ordine inverso è legata alle prestazioni: in questo modo infatti un pacchetto con un'autenticazione non valida viene scartato subito, senza doverlo prima decifrare. Quest'approccio è anche più robusto dal punto di vista degli attacchi di denial of service, anche se è controverso dal punto di vista crittografico (si veda ancora [11]). Le differenze tra IPsec e TLS sono per la maggior parte una diretta conseguenza della loro diversa posizione all'interno dello stack TCP/IP. Innanzitutto bisogna considerare il diverso ``punto terminale'' della comunicazione sicura: TLS offre un canale sicuro tra due applicazioni, poiché opera al livello dei socket, mentre i terminali della comunicazione IPsec sono due macchine. Questo non significa che le security association di IPsec siano associate esclusivamente alle macchine: possono avere granularità più o meno fine, e in particolare possono essere associate ai socket e quindi alle applicazioni. Tuttavia l'elaborazione IPsec avviene comunque a livello IP, e quindi in un ambito relativo all'host e non all'applicazione: quando il traffico è arrivato nell'host di destinazione, IPsec ha finito il suo compito e quindi i dati non sono più protetti. Il discorso è analogo per quanto riguarda l'entità che viene autenticata: con TLS è naturale che sia l'applicazione o l'utente, mentre questo è un po' più complicato (per quanto possibile) con IPsec, attualmente più adatto ad autenticare la macchina. Per quanto riguarda i protocolli di livello superiore, IPsec protegge tutto ciò che sta sopra IP, quindi ad esempio TCP, UDP, ICMP. TLS invece si deve appoggiare su un protocollo di trasporto affidabile, e quindi può essere utilizzato solo per proteggere traffico TCP; questa è una limitazione importante perché esclude ad esempio molte applicazioni real-time che viaggiano su UDP. TLS è adatto a proteggere la comunicazione tra due applicazioni, mentre IPsec può facilmente rendere sicuro tutto il traffico tra determinati host, o tra intere sottoreti. IPsec cifra tutto ciò che segue l'header IP, e quindi anche l'header TCP, e questo può prevenire alcuni attacchi a basso livello (attacchi al TCP) o alcune analisi del traffico (in quanto non sono visibili dati come i numeri di sequenza, o le porte sorgente e destinazione). D'altre parte però, come si vedrà nel prossimo paragrafo, questo fatto può comportare anche alcuni problemi. Un'altra caratteristica di IPsec utile contro gli attacchi a basso livello è quella di proteggere i messaggi ICMP. Riguardo ai numeri di sequenza, un semplice attacco a TLS è descritto in [12], ed è una conseguenza del fatto che questo opera al di sopra di TCP, il quale quindi non partecipa alle funzioni di sicurezza e non è al corrente delle operazioni crittografiche. Se un intruso inserisce nella comunicazione un pacchetto con un numero di sequenza valido, in ricezione TCP non si accorgerà di nulla per cui invierà il riscontro e passerà i dati a TLS. TLS si accorgerà che i dati non sono validi ma non potrà comunicarlo a TCP, il quale scarterà poi il pacchetto vero considerandolo un duplicato: a questo punto sarà necessario abbattere la connessione. IPsec può garantire in una certa misura l'anonimato degli interlocutori rispetto a chi intercetta il traffico cifrato: sia durante l'handshake (se si utilizza IKE main mode) che durante il trasferimento gli unici dati resi pubblici sono gli indirizzi IP dei security gateway, e non c'è modo di sapere quali siano i due interlocutori. Il caso host-to-host, se si utilizza la modalità tunnel, non è distiguibile da quello gateway-to-gateway da parte di chi intercetti il traffico tra i due host (a meno di sapere con certezza che un dato indirizzo IP non corrisponde ad un security gateway). TLS è invece esclusivamente host-to-host, e dunque sono noti gli indirizzi IP dei due interlocutori e, come poco fa ricordato, al contrario di quanto avviene con IPsec qui sono note anche le porte, per cui sono in una certa misura noti i processi che stanno comunicando, e non semplicemente gli host. A ciò si aggiunge il fatto che durante l'handshake di TLS i certificati delle due parti (che rivelano molte più informazioni sull'identità rispetto al solo indirizzo IP) viaggiano in chiaro, mentre con IKE main mode sono cifrati. Secondo alcuni (si veda [13]) SSL/TLS non è sicuro ed è vulnerabile ad attacchi di tipo man-in-the-middle (MITM), tant'è che esistono programmi come dsniff³⁶ ed ettercap³⁷ che permettono di realizzarli. Tali attacchi si fondano però su comportamenti erronei dell'utente più che su debolezze del protocollo, in quanto si basano sul fatto che l'utente tenda ad ignorare degli avvertimenti che l'applicazione gli presenta, ad esempio nel caso in cui il certificato del server è firmato da un'autorità sconosciuta oppure quando il nome dell'host non coincide con quello indicato nel certificato. È però vero che TLS richiede una grossa partecipazione all'applicazione (che deve espressamente richiedere una connessione sicura, deve preoccuparsi di controllare il certificato fornito dall'interlocutore, deve controllare che i parametri negoziati siano abbastanza forti, eccetera), la quale in genere la richiede all'utente (sia in fase di configurazione dell'applicazione stessa che in fase di utilizzo): questo fatto, pur non essendo un difetto dal punto di vista della sicurezza crittografica, può comunque costituire un punto di debolezza del protocollo. La situazione di IPsec da questo punto di vista è in parte differente, per almeno due ragioni. In primo luogo, IPsec opera al livello del sistema operativo e non dell'applicazione e in genere non interagisce con l'utente, per cui nel caso di sistemi non ``casalinghi'' (in cui cioè il sistema è configurato da un amministratore che si presume più esperto, e non dall'utente) il problema di un'errata configurazione e di politiche di sicurezza troppo deboli è minore. Inoltre, gli attacchi di tipo MITM a TLS/SSL colpiscono come detto la fase di scambio delle chiavi, la quale come già ricordato non fa propriamente parte di IPsec. Se si utilizza IKE secondo una modalità simile all'handshake di TLS, in cui ciascuna delle due parti invia un proprio certificato all'altra, tendenzialmente si è vulnerabili ad attacchi dello stesso tipo (tenendo però presente l'osservazione fatta poco fa sul rapporto con l'utente); tuttavia ci sono altre possibilità, quali l'utilizzo di DNSSEC [14] per reperire le chiavi pubbliche, oppure l'utilizzo di un diverso protocollo di scambio delle chiavi che si appoggi su un sistema di autenticazione robusto (quale ad esempio Kerberos ³⁸, il cui uso non è però ipotizzabile nel caso generale di due host che non hanno alcun rapporto tra di loro). In teoria si potrebbe utilizzare DNSSEC anche con TLS (anche se lo standard attuale del protocollo non lo prevede) ed è prevista un'estensione di TLS che permette l'uso di Kerberos [16], ma questo graverebbe comunque sull'applicazione, che dovrebbe essere riscritta per poterlo fare e dovrebbe preoccuparsi da sé di gestire il tutto. L'accoppiata IPsec-DNSSEC è generalmente considerata più sicura rispetto a TLS (si veda [17] o le ``frequently asked questions'' di dsniff), ma la sua diffusione su larga scala è ancora lontana, sia per DNSSEC in sé sia per IPsec [18], soprattutto per problemi relativi all'attuale protocollo IKE e alla sua grande complessità. Alcune possibili soluzioni attualmente allo studio relativamente all'instaurazione della connessione IPsec saranno trattate al capitolo 5.

Footnotes

... IKE ³⁴: Si veda la nota 4 a pagina .
... ripudio ³⁵: In entrambi i casi tutti i messaggi possono essere generati indifferentemente da uno qualsiasi dei due interlocutori, poiché entrambi sono in possesso delle chiavi segrete necessarie. Questo avviene perché l'uso della crittografia a chiave pubblica, per motivi di prestazioni, è limitato all'autenticazione delle parti nella fase di handshake, mentre per il resto della comunicazione si utilizzano algoritmi simmetrici.
... dsniff ³⁶: Disponibile presso http://www.monkey.org/~dugsong/dsniff.
... ettercap ³⁷: Disponibile presso http://ettercap.sourceforge.net.
...Kerberos ³⁸: A questo proposito, è attualmente allo studio il protocollo KINK [15], che permette di instaurare security association IPsec appoggiandosi appunto su Kerberos.