Sicurezza 2003/2004 Simone Vallarino HTTPS Sicurezza 2003/2004 Simone Vallarino

Sommario Introduzione Che cos’è Perché è nato e chi l’ha creato HTTPS = HTTP+SSL/TLS Connessione (HTTP over TLS) Fase di identificazione (HTTP over TLS) Formato dell’URL e comportamento del browser Esempi di attacchi a HTTPS Considerazioni finali

Introduzione Abbiamo già visto: HTTP (Hyper text transfer protocol) Ricordiamo: Protocollo di trasmissione client-server di tipo request/response basato su: TCP-IP (Transmission Control Protocol)

Che cos’è HTTPS Secure Hyper Text Transfer Protocol Come l’HTTP ma… Sicuro! Perché le informazioni che viaggiano su internet passano attraverso un canale cifrato

Che cos’è

Perché è nato e chi l’ha creato Successo dell’HTTP che era però usato in chiaro su internet (limitativo !) Utilizzo di internet per applicazioni sensibili (commercio elettronico, banche, aziende,ecc.)

Perché è nato e chi l’ ha creato Quindi… Precisiamo le motivazioni base: Le informazioni scambiate tra 2 applicazioni su Internet passano per diverse organizzazioni, occorre un sistema per poter avere transazioni confidenziali. Molti servizi richiedono il supporto di alcune importanti proprietà come: autenticazione e integrità dei dati Occorre tener conto del concetto di “non ripudiabilità” dell’originale

Perché è nato e chi l’ ha creato Sviluppato da Netscape La prima implementazione pubblica nata come HTTP over SSL era in Netscape Navigator 2 nel 1995 Non sono stati pubblicati standard veri e propri Praticamente inalterato fino all’RFC2818 (maggio 2000) con la sostituzione di SSL con il più evoluto TLS Da non confondersi con S-HTTP ! S-HTTP è una speciale versione di HTTP accresciuta in sicurezza proposta come standard dall’EIT (Enterprise Integrated Technology). Si poneva come alternativa a SSL.

HTTPS = HTTP + SSL/TLS Per rendere sicuro il protocollo http(hyper text transfer protocol) si rende utile l’utilizzo di un altro protocollo : Prima: SSL (Secure socket layer) introdotto da Netscape a partire dal 1994 come protocollo di gestione della sicurezza dei messaggi che transitano in internet Ora: TLS (Transport Layer Security) successore di SSL (basto sulla versione 3.0) nato nel 1999 ad opera dell’IETF

HTTPS = HTTP + SSL/TLS Ricordiamo: TLS/SSL si tratta di protocolli che garantiscono la privacy delle comunicazioni su Internet Creati per prevenire le intrusioni, le manomissioni e le falsificazioni dei messaggi

HTTPS = HTTP + SSL/TLS tre funzionalità fondamentali: Privatezza del collegamento: La crittografia (simmetrica). è usata dopo un handshake iniziale per definire una chiave segreta. Autenticazione: L'identità nelle connessioni può essere autenticata, così i client sono sicuri di comunicare con il corretto server, prevenendo ogni interposizione (uso di crittografia asimmetrica, o a chiave pubblica). Affidabilità: si verifica che i dati spediti tra client e server non siano stati alterati durante la trasmissione (check basato su MAC e utilizzo funzioni Hash)

HTTPS = HTTP + SSL/TLS Quindi: HTTPS = HTTP + SSL/TLS Posizionamentro all’interno della “pila” del protocollo TCP/IP: viene introdotto un ulteriore livello che si colloca tra quello di applicazione e quello di trasporto Concettualmente: uso HTTPS attraverso SSL/TLS come si fa con HTTP attraverso TCP. HTTP SMTP FTP SSL o TLS TCP IP

HTTPS = HTTP + SSL/TLS il canale sicuro di cui parlavano è rappresentato da SSL/TLS

Connessione Inizio della connessione: Chi agisce da HTTP client deve anche essere in grado di agire come TLS client La connessione inizia su una determinata porta con il segnale SSL/TLS ClientHello Segue il SSL/TLS handshake Tutti i dati http devono essere inviati come SSL/TLS “application data”. Non viene spedito nessun dato riguardante il client finchè la connessione SSL/TLS non è attiva Per il resto vengono seguite le normali caratteristiche dell’HTTP

Connessione 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. Chiusura normale: le implementazioni di TLS devono aver portato a termine uno scambio di alert di chiusura prima dell’effettiva chiusura Incomplete close: 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 Premature close : Un’implementazione che riceve un connection close senza prima aver ricevuto un close alert valido non può riusare la sessione. Non indica la perdita della sicurezza dei dati ma soltanto che potrebbero essere troncati

Connessione Client hello Server hello Server Certificate serverHelloDone Handshake ClientKeyExchange E(Kserv, PK) ChangeCipherSpec FIN Handshake (MAC) ChangeCipherSpec FIN Handshake (MAC)

Connessione Application_data http request Application_data http response Alert : close_notify Close Alert : close_notify

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

Fase di identificazione Vengono confrontati i nomi nel certificato con l’hostname E’ concesso l’uso di wildcard (*) Se l’hostname non corrisponde con il nome nel certificato il client è tenuto a lasciare la scelta all’utente se continuare o meno Si noti che in molti casi l’URI stesso proviene da una sorgente non verificata. L’identificazione descritta non provvede protezione contro attacchi dovuti al fatto che questa sia compromessa.

Fase di identificazione Client identity tipicamente si sceglie di non autenticare i “clienti”. Se si sceglie di farlo si utilizzano dati esterni (ad es. il numero della carta di credito o la password) L’identificazione del cliente non era supportata con i primi SSL ora lo è (era la differenza fondamentale con l’S-HTTP).

Formato dell’URI Il formato dell’URl: si differenzia dal normale uso di http per l’uso di https: Sintassi: https://host [:port]/path [#fragment][?query] ad esempio: https://webmail.unige.it Indica che ci vogliamo/dobbiamo collegare in maniera sicura

Comportamento del browser All’entrata in modalità sicura il browser ci avverte con un messaggio Confermato successivamente (di solito) da un simbolo (lucchetto a dx su netscape, a sx su IE)

Comportamento del browser E’ anche possibile visualizzare una finestra con le informazioni relative al certificato che stabilisce delle credenziali sul web (solitamente cliccando sul lucchetto) 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)

Comportamento del browser

Comportamento del browser

Esempi di attacchi Substitution attack Possibile se l’attaccante ha la possibilità di sostituire la pagina 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…

Esempi di attacchi Referrer attack Il 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 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: Se la nuova pagina è HTTP sono passati in chiaro !!! Se anche fosse HTTPS ma di un altro sito gli argomenti passati al primo sito saranno noti anche al secondo Soluzione: usare il metodo POST nei form in quanto, al contrario di GET passa gli argomenti nel body della richiesta

Considerazioni finali HTTPS è sostanzialmente semplice e ben funzionante Ha trovato uso comune nelle applicazioni web (online shop 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: le prestazioni (intese come velocità “nel tempo”) sono inferiori al normale HTTP