La Crittografia nell’ambito del protocollo HTTP Classe: V istituto professionale (gestione aziendale) Obiettivo 1: Generazione di competenze e preparazione su argomenti attuali da spendere anche nel mondo del lavoro nell’immediato, nella gestione aziendale o per eventuale proseguimento studi Obiettivo 2: Creazione di stimoli esterni in ambito pratico che incuriosiscano e motivino in maniera più elevata gli alunni in informatica e in tutti i campi del mondo reale Prerequisiti: Algoritmi e Reti di computer

Chiave Asimmetrica

Simmetrica & Asimmetrica

Pericoli esterni

Emissione certificato

HTTP e sicurezza il protocollo HTTP è estremamente insicuro in quanto trasmette i dati “in chiaro” Per quanto concerne confidenzialità e integrità dei dati, due sono i protocolli di sicurezza di maggiore impiego: → SSL (Secure Socket Layer) : messo a punto da Netscape nel 1994, si pone come strato intermedio tra il transport layer (TCP/UDP) e l’application layer (FTP, Telnet, HTTP, SMTP) del protocollo TCP/IP garantendo un canale di comunicazione sicuro. → S-HTTP (Secure HTTP): lavora a livello applicativo e in particolare estende il protocollo HTTP mediante la definizione di attributi di sicurezza.

SSL e porte logiche dedicate E’ semplice verificare se la sessione è sicura, in quanto l’URL del sito cambia da http in https (es. e in un punto dello schermo appare un lucchettino

Handshake connessione protetta SSL 1. Client Hello: il client invia al server alcuni random byte e comunica la scelta di un algoritmo a chiave privata per lo scambio dei messaggi, di un algoritmo a chiave pubblica per lo scambio delle chiavi di sessione e di un algoritmo di hashing. 2. Server Hello: il server invia al client il proprio server certificate, altri random byte e fornisce il proprio acknowledgment ai protocolli scelti dal client. Il server termina la propria sessione inviando al client un session identifier, utilizzabile in ogni altra sessione per evitare ulteriori handshaking che rallenterebbero le performance del sistema. 3. Certificate request: il server chiede che il client presenti un valido client certificate. 4. Client certificate: il client invia al server il proprio certificato. 5. Client key exchange: il client verifica il server certificate inviatogli dal server; a questo punto il server è autenticato. Genera poi un pre-master secret che, assieme i random byte, sarà usato come "chiave generatrice" di una coppia di chiavi simmetriche e lo crittografa con la server public key contenuta nel public server certificate; il tutto è inviato al server.

Handshake connessione protetta SSL 6. Server verifier: il server decrittografa il pre-master secret inviatogli con la propria server private key, calcola il master secret e genera la coppia di chiavi simmetriche di sessione (lato server). 7. Client finished: il client invia al server una checksum costruita crittografando, con la client- write-key, l’hash calcolato dall'unione dei precedenti messaggi con la chiave generatrice (il master secret). 8. Server finished: ricevuti tutti i dati dal client, il server verifica che l'hash di controllo inviato dal client sia corretto ed invia al client il proprio hash di controllo costruito in modo simile (ma non identico). 9. Start communication sessions: una volta verificato anche quest'ultimo hash, ogni ulteriore sessione client-server potrà essere instaurata utilizzando le chiavi di sessione e i relativi algoritmi di crittografia simmetrici (più veloci di quelli asimmetrici) precedentemente definiti.

Esercitazione pratica ai PC di Laboratorio

Raccomandazioni conclusive Quando si lascia l'area di sicurezza di un sito appare una finestra di dialogo che ci avvisa che si sta abbandonando una connessione protetta. Altra cautela va tenuta quando, pur entrando in un sito di cui si può anche conoscere l’origine, si riceve il seguente avviso andando nella zona protetta (certificato non attendibile). Le informazioni che fornisce il Browser si spiegano da sole, basta leggere!