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

ConnessioneInizio 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

ConnessioneChiusura 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 helloClient hello

Server helloServer hello

Server CertificateServer Certificate

serverHelloDone serverHelloDone

ClientKeyExchange E(Kserv, PK)ClientKeyExchange E(Kserv, PK)

ChangeCipherSpec ChangeCipherSpec

FIN Handshake (MAC) FIN Handshake (MAC) ChangeCipherSpecChangeCipherSpec

FIN Handshake (MAC) FIN Handshake (MAC)

Handshake

Connessione

Application_data http request Application_data http request Application_data http responseApplication_data http response

Alert : close_notify Alert : close_notify Alert : close_notify Alert : close_notify

Data

Close

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/IPHTTP server attende su porta 80HTTP/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 identificazioneEndpoint 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