Vallarino Simone Corso di sicurezza A.A. 2003/2004 HTTPS
INTRODUZIONE Per cominciare a parlare di https è necessario aprire la discussione ricordando le caratteristiche dell http: HTTP Nel sistema telematico esiste il concetto base di comunicazione e quindi lo scambio di informazioni. Questo colloquio si deve appoggiare su delle regole che gestiscano lo scambio di dati, per questo si introduce un protocollo di trasmissione. Nel modello client-server il protocollo ha lo scopo di consentire ai due elementi di colloquiare "al meglio". L'HTTP (HyperText Transfer Protocol) è un modello di protocollo client-server. Una delle caratteristiche più interessanti di questo protocollo è il fatto di essere di tipo request/response: la connessione viene stabilita dal client e chiusa dal server. La richiesta inviata dal client comprende una intestazione e il corpo del messaggio (questo secondo lo standard MIME); il server, ricevuta la richiesta, provvede al recupero del documento e lo spedisce al client in risposta. Viene così chiusa la connessione. Invece per l HTTP 1.1 e una variante particolare dell HTTP 1.0 dopo la response la connessione non viene terminata e si procede con una nuova coppia request/response. Dal suo inizio http è stato usato in chiaro su internet, ma è noto che il protocollo TCP/IP consente di leggere ed alterare i dati che vengono inviati in rete.
http e https INTERNET HTTPS Canale cifrato (SSL/TLS) INTERNET L utilizzo di http per applicazioni sensibili (ad esempio il commercio elettronico che aveva iniziato a muovere i primi passi) ha fatto si che si richiedessero misure di sicurezza e quindi si ponesse l obiettivo di rendere sicure le connessioni. MOTIVAZIONI E NASCITA DI HTTPS Detto ciò si pongono le motivazioni di base per la nascita di HTTPS (Secure hyper-text transfer protocol): 1. Le informazioni scambiate tra 2 applicazioni su Internet passano per diverse organizzazioni, occorre un sistema per poter avere transazioni confidenziali. 2. Molti servizi richiedono il supporto di alcune importanti proprietà come: autenticazione e integrità dei dati 3. Occorre tener conto del concetto di non ripudiabilità dell originale.
Https è stato sviluppato da Netscape, e la sua prima implementazione pubblica è datata 1995 quando comparve in Netscape navigator 2 come http over ssl Da allora non sono stati pubblicati standard veri e propri ma l idea è rimasta inalterata fino a maggio del 2000 quando con l RFC2818 è stata decisa la sostituzione di SSL con TLS (una nuova versione dello stesso SSL). In ogni caso SSL è ancora impiegato. Occorre fare attenzione a non confondere https con S-http. Infatti s-http era una versione dell http accresciuta in sicurezza che era stata proposta come standard dall EIT (enterprise integrated technology) e che si poneva come alternativa all SSL che invece era stato lanciato da Netscape. La maggiore differenza tra s-http ed SSL sta nel fatto che s-http permette al client di spedire un certificato al fine di autenticare lo user, mentre usando SSL solo il server può essere autenticato. s-http alla luce di ciò, trova applicazione ad esempio in situazioni dove il server è rappresentato da una banca che richiede allo user una autenticazione più sicura di una semplice user-id e password. HTTPS = http + SSL/TLS Per rendere sicuro il protocollo http(hyper text transfer protocol) si rende utile l utilizzo di un altro protocollo: Dalla nascita di HTTPS si usava: SSL (Secure sockets layer) introdotto da Netscape a partire dal 1994 SSL è un protocollo di utilizzo comune per la gestione della sicurezza dei messaggi spediti via internet. SSl usa uno strato di programma che si trova tra l internet Hypertext Transfer Protocol (HTTP) e il Transport Control Protocol (TCP). SSL è incluso come parte di entrambi browser più conosciuti (Microsoft internet explorer e Netscape navigator) e della gran parte dei web server. Sviluppato da Netscape, SLL ha guadagnato in fretta anche il supporto di Microsoft e di altri sviluppatori di client/server internet ed è diventato di fatto uno standard fino all avvento del suo successore (TLS). La dicitura sockets nell acronimo SSL indica il metodo a socket di passaggio dei dati avanti e indietro attraverso un programma client e uno server in una rete o attraverso strati di programma sullo stesso computer. SSL usa il sistema di
cifrazione a chiave pubblica e privata sviluppato da RSA il quale prevede anche l utilizzo di certificati digitali X.509. Ora, dal 2000, si utilizza: TLS (Transport Layer Security) successore di SSL(basato su Netscape s SSL 3.0 protocol) nato nel 1999 ad opera dell IETF TLS è composto da due strati: il TLS record protocol ed il TLS handshake protocol. Il TLS record protocol garantisce la sicurezza con l utilizzo di alcune metodi come il DES (Data encryption standard).il TLS handshake protocol permette la al server ed al client di autenticarsi a vicenda e di negoziare un algoritmo di encryption ed una chiave crittografica da usare prima di scambiarsi i dati TLS ed SSL non sono compatibili, in ogni caso un messaggio spedito con TLS può essere capito anche da un client che gestisce SSL ma non TLS. Come abbiamo visto, si tratta di protocolli che garantiscono la privacy delle comunicazioni su Internet. Essi permettono infatti alle applicazioni client/server di comunicare in modo da prevenire le intrusioni, le manomissioni e le falsificazioni dei messaggi garantendo tre funzionalità fondamentali: Privatezza del collegamento. La crittografia è usata dopo un handshake iniziale per definire una chiave segreta. Per crittografare i dati è usata la crittografia simmetrica (e.g. DES, RC4, etc.). Autenticazione. L'identità nelle connessioni può essere autenticata usando la crittografia asimmetrica, o a chiave pubblica (per es. RSA,DSS, etc.). Così i clients sono sicuri di comunicare con il corretto server, prevenendo ogni interposizione. E' prevista la certificazione sia del server che del client. Affidabilità. Il livello di trasporto include un check dell'integrità del messaggio basato su un apposito MAC (Message Authentication Code) che utilizza funzioni hash sicure (e.g. SHA, MD5, etc.). In tal modo si verifica che i dati spediti tra client e server non siano stati alterati durante la trasmissione. Quindi l https non è altro che una implementazione del protocollo http con Ssl o tls Nella pila del protocollo TCP/IP viene introdotto un ulteriore livello che si colloca tra quello di applicazione e quello di trasporto
http SMTP FTP SSL o TLS TCP IP Concettualmente si usa HTTPS attraverso SSL/TLS come si fa con HTTP attraverso TCP. CONNESSIONE Inizio della connessione: Chi agisce come http client deve essere in grado di farlo anche come tls client e deve iniziare una connesione su una determinata porta e mandare il segnale TLS clienthello per iniziare il tls handshake. Quando il tls handshake è finito il client può iniziare a mandare la prima http request. Tutti i dati http devono essere inviati come tls application data. Per il resto vengono seguite le normali caratteristiche dell http. Chiusura della connessione: Tls fornisce una struttura per la chiusura di connessione sicura: Quando si riceve un valido segnale (alert) di chiusura sicuramente non si avranno ulteriori dati su quella connessione. Prima dell effettiva chiusura le implementazioni di TLS devono aver portato a termine uno scambio di alert di chiusura. In ogni caso una implementazione tls, dopo aver spedito un segnale di chiusura può anche non aspettare la sua corrispettiva generando così una chiusura incompleta con il vantaggio che può riutilizzare questa sessione. Questo dovrebbe essere fatto solo quando l applicazione sa di aver ricevuto tutti i messaggi di suo interesse (solitamente spulciando i limiti(boundaries) dei messaggi http). Inoltre è specificato anche che ogni implementazione che riceve un connection close senza prima aver ricevuto un close alert valido (premature close) non può riusare la sessione. Una chiusura prematura non indica la perdita della sicurezza dei dati ma soltanto che potrebbero essere troncati (dato che il tls non sa i limiti di request/response dell http è necessario andare a vedere gli stessi dati http per capire se il troncamento è avvenuto tra 2 messaggi o all interno di uno)
PORT NUMBER Il primo dato che un server http si aspetta di ricevere da un client è il request line production. Il primo dato che si aspetta di ricevere un server tls(e quindi anche un server http/tls) è il clienthello, quindi per distinguerli se vengono usati su una connessione TCP/IP HTTP server attende su porta 80 HTTP/TLS server attende su porta 443 Poiché https e http sono differenti protocolli ed usano porte diverse, lo stesso sistema server può far girare contemporaneamente entrambi i tipi di server FASE DI IDENTIFICAZIONE: ENDPOINT IDENTIFICATION Server identity: Solitamente le richieste attraverso http/tls sono generate differenziando una url Di conseguenza l hostname per il server è conosciuto al client. Se l hostname è disponibile il client deve controllarlo rispetto all identità del server presentata nel server certificate message al fine di prevenire attacchi del tipo man in the middle. Se il client ha informazione esterne sulla supposta identità del client il controllo dell hostname può essere omesso (per esempio potrebbe connettersi con una macchina il cui indirizzo e hostname sono dinamici ma il client riconosce il certificato che il server gli presenta). In questi casi è importante restringere il dominio dei certificati accettabili il più possibile sempre al fine di prevenire attacchi del tipo man in the middle. Il controllo viene fatto applicando le regole descritte nell rfc2459. Se più di una identità di un dato tipo è stata presentata nel certificato una corrispondindenza in almeno 1 caso è ritenuta accettabile. I nomi possono contenere la wildcard * che è considerata corrispondente ad ogni singolo componente del nome di dominio ( esempio *.a.com corrisponde a foo.a.com ma non a bar.foo.a.com e f*.com corrisponde a foo.com ma non a bar.com). In alcuni casi la url è specificata come un ip address invece di un host name. In questi casi l ip address subjectaltname deve essere presentato nel certificato e deve corrispondere esattamente all ip nella url. Se così non fosse il client dell user deve renderlo noto all utente (gli verrà proposta una scelta tra continuare ugualmente o uscire con un errore di bad certificate). Si noti che in molti casi la url stessa può essere non verificata. I controlli fin qui descritti non forniscono una protezione contro attacchi dovuti al fatto che questa sorgente sia compromessa. Per esempio se la url fosse ottenuta ciccando su una pagina ottenuta non usando http/tls un man in the middle può aver rimpiazzato la url. Al fine di prevenire ciò gli users dovrebbero
esaminare attentamente il certificato presentato dal server al fine di determinare se è come se l aspettano. Client identity: tipicamente il server non ha non ha conoscenza esterne sull identità del client, così i controlli non sono possibili. Se invece il server fosse in grado di avere queste conoscenze (ad esempio attraverso qualche sorgente esterna ad http e tls) è tenuto a controllare l identita come descritto sopra. L identificazione del cliente non era supportata con i primi SSL ora lo è (era la differenza fondamentale con l S-HTTP). FORMATO DELL URI E COMPORTAMENTO DEL BROWSER Il formato dell URI(universal resource identifier): si differenzia dal normale uso di http per l uso di https: ad esempio https://webmail.unige.it Vediamo il comportamento del browser ad una richiesta HTTPS, cioè all entrata in trasmissione sicura: Questo avviso ci annuncia l entrata in modalità sicura
Confermata successivamente dal simbolo del lucchetto in fondo alla finestra del browser(a destra Netscape, a sinistra internet explorer) È anche possibile visualizzare le informazione relative al certificato che testimonia l identità del computer remoto.
Il certificato è emesso da una CA (certification autority) e contiene tutte le informazioni (nome, numero seriale, data di scadenza, una copia della chiave pubblica del proprietario) ESEMPI DI ATTACCHI Substitution attack E un attacco abbastanza semplice ma è possibile solo se l attaccante ha la possibilità di sostituire la pagina. Ad esempio: Il riferimento a https://amazone.com viene rimpiazzato con https://amaz0ne.com In html:
<html> <a href=https://amaz0ne.com> Click here to go to https://amazone.com </a> </html> Quando l user clicca sul link la richiesta viene spedita per: https://amaz0ne.com Il certificato corrisponde con l host richiesto, che l attaccante ha inserito, ed il gioco è fatto con l attaccante che ottiene le informazioni sull utente. Referrer attack Nello standard http Il campo referrer header contiene l url della pagina che l utente stava visualizzando quando ha cliccato sul link per la pagina corrente Nelle form che utilizzano il metodo GET gli argomenti sono concatenati all URL: es:www.ebay.com/confirm.htm?visa=123&item=7 Gli argomenti sono passati dopo il simbolo? Quando l utente cliccherà sulla pagina aperta dal form submission questa stringa apparirà nel referrer header in richiesta alla nuova pagina. Gli argomenti vengono passati nel referrer header quindi: Se la nuova pagina fosse HTTP ssarebbero passati in chiaro!!! Se anche fosse HTTPS ma di un altro sito gli argomenti passati al primo sito saranno noti anche al secondo La soluzione sta nell usare il metodo POST nei form in quanto, al contrario di GET passa gli argomenti nel body della richiesta e così facendo non sono resi visibili. CONSIDERAZIONI FINALI HTTPS è un protocollo che si basa su concetti sostanzialmente semplici, ben funzionanti e collaudati. Basti pensare alla diffusione dell http che con la nascita delle applicazioni web sensibili ha fatto sì che HTTPS divenisse di fatto uno standard per applicazioni di online shopping, banking ecc. Occorre tuttavia attenzione da parte dell utente (vedi attacchi tipo substitution) e da chi progetta servizi web (vedi attacchi tipo referrer)
Un difetto ovvio conseguente all uso di https sono le prestazioni (intese come velocità nella trasmissione) che sono inferiori al normale http. Ma questo rappresenta un prezzo da pagare molto basso rispetto ai benefici che si ottengono.