Servizi di sicurezza nelle reti IP: IPSec, SSL, TLS

Chiediamo alla nostra rete qualcosa di più di un semplice TCP/IP; chiediamo alla rete di diventare sicura, chiediamole:

• autenticazione;
• protezione dell'integrità dei dati;
• confidenzialità.

Vogliamo creare dei servizi che rendano la rete più sicura, e vogliamo che questi servizi diventino come i livelli dello stack protocollare TCP/IP: il più possibile indipendenti dagli altri livelli.

Gli strumenti che ci permettono di raggiungere questo scopo sono IPSec e TLS, due livelli che si inseriscono nello stack protocollare TCP/IP classico.

La pila ISO-OSI e il modello TCP-IP

IPSec è un servizio che si poggia direttamente su IP, è di livello 3; può essere implementato direttamente in hardware, oppure in software: nel caso di implementazioni hardware, sarà completamente trasparente alla macchina, alle applicazioni e al sistema operativo, mentre nel caso di implementazione software, si deve modificare il sistema operativo.

Al contrario, TLS è un protocollo che non prevede modifiche del sistema operativo: deve essere implementato nelle applicazioni. Il problema principale è che TLS è posizionato sopra al TCP, quindi soffre di tutti i difetti del TCP, come l'esposizione agli attacchi DoS e l'esposizione all'attacco del tipo IP spoofing.

IPSec

Posizionamento di IPSec nella pila ISO/OSI e in quella TCP

Il protocollo IPSec non è altro che un insieme di regole che permettono di rendere sicuro, attraverso strumenti crittografici, il protocollo IP; IPSec è definito prima nello standard RFC 2401, successivamente nello standard RFC 4301. L'idea è quella di creare dei canali sicuri attraverso tutti i nodi autorizzati ad avere accesso alla rete, evitando che questo fatto arrechi danno ai livelli superiori ed inferiori, in modo tale da poter rendere crittograficamente sicure anche applicazioni legacy di cui non si dispone il codice sorgente oppure su cui non si vuole spendere denaro per gli aggiornamenti.

Originariamente, IPSec fu pensato per funzionare con IPv6, ma poi venne reso compatibile anche con IPv4; noi studieremo la versione per IPv4, che è la più usata ad oggi.

La prima versione di IPSec risale al 1998 ed era estremamente complicata da implementare; l'aggiornamento, arrivato nel 2005, ha reso l'implementazione e l'architettura di IPSec molto più semplice. Ad oggi, IPSec è implementato in tutti i router/modem, anche quelli economici e domestici, oltre ad essere integrato in tutti i sistemi operativi moderni (da Windows 2000 in avanti, dal kernel Linux 2.4, ed anche in MAC OS con KAME).

Alcune implementazioni di IPSec permettono di utilizzare anche NAT, uno strumento molto utilizzato ad oggi; inoltre, le ultime versioni di IPSec permettono di implementare VPN anche verso singoli nodi isolati in internet.

Security association

Una Security Association SA è una connessione, protetta crittograficamente, che collega due nodi nella rete. Una security association è un oggetto che prevede l'utilizzo di algoritmi e di chiavi: il Security Parameters Index SPI è un indice numerico associato alla SA.

I parametri che distinguono le diverse security association sono:

• l'indirizzo IP della macchina di destinazione;
• quali servizi devono essere disponibili (riservatezza, integrità dei dati e/o autenticazione);
• quali sono gli algoritmi usati per cifrare i dati (DES, 3DES, AES, ...) e le chiavi associate.

In IPSec, le security association sono monodirezionali, quindi è necessario che vengano create almeno due SA, affinché due nodi possano comunicare tra loro in maniera costruttiva.

File:Sicurezza IPSec infrastruttura.png

Per permettere ai nodi di scambiarsi le chiavi, si usa il protocollo Internet Key Exchange IKE; nel 2005, assieme alla seconda versione di IPSec, è stata pubblicata anche la seconda versione di IKE, IKEv2.

Il Security Policy Database SPD è un elenco che serve al computer per tener traccia di quali pacchetti devono essere cifrati prima di essere immessi sulla rete, e quali invece non devono esserlo; il Security Association Database, invece, è il database che contiene tutte le SA e tutte le SPI associate.

All'interno di IPSec, i pacchetti possono essere gestiti in due diverse maniere:

• Encapsulating Security Payload ESP;
• Authentication Header AH.

Questi due metodi di protezione dei dati rispondono ad esigenze diverse; il database SPD serve per indicare al sistema operativo, quando questo deve spedire un pacchetto, se adottare la politica ESP, AH oppure se non adottare alcuna protezione IPSec. Tutti i parametri sono salvati all'interno del database SAD.

IPSec, oltre a trattare in maniera differenziata diversi pacchetti, può funzionare con due modalità diverse:

• modalità tunnel;
• modalità trasporto.

Modalità tunnel vs modalità trasporto

Modalità trasporto e modalità tunnel

Far operare il protocollo IPSec in modalità trasporto ha il vantaggio di migliorare l'efficienza della rete, ma ha il difetto di dover essere implementata nel sistema operativo di ogni singolo calcolatore. Quello che accade in questa modalità è che IPSec aggiunge un header al pacchetto, nel quale stanno scritte le informazioni necessarie al destinatario per ricostruire il pacchetto originale.

Questo approccio ha alcuni problemi con IPv4, per esempio quando dei nodi sulla rete vogliono frammentare i pacchetti troppo grandi; infatti, dopo una frammentazione, il nodo destinatario non sarà in grado di riordinare i pacchetti ricevuti per ricostruire il payload originale, quindi non sarà nemmeno in grado di consegnare i messaggi.

Nella modalità tunnel, ciò che accade è che tutto il pacchetto viene inserito nel payload di un nuovo pacchetto: si aggiungono informazioni ulteriori, si raddoppiano le dimensioni di occupazione dei campi mittente e destinatario, ma si ottiene un vantaggio enorme: la possibilità di implementare il protocollo soltanto su router e firewall.

Questa modalità è molto interessante se pensiamo a degli uffici che devono comunicare tra loro: anche se questi sono separati dal punto di vista geografico, può comunque sussistere l'esigenza di comunicazioni in formato riservato. Grazie a IPSec/Tunnel, questi due uffici geograficamente distanti tra loro possono essere anche all'interno della stessa sottorete IP: quello che si deve fare è configurare i router dei due uffici in modo tale che si spediscano, attraverso internet, i messaggi in forma cifrata. Allora, all'interno di internet si vedranno circolare dei pacchetti con indirizzi sorgente/destinazione i due router, ma nessuno potrà intercettare i pacchetti e sapere, quindi, quali computer stanno comunicando tra loro, né tantomeno qual è l'oggetto della comunicazione.

Encapsulating Security Payload

File:Sicurezza IPSec ESP.png

pacchetto ESP

Il protocollo ESP è definito prima dallo standard RFC 2406, successivamente dallo standard RFC 4303; questo protocollo garantisce autenticazione, confidenzialità e protezione d'integrità sui dati.

Un difetto di questo approccio è che l'header IP esterno non può essere processato autenticato. L'header ESP contiene:

• un numero di sequenza di 32 bit che viene usato per identificare eventuali pacchetti duplicati e per evitare i replay attack;
• il SPI, l'insieme di tutti i parametri che spiegano come decifrare il testo cifrato: l'header viene autenticato, ma non può essere cifrato.

Dopo l'header, se necessario, sarà inserito il vettore di inizializzazione IV dell'algoritmo di cifratura usato per proteggere il pacchetto, dopodiché ci sarà il testo cifrato ed autenticato, all'interno del quale troviamo tutti gli altri header, come quello TCP e gli eventuali applicativi.

A seconda delle configurazioni, ESP può offrire

• autenticazione e integrità dei dati;
• confidenzialità;
• autenticazione, integrità dei dati e confidenzialità.

Authentication Header

Il protocollo IPSec con AH (definito negli standard RFC 2402 prima e RFC 4302 poi) è una configurazione che permette di autenticare tutto il pacchetto che viene spedito nella rete, compreso l'header IP esterno.

File:Sicurezza IPSec AH.png

AH in modalità trasporto

AH in modalità tunnel

Oltre a questo, viene garantita anche l'integrità dei dati su tutto il messaggio, ma non la confidenzialità, cioè non può esserci cifratura del messaggio. Questa configurazione, che autentica anche l'header IP esterno, ha un problema con i campi mutevoli del pacchetto, come il TTL, oltre che con i NAT; secondo molti, la configurazione con AH è superflua.

Internet Key Exchange v2

IKEv2 è un protocollo che ha la funzione di permettere la mutua autenticazione, sfruttando credenziali di lungo periodo, di due nodi Alice e Bob, negoziando tutti i parametri necessari per instaurare una o più security association, con chiavi temporanee.

Questo protocollo, definito negli standard RFC 2407, RFC 2408 e RFC 2409 prima, successivamente dalla RFC 4306, lavora con pacchetti UDP sulle porte 500 o 4500. IKE garantisce la PFS.

File:Sicurezza IKEv2 vista d insieme.png

La prima attività svolta da IKE è uno scambio dati che permette di derivare due chiavi:

• la IKE_SA, una chiave effimera derivata dalle credenziali di lungo periodo;
• la CHILD_SA, una chiave effimera derivata dalla IKE_SA, usata per proteggere i dati degli utenti.

IKE prevede delle security association a due livelli. Il primo livello è quello più computazionalmente importante, nel quale si deriva la chiave IKE_SA. Questa chiave, poi, verrà usata per cifrare delle sessioni intermedie all'interno delle quali, con un algoritmo meno computazionalmente oneroso, si possono derivare più CHILD_SA. Quando i dati cifrati con una CHILD_SA diventano tanti e si rischia di esporre i dati ad analisi crittografica, si riutilizza la IKE_SA per ricalcolare una nuova CHILD_SA con cui continuare a cifrare i dati.

Il risultato finale sarà che i dati possono essere cifrati con più chiavi effimere, in modo da non esporli alla crittanalisi, e che le nuove chiavi effimere possono essere ricavate quando necessario, senza dover esporre nuovamente le credenziali di lungo periodo, che potrebbero essere una coppia di chiavi asimmetriche con certificato digitale.

Le varie CHILD_SA, inoltre, possono essere diverse per scopi diversi. Allora, per risparmiare potenza, alcuni dati meno importanti potranno essere cifrati con chiavi CHILD_SA più corte di altri dati più importanti: abbiamo la possibilità di scalare le politiche di protezione in base all'importanza che diamo ai dati.

Calcolo della chiave principale IKE_SA

Attenzione: questa è una descrizione semplificata del protocollo!

File:Sicurezza IPSec IKE calcolo chiave principale IKE SA.png

La prima cosa da notare è che non esiste un client ed un server: tutti gli utenti hanno la stessa importanza. Sia Alice ad iniziare la trattativa: quello che fa è mandare a Bob un messaggio in cui propone un insieme di criptosistemi, il proprio parametri Diffie-Hellman ed una nonce $N_{A}$.

A questo messaggio Bob risponde con il criptosistema che ha scelto di utilizzare, con il suo parametro DH, con una sua nonce e con una richiesta del certificato di Alice. La chiave effimera IKE_SA viene derivata usando una funzione di MAC, negoziata con questi due messaggi: una volta derivata IKE_SA, Alice e Bob possono cominciare a trasmettersi dati cifrati con il criptosistema che hanno negoziato.

Alice manda a Bob:

• la propria identità;
• il proprio certificato contenente la chiave pubblica
• l'identità di Bob con cui vuole comunicare (perché su una macchina possono esserci tanti Bob, tanti servizi abilitati);
• una firma sui due messaggi che si sono precedentemente scambiati, AUTH;
• un nuovo elenco di criptosistemi utilizzabili;
• un Traffic Selector TS, un descrittore del tipo di traffico che sarà scambiato con la chiave CHILD_SA.

A questo punto, Bob viene a conoscenza dell'identità di Alice, può verificarla in maniera sicura tramite il certificato, e può scegliere il crittosistema che preferisce, tenendo in considerazione anche l'uso che ne verrà fatto, cioè il tipo di traffico che sarà scambiato all'interno della connessione con Alice. La sua risposta contiene:

• la propria identità;
• il proprio certificato digitale;
• una firma sui messaggi scambiati, AUTH;
• la suite di criptosistemi che supporta (se vuole negoziare) oppure il criptosistema che preferisce;
• il suo Traffic selector.

I messaggi scambiati per l'autenticazione vengono utilizzati sia da Alice che da Bob come seme, per derivare la chiave effimera CHILD_SA; i criptosistemi usati per la connessione cifrata con IKE_SA possono essere diversi da quelli usati con le CHILD_SA, a seconda del tipo di traffico e della disponibilità dei due soggetti.

Quando una chiave CHILD_SA termina il suo ciclo di vita e deve essere cambiata, oppure quando si vuole iniziare una seconda security association con l'altro calcolatore, si usa il protocollo CREATE_CHILD_SA, che permette di riutilizzare la cifratura con IKE_SA per negoziare nuovamente tutti i parametri necessari, come per esempio la criptosuite disponibile.

Credenziali

Le credenziali, con IKE, possono essere di varia natura. Possono essere

• l'indirizzo IP di un computer;
• l'indirizzo DNS di un computer;
• l'indirizzo e-mail di una persona;
• ....

L'autenticazione, comunque, viene fatta sulla base del certificato digitale scambiato, oppure sulla base di una Pre-Shared Key PSK , una chiave simmetrica precedentemente negoziata da Alice e Bob, con la quale hanno deciso di farsi riconoscere. La PSK non è una password, è una chiave di cifratura.

Dal momento che le identità vengono scambiate all'interno di una connessione cifrata che permette perfect forward secrecy, le identità sia di Alice che di Bob sono protette da attacchi passivi, ma lo stesso non vale per gli attacchi attivi: infatti, se Trudy dovesse impersonale Bob, potrebbe accettare una connessione in ingresso da Alice: a questo punto, una volta derivata la IKE_SA, Alice manderebbe a Trudy la sua identità, permettendo così a Trudy di scoprire che Alice voleva comunicare con Bob. Al passo successivo, Trudy non sarà comunque in grado di mandare il certificato di Bob, quindi la connessione sarà chiusa, ma si tratta comunque di un problema: Trudy sa che Alice ha provato a contattare Bob.

Quando si negoziano i criptosistemi da utilizzare per cifrare i dati, bisogna essere furbi e non lasciarsi truffare. Ancora una volta, Trudy sta impersonando Bob. Trudy potrebbe decidere di utilizzare un criptosistema, all'interno delle proposte fatte da Alice, che sia facilmente crackabile. È quindi fondamentale, quando si negozia il criptosistema da utilizzare, non proporre algoritmi blandi per le proprie comunicazioni; un'implementazione furba, invece, potrebbe comunque proporli al destinatario: se questo accetta un algoritmo non sicuro, si può ipotizzare che il destinatario dei messaggi sia un attaccante e, quindi, chiudere ogni connessione; questa soluzione è sicuramente vantaggiosa, perché potenzialmente permette ad Alice di sospettare di Bob prima ancora che Bob riceva le credenziali di Alice.

Attacco Dos ad IKE

Ammettiamo che Trudy voglia far in modo che Bob non sia in grado di comunicare con la rete: questo può essere fatto con un attacco di tipo DoS. L'idea di base è che Trudy comincia a mandare a Bob una quantità notevole di pacchetti di apertura della connessione: Bob sarà costretto a calcolare e memorizzare un numero di parametri DH notevole.

Dal momento che il protocollo funziona su UDP, esistono dei timer che indicano quando una connessione deve essere considerata non più valida: questo da a Trudy un certo margine di tempo per sferrare il suo attacco nei confronti di Bob. Abbiamo Trudy che apre $N$ connessioni con Bob, magari facendo IP spoofing per non essere riconosciuta, mentre Bob è costretto a memorizzare nella sua RAM tutti i parametri DH ricevuti da Trudy e tutti quelli che lui stesso ha dovuto calcolare. Il risultato di questo attacco è che Bob finisce la sua memoria.

La soluzione a questo attacco è l'utilizzo di cookie: quando Bob si accorge che tutta una serie di connessioni rimane pendente, può andare in modalità di protezione e rispondere a tutte le connessioni entranti con la richiesta di rinnovare una seconda volta la connessione, inserendo nella richiesta un parametro, detto cookie:

$cookie=MDC(N_{A}|IP_{A}|SPI_{A}|segreto)$

In questa modalità, Bob non deve far altro che ricordare il segreto e, ogni volta che arriva una connessione, verificare la correttezza dell'MDC. Con questa tecnica, sarà Trudy a dover ripresentare $N$ connessioni memorizzando un numero $N$ di cookie e di parametri: Trudy finirà la sua memoria, mentre Bob continuerà a lavorare normalmente.

La soluzione trovata, però, non è sufficiente a contrastare attacchi DDos: se Trudy dispone di una botnet di calcolatori, ottenuta per esempio disseminando malware e virus su internet, per questa botnet distribuita sarà più facile ricordare i parametri delle connessioni e rispondere in maniera corretta alla richiesta del cookie. Con un attacco DDoS, infatti, tanti computer controllati da Trudy mandano a Bob un numero limitato e gestibile di richieste di connessione, quindi Bob sarà costretto ad accettare tutte le connessioni che rispondono correttamente alla richiesta di un cookie, col risultato che Bob finirà comunque la sua memoria.

Transport Layer Security

Il TLS è un insieme di protocolli di sicurezza che lavora, nello stack TCP/IP, sopra a TCP e UDP. TLS è in grado di fornire:

• autenticazione;
• integrità dei dati;
• confidenzialità.

L'idea è quella di creare un canale sicuro, che permetta la PFS attraverso delle chiavi effimere, sfruttando come sempre delle credenziali di lungo periodo per l'autenticazione, quali possono essere i certificati X.509, delle chiavi fornite dal KDC Kerberos oppure delle semplici pre-shared key. TLS ed SSL hanno una storia condivisa:

• nel 1995 la Netscape Inc pubblica il protocollo SSLv2, usato per proteggere le connessioni HTTP nel suo browser Netscape Navigator;
• nel 1997 viene pubblicato il protocollo SSLv3, un aggiornamento di SSL;
• nel 1999 la IETF standardizza il protocollo SSLv3 col nome di TLSv1, con l'aggiunta del supporto alle firme DSS e RSA;
• nel 2005 nascono gli standard TLSv1.1 e DTLSv1.0 (RFC 4346, RFC 4347 e RFC 4279).

Noi studieremo il TLSv1, che lavora soltanto con il protocollo TCP e che usa, come credenziali di lungo termine, chiavi DSS oppure RSA, cioè i certificati X.509; questa versione non supporta le PSK né il protocollo UDP.

Protocolli del TLS

Il protocollo TLS record offre gli stessi servizi del TCP, aggiungendo la sicurezza. All'interno dei suoi pacchetti possono essere veicolati sia dati che i messaggi del protocollo TLS:

• handshake protocol è protocollo deputato alla trasmissione di tutti i parametri e le impostazioni dei sistemi di cifratura; si occupa sia della negoziazione dei criptosistemi da usare, sia del calcolo delle chiavi, sia dell'autenticazione;
• Change CipherSpec, un singolo bit che segnala la fine delle trasmissioni dei dati in chiaro;
• Alert protocol, usato per segnalare condizioni di errore.

TLS handshake protocol

Se in IKE non si poteva parlare di client/server quanto piuttosto di un protocollo tra pari, con il TLS si possono invece individuare proprio un initiator Alice ed un responder, un server Bob. Sarà l'initiator a contattare il responder per instaurare una connessione TLS; tutti i protocolli di handshake sono trasportati all'interno dei pacchetti TLS record.

File:Sicurezza TLS setup connessione.png

Lo scopo di questo protocollo di handshake è l'autenticazione del server ad Alice ed, eventualmente, anche di Alice al server; oltre a questo, il TLS handshake si occupa di derivare la chiave principale $k_{ms}$ (Master Secret) e le chiavi delle singole connessioni.

Il primo messaggio per instaurare una connessione lo manda Alice, all'interno del quale vi sono la lista dei protocolli di cifratura che vuole usare ed un numero casuale $R_{A}$; a questo messaggio segue la risposta del server, all'interno del quale viene inserito il criptosistema scelto, un numero casuale $R_{B}$, il certificato di del server ed un numero, un session ID.

A questo punto, Alice può scegliere di autenticarsi a sua volta oppure no: se si vuole autenticare, manda il suo certificato digitale e la sua firma su tutti i messaggi precedenti; se invece non vuole autenticarsi, allora manda solo i campi obbligatori del protocollo, cioè la versione cifrata con la chiave pubblica di Bob del pre-shared master secret PMS e la versione cifrata, usando come chiave il PMS, dell'MCA dei pacchetti precedenti.

La risposta finale da parte del responder sarà la versione cifrata, con il PMS come chiave, dell'hash dei messaggi precedenti.

Una volta che questi messaggi sono stati scambiati ed accettati, tra i due calcolatori è instaurata una sessione TLS. L'autenticazione di Bob nei confronti di Alice è possibile grazie al fatto che Bob ha dimostrato di conoscere la $K_{ms}$, la chiave derivata dal pre-shared master secret; la $K_{ms}$ è lunga 384 bit.

Dalla chiave principale $K_{ms}$ possono essere derivate tutte le chiavi necessarie per instaurare un numero a piacere di connessioni TLS, usando chiavi secondarie diverse; è da notare che la PFS è opzionale, dipende da come viene derivata la chiave $K_{ms}$. Il traffico dell'utente sarà protetto da queste connessioni TLS, all'interno del protocollo record TLS.

L'autenticazione di Bob ad Alice avviene attraverso un certificato digitale; quando questo certificato viene mandato, viene anche mandata un insieme di certificati digitali di tutte le certification authority CA che potrebbero essere utili ad Alice per risalire ad una CA di cui si fida e, quindi, per fidarsi del certificato di Bob; allo stesso modo, se è richiesta l'autenticazione anche di Alice a Bob, quest'ultimo comunica, assieme alla richiesta di certificato, anche l'elenco delle CA ammesse, cioè di quelle CA di cui Bob si fida.

Quando è attiva una connessione tra Alice e Bob, allora è presente anche una $K_{ms}$: per questo motivo, quando è necessario aprire una nuova connessione, non serve ricavare una nuova $K{ms}$, si può semplicemente rinegoziare il criptosistema da usare e derivare delle nuove chiavi temporanee, sfruttando la sessione già esistente: questo può accadere quando si vuole iniziare una nuova connessione, ma anche quando si è usata troppo una chiave temporanea ed è giunto il momento di crearne una nuova, per non rischiare di esporre tutto il traffico alla crittanalisi.

Cifratura dei dati in TLS

Partiamo da un blocco di dati che arriva dal livello applicativo e deve essere trasmesso, tramite TLS, nella rete. Il primo passaggio da fare è quello di frammentare i dati in porzioni più piccole; opzionalmente, questi dati possono essere anche compressi.

Ai dati così ottenuti si applica una funzione di MAC e si invierà anche l'hash così ottenuto; infine, tutto viene cifrato con l'algoritmo scelto, viene aggiunto l'header TLS ed il pacchetto viene passato al protocollo TCP, che si occuperà di inoltrarlo ai livelli inferiori.

Nel caso in cui un algoritmo di cifratura preveda un vettore di inizializzazione dei dati, IV, allora questo sarà trasmesso all'inizio di ogni singola connessione; per tutti i pacchetti successivi al primo, invece, sarà usata la coda del pacchetto precedente come IV.

Al contrario di IKE e di SSLv3, all'interno dello standard TLS sono definiti i criptosistemi minimi che devono essere sempre implementati. Quello che accade è che Alice comunica al server l'elenco dei criptosistemi implementati, in ordine dal preferito al meno gradito: sarà il server a scegliere quello che preferisce, solitamente cercando di andare incontro alle preferenze di Alice.

All'interno dello standard TLS, sono presenti alcuni protocolli di cifratura obbligatori marchiati come exportable; fino al 2001, gli Stati Uniti d'America consideravano l'esportazione al di fuori del territorio americano degli algoritmi di cifratura al pari del traffico di armi da guerra. Questo atteggiamento ha fatto sì che per molto tempo l'NSA avesse il potere di decidere quali sistemi di cifratura potevano essere esportati e quali no. I protocolli esportati prima del 2001 sono detti exportable e prevedono delle chiavi talmente piccole, di soli 40 bit, che una ricerca esaustiva può essere fatta in pochi minuti. Quindi, quando si riceve la proposta di usare un criptosistema del tipo exportable, è meglio evitare di usarlo e sospettare del server che l'ha proposto.

Ad oggi, il TLS è il protocollo principe con cui vengono rese sicure le connessioni HTTP, e si può richiedere ai server che lo supportano inserendo nel browser, al posto di http://, il protocollo https://. Nella maggioranza delle situazioni, TLS prevede autenticazione soltanto del server verso il client, mentre le autenticazioni dei client verso i server sono fatte a livello applicativo, tipicamente attraverso delle password.

Il protocollo TLS, comunque, è usato per molte altre applicazioni, come per esempio creare dei tunnel cifrati (stunnel): il problema principale di questi tunnel, però, è il fatto che viene usato il protocollo TCP all'interno di un altro TCP. Questo fatto teoricamente non è un problema, ma accade che, quando si ha una piccola perdita di dati, che le finestre dei due TCP si chiudono rapidamente e non riescono più ad aprirsi, col risultato che il canale creato diventa rapidamente inutilizzabile.

Bisogna infine ricordare che, dal momento che il TLS si poggia sul TCP, soffre di tutti i problemi di cui soffre anche il TCP, come la sua esposizione agli attacchi DoS.

Collegamenti esterni

• RFC 2401 per IPSec (in inglese) (9/12/2008 verificato funzionante)
• RFC 2402 per IPSec/AH (in inglese) (9/12/2008 verificato funzionante)
• RFC 2406 per IPSec/ESP (in inglese) (9/12/2008 verificato funzionante)
• RFC 2407 per IKEv1,1 (in inglese) (9/12/2008 verificato funzionante)
• RFC 2408 per IKEv1,2 (in inglese) (9/12/2008 verificato funzionante)
• RFC 2409 per IKEv1,3 (in inglese) (9/12/2008 verificato funzionante)
• RFC 4279 per DTLSv1.0 e supporto con PSK (in inglese) (9/12/2008 verificato funzionante)
• RFC 4301 per IPSec (in inglese) (9/12/2008 verificato funzionante)
• RFC 4302 per IPSec/AH (in inglese) (9/12/2008 verificato funzionante)
• RFC 4303 per IPSec/ESP (in inglese) (9/12/2008 verificato funzionante)
• RFC 4306 per IKEv2 (in inglese) (9/12/2008 verificato funzionante)
• RFC 4346 per TLSv1.1 (in inglese) (9/12/2008 verificato funzionante)
• RFC 4347 per DTLSv1.0 (in inglese) (9/12/2008 verificato funzionante)