Intro to SSL/TLS

1. Intro to SSL/TLS Network Security Gene Itkis

2. Sicurezza in rete • Sicurezza a livello applicativo • Pros: concepita ad hoc per le applicazioni • Cons: richiede l’utilizzo di più meccanismi • Sicurezza a livello trasporto • Pros: fornisce interfacce comuni a tutti i servizi applicativi • Cons: richiede piccole modifiche alle applicazioni • Sicurezza a livello rete • Pros: funziona con applicazioni che non si curano affatto della sicurezza • Consente di attraversare in modo sicuro domini non sicuri • Cons: può richiedere modifiche a livello Sistema Operativo

3. Meccanismi di sicurezza • Network levevel • IPSec • Transport levevel • SSL (Secure Socket Layer) • Application levevel • S/MIME • PGP • Kerberos • SET

5. Modelli di sicurezza (1) • Ci sono due modi per fornire un trasporto sicuro (cioè non intercettabile da orecchie maliziose durante la trasmissione): • Usare un'infrastruttura di trasporto sicura • Il protocollo non cambia, ma ogni pacchetto trasmesso nello scambio di informazioni viene gestito in maniera sicura dal protocollo di trasporto • Usare un protocollo sicuro a livello applicazione • Si usa un protocollo anche diverso, che si occupa di gestire la trasmissione delle informazioni.

6. Modelli di sicurezza (2) • HTTPS (RFC 2818) • Introdotto da Netscape, trasmette i dati in HTTP semplice su un protocollo di trasporto (SSL) che crittografa tutti i pacchetti. • Il server ascolta su una porta diversa (per default la porta 443), e si usa uno schema di URI diverso (introdotto da https://) • S-HTTP (RFC 2660) • Poco diffuso, incapsula richieste e risposte HTTP in un messaggio crittografato secondo o un formato MIME apposito (MIME Object Security Services, MOSS), o un formato terzo (Cryptographic Message Syntax, CMS). • E' più efficiente ma più complesso.

7. Protocollo SSL • Garantisce • Privatezza della comunicazione • Cifratura a chiave simmetrica • Autenticazione Server • Utilizzo di certificati digitali per scambio di chiavi • (opzionale) Autenticazione Client • Integrità dei dati ( Mac dei record SSL )

8. Architecture Application (HTTP) SSL TCP IP

9. History • 1993 – Mosaic (“browser #1”) • 1994 – Netscape Browser released • SSL v1 design complete – never released • SSL v2 released in Navigator 1.1 • Badly broken (bad seeds for PRNG) • 1995 – Explorer released • PCT (MS), SSL v3 (Netscape) • 1996-1999 – TLS 1.0 • 1999 – WTLS

10. SSL choices • Connection-oriented • SSL, TLS do not support UDP • But WTLS does • No non-repudiation • But signatures are used for AKE • “Only protects the pipe” • Attacks are mounted on data before and after “the pipe”

11. OpenSSL • Software crittografico open source, basato sulla libreria SSLeay sviluppata da Eric A. Young e Tim J. Hudson • Inizialmente (23/12/98) destinata alla diffusione come libreria per l’implementazione dei protocolli SSL e TLS, negli anni è stata integrata con funzionalità crittografiche avanzate che la rendono la più diffusa e utilizzata in ambito open souce ( e non…) per strumenti di firma, cifratura dati e comunicazioni sicure • Disponibile sulla maggior parte delle piattaforme Unix proprietarie e open source (Linux, OpenBSD ecc…), nonché sui sistemi Microsoft

12. Alternative architectures • Separate Layer • Over TCP: SSL • Over IP: IPSec • Application-Specific • SHTTP • Parallel • Kerberos; Kerberos with TLS?

13. Protocollo SSL • Presentato nel 1994 da Netscape Communication Corporation che successivamente rilasciò nel 1996 la v3. • SSL introduce un ulteriore livello nell'architettura ISO/OSI che si colloca tra il livello Applicazione e quello Trasporto • Una variante, seppur minima, del protocollo è divenuta standard con il nome TLS (RFC 2246)

14. Protocollo SSL Garantisce: • Privatezza della comunicazione • Cifratura a chiave simmetrica • Autenticazione Server • Utilizzo di certificati digitali per scambio di chiavi • (opzionale) Autenticazione Client • Integrità dei dati ( Mac dei record SSL )

15. TLS/SSL in dettaglio • E’ un protocollo di livello 5 (sessione) che opera quindi al di sopra del livello di trasporto • E’ composto da due livelli: • TLS Record Protocol: opera a livello più basso, direttamente al di sopra di un protocollo di trasporto affidabile come il TCP • E’ utilizzato per incapsulare (offrendo servizi di sicurezza) protocolli del livello superiore, tra cui l’Handshake Protocol • TLS Handshake Protocol: si occupa della fase di negoziazione in cui si autentica l’interlocutore e si stabiliscono le chiavi segrete condivise

16. Handshake Protocol Change Cipher Spec Alert Protocol TLS Record Protocol TLS: Architecture • TLS definisce il Record Protocol per trasferire I dati dell’applicazione e del TLS • La sessione viene stabilita utilizzando l’Handshake Protocol

17. Example: I want to book and buy a ticket on line. Standard way to access a Web site via non-secure connection. If anyone ever checked, the site business identity cannot be verified. No lock symbol means no security and no encryption.No one knows to click here.

18. OK, I’m ready to purchase and give my credit card – to United right? It really is United right? Click-1 shows that this certificate was issued to www.itn.net. Who is this? And what do they have to do with United Airlines? Click on the “Details” tab to dig deeper. Lock symbol appears because I am about to enter credit card info but unbeknownst to most everyone, it is clickable

19. You have to dig really deeply into crypto-arcanery to get to the identity information such as it is. Click-2 gives access to the contents of the server’s digital certificate. The site business identity is still not available. Click on the “Subject” field to dig deeper.

20. We learn the hard way that this is actually not United at all. The Web pages still say United and yet its not United. How often is that going on? A lot! Finally, after 3 clicks, the authenticated identity of the site business owner is available. It is right after the ‘O = ‘ and in this case it is GetThere.com, Inc. Intuitive and accessible… NOT. Really usable identity information…NOT. AND IT IS NOT EVEN UNITED AIRLINES THAT I AM ABOUT TO GIVE MY CREDIT CARD TO.

21. TLS: Overview • Viene stabilita una sessione • Accordo sugli algoritmi • Calcolo del segreto comune • Autenticazione • Vengono trasferiti i dati dell’applicazione • Viene garantita privacy e integrità

22. A B Message $%&#!@ Message TLS: Privacy • Cifra il messaggio così da non poter essere letto da terzi • Usa la convenzionale crittografia a chiave segreta • DES, 3DES • RC2, RC4 • IDEA

23. TLS:Key Exchange • Occorrono metodi sicuri per scambiare la chiave segreta • Si usa la crittografia a chiave pubblica • “key pair” is used - either one can encrypt and then the other can decrypt • slower than conventional cryptography • share one key, keep the other private • Le scelte sono RSA o Diffie-Helmann

24. TLS: Integrity • Vengono calcolati Message Authentication Code (MAC) a lunghezza fissa • Include l’hash del messaggio • Include un segreto condiviso • Include un numero di sequenza • Il MAC viene trasmesso assieme al messaggio

25. A B Message Message’ MAC =? MAC MAC’ TLS: Integrity • Il destinatario ricalcola il MAC • deve essere identico al MAC trasmesso MAC • TLS utilizza sia MD5 che SHA-1

26. A B Certificate Certificate TLS: Authentication • Verifica l’identità dei partecipanti • L’autenticazione del Client e opzionale • I certificati sono utilizzati per associare la chiave, o altri attributi al proprietario

27. Possibile autenticazione di U • Se richiesto U può autenticarsi mediante invio del suo certificato. • In pratica: Il sistema dispone di certificati mentre gli utenti di solito no. • Quando richiesto per autenticare U si procede con login e password.

28. TLS: Record Protocol

29. TLS Record Protocol • Riceve i dati dal livello superiore, li suddivide in blocchi, eventualmente li comprime, calcola il MAC, cifra il tutto e trasmette il risultato dell’elaborazione • Tipi di dati consegnati al Record Protocol: “handshake protocol”, “alert protocol”, “change cipher spec protocol” e “application protocol” • Il Record Protocol opera sempre all’interno di uno stato, che definisce gli algoritmi di compressione, cifratura e autenticazione e i parametri relativi (come le chiavi) • Vengono mantenuti 4 stati: gli stati di lettura (per i record ricevuti) e scrittura (per l’invio dei record) correnti e gli stati di lettura e scrittura pendenti

30. TLS Record Protocol • Una volta che i parametri di sicurezza sono stati settati e le chiavi generate, gli stati della connessione possono essere istanziati rendendoli correnti • Gli stati correnti devono essere aggiornati per ogni record elaborato e includono i seguenti elementi: • stato della compressione (stato corrente dell'algoritmo di compressione) • stato della cifratura (comprende la chiave e altre informazioni necessarie a definire lo stato dell'algoritmo, per esempio l'ultimo blocco nel caso di un cifrario a blocco in modalità CBC) • MAC secret • numero di sequenza: valore incrementato dopo ogni record

31. TLS Record Protocol I parametri di sicurezza definiti per uno stato sono settati fornendo i seguenti valori: • connection end: specifica se l’entità in questione è il client o il server • bulk encryption algorithm: indica l’algoritmo di cifratura e i relativi parametri, come la lunghezza della chiave • MAC algorithm: indica l’algoritmo di autenticazione ed i parametri relativi • compression algorithm: indica l’algoritmo di compressione e i relativi parametri • master secret: sequenza di 48 byte condivisa tra i due interlocutori • client random: 32 byte casuali forniti dal client • server random: 32 byte casuali forniti dal server

32. Handshake Protocol • E’ costituito da tre sotto-protocolli (“change cipher spec”, “alert” e “handshake”) che permettono ai due interlocutori di negoziare i parametri di sicurezza e notificare condizioni di errore • E’ responsabile della negoziazione di una sessione, che è costituita dai seguenti parametri: • session identifer: identificatore della sessione scelto dal server • peer certificate: certificato X.509 dell'interlocutore -- può mancare • compression method: algoritmo di compressione • cipher spec: algoritmi di cifratura e autenticazione e relativi parametri crittografici • master secret • is resumable: flag che indica se la sessione può essere utilizzata per iniziare nuove connessioni

33. MAC in SSL record • Ogni blocco viene numerato e autenticato con MAC. • MAC= H(blocco, numero, K, stringhe note) • numero = 64 bit. No ripetizioni all’interno della stessa sessione !!! • Si previene così facendo l’uso fraudolento e iterato dello stesso blocco nella stessa sessione • Se un blocco viene perduto i blocchi successivi vanno ricreati e rispediti. • MAC sono cifrati insieme al messaggio con chiave simmetrica.

34. TLS: Handshake • Negoziazione del Cipher-Suite Algorithms • Symmetric cipher to use • Key exchange method • Message digest function • Calcola e condivide il master secret • Opzionalmente consente di autenticare server e/o client

35. Handshake Phases • Messaggi di Hello • Messaggi per lo scambio di Certificati and Chiavi • Messaggi di Change CipherSpec e Finished

36. Client ClientHello Server ServerHello Certificate ServerKeyExchange TLS: ServerKeyExchange

37. TLS: Hello • Client “Hello” – inizia la sessione • Propone la versione del protocollo • Propone la cipher suite • Il Server sceglie protocol e suite • Il Client può richiedere l’uso di cached sessions • Il Server sceglie se accordare la richiesta

38. Server hello • S riceve il msg (client hello) da U • S seleziona un algoritmo di compressione tra quelli elencati da U. • S seleziona dalla cipher suite inviata da U una cipher suite comune (tra U e S). • S invia a U un msg (server hello) contenente gli elementi selezionati e una nuova sequenza di byte casuali. • Se U non riceve il msg server hello interrompe la comunicazione.

39. TLS: Key Exchange • Il Server invia un certificato contenente la chiave publlica (RSA) o i parametri Diffie-Hellman • Il Client invia il “pre-master” secret cifrato al server usando il messaggio Client Key Exchange • Viene calcolato il Master secret • Si usano i valori random usati nei messaggi Client and Server Hello

40. Costruzione del master secret • U costruisce un pre-master secret P (nuova sequenza di byte casuali) • U spedisce P a S dopo averlo cifrato con la chiave pubblica di S contenuta nel certificato e l’algoritmo concordato. • U combina P con alcune stringhe note + byte casuali contenuti in client hello e server hello e codifica il tutto con SHA e MD5 ottenendo il master secret M.

41. A cosa serve M ? • S e U utilizzano M per generare le chiavi (sia per il cifrario simmetrico sia per le funzioni MAC) e per altri scopi... • Nota: Le chiavi utilizzate da S e U sono diverse ma note ad entrambi. Ciò rende il protocollo ancora più sicuro.

42. Client ClientHello Server ServerHello Certificate ServerKeyExchange CertificateRequest TLS: Certificate Request

43. Client ClientHello ClientCertificate ClientKeyExchange Server ServerHello Certificate ServerKeyExchange CertificateRequest TLS: Client Certificate

44. Come vengono usati i certificati • I certificati consentono ai Web server ed ai client l’autenticazione prima di stabilire una connessione per mezzo delle chiavi pubbliche • I certificati sono parte del protocollo SSL per l’utilizzo di connessioni sicure: per sfruttare connessioni SSL un Web server deve ottenere ed installare un certificato • I certificati possono essere essere adottati sia dal client che dal server solo con SSL 3.0

45. Public Key Certificates • X.509 Certificate associano le chiavi all’identità deio possessori • Certification Authority (CA) crea il certificato • Rispetta le politiche e verifica le identità • Firma i certificati • L’utente deve verificare che il Certificato sia valido

46. Validare un Certificate • Bisogna riconoscere la CA fidata nella certificate chain • Ogni CA può essere certificata da un’altra CA • Occorre verificare che il certificato non sia stato revocato • La CA pubblica la Certificate Revocation List (CRL)

47. Version Serial Number Signature Algorithm Identifier Object Identifier (OID) e.g. id-dsa: {iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 1} Issuer (CA) X.500 name Validity Period (Start,End) Subject X.500 name Subject Public Key Algorithm Value Issuer Unique Id (Version 2 ,3) Subject Unique Id (Version 2,3) Extensions (version 3) optional CA digital Signature X.509: Certificate Content

48. Subject Names • X.500 Distinguished Name (DN) • Associato ad un nodo della gerarchia di directory (X.500) • Ogni nodo ha un Relative Distinguished Name (RDN) • Un percorso per raggiungere il nodo padre • Un set unico di coppie attributo/valore

49. Example Subject Name • Country at Highest Level (e.g. US) • Organization typically at next level (e.g. CertCo) • Individual below (e.g. Common Name “Elizabeth” with Id = 1) DN = { • C=US; • O=CertCo; • CN=Elizabeth, ID=1}

50. Version 3 Certificates • Version 3 X.509 Certificates supporta formati ed estensioni alternative per i nomi • X.500 names • Internet domain names • e-mail addresses • URLs • Un Certificato può includere più di un nome