Network Security Gene Itkis Intro to SSL/TLS Network Security Gene Itkis

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

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

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.

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.

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 )

Architecture Application (HTTP) SSL TCP IP

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

SSL choices Connection-oriented No non-repudiation 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”

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

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

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)

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 )

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

TLS: Architecture TLS definisce il Record Protocol per trasferire I dati dell’applicazione e del TLS La sessione viene stabilita utilizzando l’Handshake Protocol Operational and pending states TLS Record Protocol Handshake Protocol Alert Protocol Change Cipher Spec

The Lock Symbol – How It Works https://www.llbean.com/cgi-bin/ncommerce3/OrderItemDisplay User’s browser accesses a secure site – one that begins with https: instead of http:  Browser sends the server its SSL version number and cipher settings  Server responds with the site’s SSL certificate along with server’s SSL version number and cipher settings  Browser examines server’s certificate and verifies: Certificate is valid and has a valid date, CA that signed the certificate is a trusted CA built into the browser Issuing CA’s public key built into browser validates issuer’s digital signature Domain name in certificate matches the domain name the browser is currently visiting The Lock Symbol – How It Works Browser generates a unique session key to encrypt all communications Browser encrypts session key with the site’s public key and sends it to the server  Server decrypts session key using its own private key Browser and server each generate message to the other informing that messages will hereon be encrypted  SSL session is established and all messages are sent using symmetric encryption (faster than PKI)

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.

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

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.

We learn the hard way that this is actually not United at all 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.

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à

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 Most block ciphers (64 bit blocks) except for RC4 stream cipher CBC cipher block chaining use IV (initialization vector) XOR previous encrypted block with block then encrypt … A Message B $%&#!@

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

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 Secret is used so that someone cannot replace both message and MAC, putting a new matching MAC in place of the original

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

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 A Certificate B

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.

TLS: Record Protocol Currently no compression defined but could be client boundaries are not preserved 2^14 bytes or less in protocol unit md5, sha-1, none MAC des, 3des, des40, rc2, rc4, idea none encryption

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

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

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

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

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.

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 Encryption mac key exchange Des/3des/des40 md5, sha1, none rsa, dh rc2 rc4 idea none

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

TLS: ServerKeyExchange Client ClientHello Server ServerHello Certificate ServerKeyExchange Certificate specifies public key must be appropriate for key exchange algorithm required for non-anonymous key exchange includes certificate chain - certs which verify previous ones in the chain PKCS#7 is not used since defined in sets rather than sequences

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 Server “Hello Request”- ask client to restart hello includes some random data for creating the master secret

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.

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 Client generates 48-byte secret random # , encrypts using server’s public key, sends to server if diffie-hellman, p,g

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.

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.

TLS: Certificate Request Client ClientHello Server ServerHello Certificate ServerKeyExchange CertificateRequest Certificate request is optional specifies list of acceptable certificate authorities specifies types of certificates requested (e.g. RSA, dh)

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

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

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 PKCS standards from RSA for RSA certificates PKCS #10 cert requests PKCS #9 cert attributes PKCS #7 cert chain format application/x-pkcs7-mime used to load CA chain into browser

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)

X.509: Certificate Content 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

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

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} Possible to have more than one DN for an entry

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

Certificate Signature RSA Signature Crea l’hash del Certificato Lo cifra usando la chiave privata della CA Signature verification Decifra la firma usando la chiave pubblica della CA Verifica l’hash DSS digital signature standard also

TLS: Change Cipher Spec, Finished Client [ChangeCipherSpec] Finished Application Data Server [ChangeCipherSpec] Finished Application Data See next slide

TLS: Change Cipher Spec/Finished Chiede di iniziare l’utilizzo della Cipher Suite concordata Finished Invia una copia dell’handshake ed apre una nuova sessione Permette la validazione dell’handshake Change Cipher Spec not part of handshake

U Finished U invia a S il msg finished protetto utilizzando M. Costruzione di finished: FU = M + tutti msg di handshake scambiati finora +identità di U U codificando FU con SHA e MD5 lo invia a S.

S: Finished S verifica il msg finished di U ricalcolando il tutto. S invia a U il suo msg finished protetto utilizzando M. Costruzione di finished: FS = M + tutti msg di handshake scambiati finora (incluso il msg finished di U) +identità di S. S codifica FS con SHA e MD5 e lo invia a U. U verifica il msg finished ricevuo da S.

TLS: Using a Session Client ClientHello (Session #) [ChangeCipherSpec] Finished Application Data Server ServerHello (Session #) [ChangeCipherSpec] Finished Application Data Server can refuse to use session by not including session # in server hello keys for session are calculated fresh using shared master secret and new random numbers from Hello messages

Changes from SSL 3.0 to TLS Fortezza rimossa Aggiunti messaggi di Alert Modifiche al calcolo dell’hash Nuova Protocol version 3.1 in ClientHello, ServerHello Hash includes Finished and CertificateVerify messages following client cert types removed: rsa_ephemeral_dh dss_ephemeral_dh fortezza_dms SSL 2 -> SSL 3.0 major changes

TLS: HTTP Application HTTP è la più comune applicazione di TLS https:// Richiede TLS-capable web server Richiede TLS-capable web browser Netscape Navigator Internet Explorer Cryptozilla Netscape Mozilla sources with SSLeay

Web Servers Apache-SSL Apache mod_ssl Stronghold Roxen iNetStore Stronghold is from C2Net, provides Apache server with SSL full strength encryption 128 bit supports TLS HTTP/1.1 these servers mentioned because they use SSLeay iNetStore designed to produce online catalogs

Other Applications Telnet FTP LDAP POP SSLrsh Commercial Proxies Telnet and FTP have specs which have been written SSLrsh - use X.509 certificates instead of .rhosts file for remote login Safe Passage Web Proxy export only browser proxies to safe passage which provides full 128-bit encryption Secure Socket Relay provides strong encryption for clients

TLS: Implementation Cryptographic Libraries TLS/SSL packages RSARef, BSAFE TLS/SSL packages SSLeay SSLRef BSAFE 4.0 is available from RSA, 6/8/98

X.509 Certificate Issues Certificate Administration is complex Hierarchy of Certification Authorities Mechanisms for requesting, issuing, revoking certificates X.500 names are complicated Description formats are cumbersome (ASN.1) Mention different kinds of certificates identity encryption etc

X.509 Alternative: SDSI SDSI: Simple Distributed Security Infrastructure (Rivest, Lampson) Merging with IETF SPKI: Simple Public-Key Infrastructure in SDSI 2.0 Eliminate X.500 names - use DNS and text Everyone is their own CA Instead of ASN.1 use “S-expressions” and simple syntax

TLS “Alternatives” S-HTTP: secure HTTP protocol, shttp:// IPSec: secure IP SET: Secure Electronic Transaction Protocol and infrastructure for bank card payments SASL: Simple Authentication and Security Layer (RFC 2222) S-HTTP inter-operates with http signature authentication encryption public key key exchange, & externally arranged Secure * Secure-HTTP/1.4 : Request URI Secure-HTTP/1.4 200 OK response header lines convey information e.g. Certificate-Info: has cert, Encryption-Identity: x500 name ------------ IPSec RFC 1825-1829 required for IPv6, optional for IPv4 transport mode - protect contents of IP packet tunnel mode - protect entire IP packet encryption, MAC SASL Means to add authentication to connection-based protocol Variety of mechanisms Kerberos V4, GSSAPI, “External” Allows separation of authorization identity from client identity in credentials Permits authenticated state in protocol

Protocollo SSL

Riassumendo PGP fornisce sicurezza per una specifica applicazione SSL opera sullo strato di trasporto; fornisce sicurezza ad ogni applicazione TCP SSL: usato fra WWW browsers, servers per e-commerce (shttp). SSL servizi offerti: Autenticazione server Codifica dati Autenticazione client (opzionale) Autenticazione Server: browser con SSL include chiavi pubbliche per CA fidate Browser richiede certificato del server alla CA fidata Browser usa la chiave pubblica della CA per estrarre la chiave pubblica del server dal certificato

Riassumendo Sessione SSL crittata: Browser genera chiave simmetrica di sessione, la codifica con la chiave pubblica del server e invia la codifica al server Server decodifica la chiave di sessione con la sua chiave pubblica Browser e server concordano che messaggi futuri saranno crittati I dati inviati nel socket TCP sono codificati con la chiave di sessione SSL: base del livello di trasporto sicuro (Transport Layer Security, TLS). SSL può essere usato anche per altre applicazioni (non Web) ad es., IMAP. L’autentica del cliente può essere fatta in modo analogo (usando certificati del cliente) Uso di chiavi di sessione generate ad hoc permette di limitare l’uso della chiave pubblica (+ veloce, + sicuro)

Handshake Protocol ClientHello ServerHello [Certificate] Messaggio con il quale il client indica quali algoritmi supporta in ordine di preferenza e inserisce un valore casuale ServerHello Risposta del server che indica quali algoritmi (compressione, cifratura, autenticazione) ha scelto, il codice identificativo della sessione e un numero casuale [Certificate] Messaggio contenente il certificato del server ServerKeyExchange Messaggio contenente la chiave pubblica RSA o un valore per effettuare uno scambio Diffie-Hellman [CertificateRequest] Il server può richiedere al client un certificato

Handshake Protocol Change cipher spec Alert E’ un protocollo che consiste di un solo messaggio che viene crittato e compresso in base allo stato corrente della connessione Tale messaggio viene inviato sia dal client che dal server per notificare che i record successivi verranno protetti con gli algoritmi e le chiavi di cifratura appena negoziati Alert Messaggi di controllo ed errore per notificare all’interlocutore una particolare situazione o un evento Tipi di messaggi: chiusura della connessione, errore nella verifica del MAC o nella decifratura, vari tipi di errore relativi ai certificati

Cipher suite Key exchange methods: RSA: richiede il certificato del destinatario Fixed DH: richiede che entrambi abbiano il certificato Ephemeral DH: vengono scambiate chiavi ephemeral firmate, sono richiesti i certificati per ambo le parti Anonymous DH: non occorre autenticazione delle chiavi DH, vulnerabile all’attacco men-in-the-middle Fortezza: Fortezza key exchange

Cipher suite CipherAlgorithm: RC4, RC2, DES, 3DES, DES40, IDEA, Fortezza MACAlgorithm: MD5 or SHA-1 CipherType: stream or block IsExportable: true or false HashSize: 0, 16 or 20 bytes Key Material: used to generate write keys IV Size: size of IV for CBC

Possibili modi di utilizzo Porti dedicati per ogni applicazione che utilizza SSL quello che avviene di fatto Uso del porto comune e negoziazione della sicurezza come parte del protocollo applicativo Uso di SSL negoziato durante l’apertura della normale connessione TCP/IP

Porti https 443 ssmtp 465 snntp 563 sldap 636 spop3 995 ftp-data 889 ftps 990 imaps 991 telnets 992 ircs 993

Differenze tls/ssl TLS usa HMAC, SSL usa un precursore TLS MAC utilizza un maggior numero di meccanismi di compressione rispetto a SSL MAC TLS definisce alert codes aggiuntivi Altre differenze minori TLS può implementare SSL

SSL & ACL Con gli odierni server web, utilizzati con protocollo HTTPS (HTTP over SSL) è possibile definire delle ACL basate sui possibili dati presenti nei certificati degli utenti abilitati all’accesso, Es: campo “Organization” del Distinguished Name del certificato utente oppure consentire l’accesso esclusivamente ad un sottoinsieme di utenti i cui certificati sono contenuti in un repository

SSL & ACL Vantaggi: Gestione di parte dell’autenticazione demandata alla CA In caso di utente malevolo, la revoca da parte della CA del certificato ha come effetto l’impossibilità di accedere a qualunque sistema ( che ha prelevato l’ultima CRL…) Obbligo di revisione delle credenziali di accesso alla scadenza del certificato utente Semplificazione delle procedure di registrazione: l’identificazione dell’utente è stata già fatta dalla CA Single Sign On Possibile centralizzazione/semplificazione delle funzioni di Autenticazione e Autorizzazione …

SSL con APACHE la Apache Software Foundation non include nel progetto Apache Httpd il modulo per il supporto di SSL esistono due progetti open source che si propongono di garantire il supporto di SSL :mod ssl e Apache-SSL , ed entrambi gestiscono le connessioni sicure appoggiandosi alle librerie del progetto OpenSSL esistono altre implementazioni commerciali di moduli SSL per Apache:"Covalent Raven SSL Module For Apache”, la distribuzione IBM di Apache "IBM Http Server".

Direttive per l’uso di SSL SSLSessionCache: imposta il tipo di memorizzazione della cache SSLEngine è la direttiva che abilita o disabilita le connessioni SSL SSLProtocol controlla la versione del protocollo che verrà usata durante le transazioni sicure. Es. SSLProtocol All -SSLv2 SSLCertificateFile e SSLCertificateKeyFile contengono banalmente il path ai file certificato e chiave del server SSLRequireSSL :usata nelle sezioni "<directory>" ci consente di rendere accessibili alcune aree del nostro server solo attraverso connessioni sicure SSLCipherSuite permette di configurare gli algoritmi crittografici che il client può usare quando viene stabilita la connessione

Così… SSL non garantisce l’identità delle parti. Permette la cifratura delle comunicazioni tra client e server La cosa più importanti nelle transazioni è: conchi ho a che fare? Come fare a garantire ciò sul web ?

Commercio Elettronico

Schema della doppia codifica

Commercio elettronico A: acquirente, con accesso a Internet. B: venditore, con catalogo elettronico in Internet. A consulta il catalogo di B, sceglie la merce da acquistare e attiva la transazione. B fornisce ad A la propria chiave pubblica. Il PC di A automaticamente: prepara l’ordine elettronico m; genera una chiave k con cui codifica m  m’; codifica k con la chiave pubblica di B  k’; invia m’ e k’ a B. Il computer di B automaticamente: decodifica k’ con la chiave privata di B; con k decodifica m’ e ottiene l’ordine. B spedisce la merce. problema del pagamento

Pagamento con carta di credito (schema teorico) CC indichi la Società della Carta di credito. A consulta il catalogo di B, sceglie la merce da acquistare, fornisce i dati della propria Carta di credito e attiva la transazione. Il PC di A compie automaticamente due operazioni: prepara l’ordine elettronico senza i dati della Carta di credito e lo invia a B; prepara la nota di debito con i dati della Carta di credito e con riferimento a B; codifica questa nota con un sistema di doppia codifica e la invia a CC. CC decodifica la nota di debito, effettua i controlli rituali, contabilizza l’addebito su A e l’accredito su B, comunica a B il buon esito contabile dell’operazione. B riceve il messaggio da CC ed evade l’ordine. Sistema sicuro ma informaticamente complesso (2 collegamenti indipendenti).

Pagamento con carta di credito (schema reale 1a) Protocollo SSL (Secure Socket Layer) Sviluppato da Netscape e utilizzato anche da Microsoft. m contiene sia i codici della merce sia le coordinate della carta di credito. m viene cifrato da A con un sistema a doppia codifica. m viene inviato a B. L’inoltro delle coordinate della carta di credito a CC è a cura del venditore B.

Osservazioni sulla sicurezza Pro k viene generata presso il mittente A, cambia ad ogni transazione e non esce dal PC di A. A è sicuro di ordinare merce da un fornitore B affidabile, la cui garanzia è fornita indirettamente da CC. B è sicuro di ricevere tramite CC il corrispettivo della merce spedita. Contro B viene a conoscere le coordinate della carta di credito di A: la sicurezza del sistema pertanto è anche in funzione dell’etica di B, non valutabile a priori.

Pagamento con carta di credito (schema reale 1b) Variante del precedente m contiene sia i codici della merce sia le coordinate della carta di credito. m viene cifrato da A con un sistema a doppia codifica. m viene inviato a CC. L’inoltro dell’ordine al venditore B è a cura di CC.  Scompaiono i contro.

Pagamento con carta di credito (schema reale 2) Protocollo SET (Secure Electronic Transaction) Sviluppato su iniziativa di Visa e Mastercard (CC). Le coordinate della carta di credito sono prima codificate con la chiave pubblica di CC poi affiancate ai codici della merce: il tutto forma il messaggio m, che viene codificato con hB . B al ricevimento di m’ estrae le coordinate della carta di credito - che sono cifrate - e le invia a CC. CC le decodifica e autorizza B a spedire la merce.

Osservazioni sulla sicurezza Pro A è sicuro di ordinare merce da un fornitore B affidabile, la cui garanzia è fornita indirettamente da CC. B è sicuro di ricevere il corrispettivo della merce spedita. B non viene a conoscere le coordinate della carta di credito di A: la sicurezza del sistema pertanto dipende solo dell’etica di CC, che si presume altissima. Contro Sistema nuovo, complesso, in corso di diffusione.

Secure electronic transact. (SET) Limiti di SSL in applicazioni e-commerce. Garanzie su validità carta di credito (rubata?) Autorizzazione azienda (per transazione) SET Progettato per transazioni con carta di credito Fornisce sicurezza fra: cliente negoziante banca negoziante Tutti hanno certificati Il numero della carta di credito è fornito in modo crittato (negoz. non vede il numero in chiaro) Previene frodi da parte del negoziante Tre componenti software : Browser Server negoziante Gateway cliente