Scarica SSL: Architettura, Protocolli e Sicurezza e più Appunti in PDF di Reti Di Calcolatori solo su Docsity!
Sicurezza di rete
Molte soluzioni viste al livello applicativo offrono poche garanzie in termini di sicurezza, ad esempio HTTP Basic , in cui i messaggi scambiati sono tutti in chiaro. Questa ed altre soluzioni del genere vengono utilizzate nella pratica, poiché si assume che la sicurezza si delegata al canale sottostante: ci si appoggia sullo strato di rete per far sì che la sicurezza sia garantita. L’obiettivo sarà proprio di capire cosa gli strati sottostanti possono garantire in termini di sicurezza.
SSL/TLS
Questo protocollo opera sopra il livello trasporto, quindi dovrebbe essere considerato un protocollo di livello applicativo. Ricordiamo quali sono i compiti di un protocollo di livello trasporto: multiplexing verso le applicazioni, garanzia delle comunicazioni affidabili, la gestione della connessione, ecc... SSL non si occupa il multiplexing verso le applicazioni e non offre comunicazione affidabile, poiché utilizza TCP per garantire ciò. Verso l’alto offre le stesse caratteristiche di TCP e aggiunge ulteriori funzionalità. In pratica, se consideriamo lo stack TCP/IP, questo protocollo si colloca tra il livello trasporto e il livello applicazione ; può essere considerato un livello di trasporto “sicuro”. L’obiettivo primario di SSL è garantire al client sicurezza su chi è il server e sul fatto che nessuna terza parte sia in grado di accedere alle informazioni scambiate tra client e server ( quindi garantire confidenzialità e integrità ). Architettura di SSL SSL è organizzato su due livelli :
- Record Protocol : il protocollo che si occupa della gestione dei pacchetti.
- Parte di controllo : Handshake, Cipher Spec, SSL Alert.
In totale dunque SSL utilizza quattro differenti protocolli (uno + tre di livello applicazione). In seguito, vedremo come HTTP si relaziona con SSL. Essendo un protocollo che cerca di garantire confidenzialità e integrità, è di conseguenza orientato alle connessioni : si deve gestire la connessione tra le due parti, poiché ci saranno delle informazioni che vengono mantenute e che devono garantire che tutto lo scambio di informazioni non venga alterato. Rispetto a TCP, SSL ha bisogno di effettuare un cambiamento: in TCP abbiamo una connessione punto – punto abbastanza elementare. Riprendiamo un attimo il protocollo SCTP: esso offre il concetto di stream per gestire le connessioni contemporanee fra più endpoint. SSL si pone un problema analogo: abbiamo bisogno di fare in modo che ogni comunicazione fra due peer che fanno parte dello stesso blocco di comunicazione possa utilizzare le stesse informazioni (chiavi) in termini di sicurezza. Se così non fosse un browser ad esempio per parlare con il server dovrebbe aprire una connessione SSL per ogni connessione TCP (quindi una per testo, una per dati, una per la parte multimediale etc). Quindi aumenta la ridondanza. Poiché SSL non è leggerissimo, non è una scelta particolarmente opportuna. Dunque, come SCTP introduce il concetto di associazione , in SSL abbiamo il concetto di sessione e di connessione. La sessione è l’associazione tra client e server, creata dall’Handshake Protocol (corrisponde all’associazione in SCTP); le connessioni SSL sono quelle che hanno un rapporto 1: con le connessioni TCP. Sono comunicazioni temporanee, punto – punto e rappresentano il link di comunicazione tra le due parti e fanno riferimento ad una sessione SSL. In altre parole, creata la sessione SSL , al suo interno avremo tante connessioni SSL. Durante la fase di creazione della sessione SSL, avviene lo scambio delle chiavi, che poi verranno usate da tutte le connessioni che verranno aperte. Da tenere presente che la fase in cui viene creata la sessione è l’unica monitorabile dall’esterno (si vedono i messaggi di richiesta dell’handshake, ecc…, poiché vanno su connessione TCP base); tutti i messaggi successivi avranno il payload criptato, dunque non sarà possibile leggere i messaggi, oltre al fatto che non dovrebbe nemmeno essere possibile distinguere una connessione da un’altra. Record Protocol È quello che garantisce nella sostanza e nella pratica i requisiti di confidenzialità e integrità , tramite tecniche di criptazione e codici MAC. Non c’è una tecnica di criptazione predefinita, ma viene usato l’Handshake Protocol per stabilire l’algoritmo e i parametri da utilizzare (AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128). Altra caratteristica: tutti i messaggi spediti, vengono compressi prima di essere criptati. Questa caratteristica, oltre a diminuire l’overhead di rete, aumenta il livello di confidenzialità perché si passa da un plaintext ad un plaintext in cui i dati hanno una maggiore confusione interna quindi è più difficile recuperarne le proprietà statistiche. Per quanto riguarda l’integrità, usa i codici MAC , in particolare una versione adattata di H-MAC. Come avviene lo scambio di messaggi con il Record Protocol? Il pacchetto dati viene frammentato, il singolo frammento viene compresso, sul pacchetto compresso viene aggiunto il Message Autenticator Code (MAC); da notare che viene aggiunto sul dato compresso, non prima, quindi il MAC non viene compresso. Questo pacchetto viene criptato, e al pacchetto criptato viene aggiunto l’header SSL in chiaro. Quindi uno sniffing di questi pacchetti mostra solo l’header SSL, non il contenuto.
Handshake Protocol Obiettivo: coordinare i messaggi visti prima, effettuare autenticazione, scambiare le chiavi e far sì che il Record Protocol possa criptare e generare MAC in modo opportuno e tutti i messaggi di alert possano essere generati se qualcosa dovesse andare storto. Dobbiamo fare in modo che client e server si accordino sulle caratteristiche della comunicazione (che includono anche la scelta degli algoritmi adottati). Il protocollo ha la possibilità di autenticare sia client che server, ma l’autenticazione del client non è strettamente obbligatoria: è possibile usare SSL per autenticare una sola delle due parti coinvolte (server), l’altra è opzionale. L’handshake avviene in 4 fasi: Fase 1 Il primo messaggio scambiato parte dal lato client (client_hello) e il server risponde con un server_hello. Nel client hello ci sono tutte le informazioni necessarie per stabilire: Le security capabilities La versione del protocollo Le suite crittografiche L’id della sessione Il metodo di compressione I numeri random iniziali. Quindi si manda un messaggio con quello che si è in grado di fare. Il server risponde esattamente con le stesse informazioni, in modo che client e server sappiano entrambi le informazioni dell’altro. Attenzione: ci sono varie versioni di SSL e TLS e alcune hanno vulnerabilità: quando client e server
si scambiano i messaggi di hello, tra le altre cose viene scelta la versione del protocollo da utilizzare, e chiaramente si sceglie la versione più recente. Se però siamo utenti maliziosi, possiamo mandare prima un messaggio di client_hello per conoscere le suite supportate dal server, in seguito un altro in cui il client dichiara di supportare soltanto la suite peggiore tra quelle dichiarate dal server, in modo da obbligarlo a utilizzarla. Dualmente si può sfruttare questa tecnica lato server. In ogni caso, a seguito di questo scambio client e server si sono accordati sulle informazioni principali di riferimento. Fase 2 Notiamo subito una particolarità: essendo questo un handshake, dopo il messaggio di server_hello, dovrebbe essere il client a mandare il messaggio successivo, mentre come vediamo dalla figura è il server a mandare altri 4 messaggi. Questo avviene perché il server evita di occupare risorse, almeno inizialmente, scaricando il lavoro sul client, per cui gli invia tutte le informazioni di cui ha bisogno perché possa allocare le risorse necessarie. Fino al client_hello il server non fa nulla. (Il procedimento è analogo a quello che succede con SCTP). I dati che vengono scambiati in questa fase sono: Il certificato Le informazioni che servono per scambiare la chiave del server Una richiesta di certificato. La richiesta di certificato è opzionale perché è non è obbligatorio autenticare anche il client. L’operazione avviene utilizzando la crittografia asimmetrica : il certificato che il server invia è firmato con un MAC che è stato crittato con una chiave asimmetrica prodotta da una Certification Authority fidata che garantisce che all’indirizzo a cui ha acceduto il client c’è un server che è chi dichiara di essere. Il certificato contiene anche la chiave pubblica del server, la quale verrà poi utilizzata per decrittare i dati. Mandando questa serie di informazioni il server dice: “guarda questo è il mio certificato, quindi io sono… NOME SERVER”, dopodiché manda le informazioni dicendo: “Ok, questa è la base che ti serve per costruire la chiave comune e quindi fa un’operazione tipo Diffie-Hellman (in realtà usa RSA, per le prime versioni veniva usato Diffie-Hellman) per lo scambio della chiave di sessione. In realtà non è una chiave di sessione, ma una master-key (chiave con la quale poi generiamo tutte quante le altre chiavi), poi manda il messaggio finale in cui dice: “ora ti ho mandato tutto quello che ti serve”. Fase 3 Il client risponde mandando il suo certificato, le sue informazioni sulla chiave e la verifica del certificato precedentemente ricevuto. In realtà noi non inviamo nella maggior parte dei casi il certificato al server in quanto esso non ha l’obbligo di autenticarci (opzionale). Infatti, nei browser noi non facciamo mai autenticazione manuale, al massimo carichiamo la coppia (public-key, private-key) e il certificato nei file di configurazione del browser. Dunque, il client è sicuro che il server è chi dichiara di essere, il server invece non è garantito sull’identità del client. A prescindere da questo, tutti i messaggi da ora in poi saranno criptati quindi solo il client e il server possono utilizzarli. Fase 4 Fatto questo scambio, il client invia il messaggio change_cipher_spec, per cambiare la suite di cifratura, tutti i messaggi da adesso in poi sono criptati con le chiavi che abbiamo concordato. Il server risponde con lo stesso messaggio quindi tutti i messaggi che seguono verranno crittati con la chiave accordata.
Modifiche al livello applicativo Se modifico il protocollo al livello di trasporto, il livello applicazione se ne accorge, quindi dovrà supportare il nuovo protocollo sottostante (TLS in questo caso). In particolare, quello di cui ci occupiamo è HTTP, che dovrà essere reimplementato. In realtà non tutte le versioni di HTTP possono usare SSL: HTTP 1.0 ad esempio non supportava il “keep alive”: senza keep alive non c’è il concetto di connessione persistente, senza questo concetto non posso usare SSL. HTTP 1.1 invece supporta il “keep alive”, quindi ha la gestione delle connessioni, ma per un problema di compatibilità con il passato fa sì che si possa anche non specificare il keep alive, il che lo rende incompatibile. Quello che si usa è HTTPS, che ha un URL differente per specificare che si sta utilizzando SSL/TLS e qualche adattamento rispetto ad HTTP, come ad esempio l’obbligatorietà del keep alive. La porta di default di HTTPS è la 443. Analisi della sicurezza di un sistema SSL/TLS Configurare un sistema con SSL per garantire un certo livello di sicurezza non è una cosa così banale, esistono alcune best pratices che vengono utilizzate per indicare come quel sistema possa essere considerato sicuro o meno. Esistono dei test dedicati che verificano la sicurezza e la qualità del server SSL. Cosa fanno? Implementano l’handshake, recuperano tutte le informazioni (qualità del certificato, suite di crittografia utilizzate, versioni del protocollo supportate e se sono state applicate tutte le patch di sicurezza). Nota: in questo test fanno una scansione del server alla ricerca dei punti deboli (questo tipo di scansione è legale, poiché questi strumenti aprono una connessione SSL utilizzando dati pubblici; le scansioni di tipo IP scanning e Port scanning sono invece vietate, per cui possono essere usate su sistemi privati, chiusi e isolati, altrimenti bisogna chiedere il permesso prima di effettuarle su sistemi pubblici). Teniamo in considerazione un aspetto: non è detto che la scelta migliore sia sempre quella di usare le suite più recenti dei protocolli, soprattutto quando ad un sistema deve accedere un gran numero di utenti, poiché dal lato client potrebbero essere utilizzati browser che non supportano le ultime tecnologie; questo non è un problema da tenere più di tanto in considerazione se il sito non richiede particolari requisiti di sicurezza (informazioni critiche).
SSL Threat Model Quando studiamo un sistema dal punto di vista della sicurezza, oltre a capire l’architettura e come avviene lo scambio dei messaggi del protocollo, dobbiamo capire le minacce a cui è soggetto. Esistono dei sistemi di threat modeling che ci permettono di trovare le vulnerabilità dei protocolli. Negli RFC dei protocolli possiamo trovare un capitolo che descrive quali sono le minacce a cui essi sono soggetti (esempio HTTP che abbiamo visto in classe). Quindi tipicamente per ogni protocollo esistono dei threat model dedicati. Analizziamo una mind map di SSL Abbiamo al centro il threat model; da un lato trovo le componenti di utilizzo del sistema e quindi gli aspetti legati al protocollo, agli utenti e agli attacchi possibili. Nel protocollo ci possono essere: bug sull’implementazione (vanno risolti da codice) o problemi di sicurezza specifica (vanno affrontati con le versioni del protocollo). Sulle specifiche ci possono essere delle weakness (debolezze strutturali), o delle limitazioni sull’ambito di utilizzo del sistema (es. Non c’è protezione IP o sulle info dei certificati, è possibile fare il furto degli hostname). Si potrebbe attuare un downgrade attack, come abbiamo già discusso in precedenza: forzare il sistema ad utilizzare una versione più vecchia del protocollo. Quindi ci potrebbe essere un attacco in cui si sfrutta una versione sulla quale so che c’è un buco di sicurezza. Dal punto di vista degli utenti ho: utilizzabilità, attacchi DNS cache poisoning (vado a modificare i nomi: tu pensi di andare su www.unicampania.it ma in realtà io ho modificato la cache DNS e ti sto mandando su www.unicampaniatistofregando.it). Anche man in the middle. Si potrebbero fare attacchi in cui si sfruttano protocolli che non fanno autenticazione come ARP in cui sfrutto le tabelle ARP per forgiare indirizzi IP per dichiararsi agli indirizzi IP come membro della LAN in falso nome. Ci sono attacchi di route hijacking: vado a giocare su BGP per fare in modo che i percorsi di routing siano differenti; attacchi di phishing. Dall’altro lato abbiamo tutti gli aspetti legati al “trust”, di fiducia verso l’infrastruttura a chiave pubblica (CA): la sicurezza di SSL dipende dalla sicurezza dell’infrastruttura a chiave pubblica. Oltre a questo entra in gioco anche la sicurezza degli endpoint (client e server), che devono essere configurati correttamente (scambi di chiavi deboli, tecniche di cifratura non approvate).
