Antonio Lioy < lioy @ polito.it> Sicurezza della Politecnico di Torino Dip. Automatica Antonio e Lioy Informatica < lioy @ polito.it> Politecnico di Torino Dip. Automatica e Informatica MHS (Message Handling System) MS MTA MTA MTA chain MSA MSA MHS (Message Handling System) MS MTA MTA MUA MTA chain MUA MSA MSA MUA (Message User Agent) MS E-mail in client-server MSA (Message Submission Agent) MS MTA (Message Transfer Agent) MS MUA (Message Store) MUA Mailserver MTA... MUA (Message( MSA User ) Agent) E-mail in client-server MSA (Message Submission Agent) MUA (es. Thunderbird, MTA (Message Transfer Agent) Outlook - Politecnico di Torino MS Express) (1995-2013) (Message Store) 1 Mailserver MTA... Post ( MSA Office )... MTA POP, IMAP ( MS ) MUA (es. Thunderbird, Outlook Express) - Politecnico di Torino (1995-2013) 1 POP, IMAP Post Office ( MS )... MTA Webmail Mailserver ( MSA ) MTA... web browser HTTP HTML Webmail web server HTTP engine POP / IMAP virtual Mailserver MUA ( MSA ) MTA... web browser HTTP HTML web serverpost Office HTTP virtual ( MS ) engine MUA... MTA
25/tcp (MTA) 587/tcp (MSA) Protocolli, porte e formati standard POP (Post Office Protocol) 110/tcp (Simple Mail Transfer Protocol) IMAP (Internet Message Access Protocol) 25/tcp (MTA) 143/tcp 587/tcp (MSA) RFC-822 POP (Post Office Protocol) formato di un messaggio (body di puro testo) 110/tcp MIME IMAP (Internet Message Access Protocol) estensione multimediale di RFC-822 143/tcp RFC-822 formato di un messaggio (body di puro testo) MIME estensione multimediale di RFC-822 Messaggi RFC-822 solo caratteri US-ASCII a 7 bit righe terminate da <CR> <LF> messaggi composti da header + body header Messaggi RFC-822 parole chiave a inizio riga solo caratteri US-ASCII a 7 bit righe di continuazione iniziano con uno spazio righe terminate da <CR> <LF> body messaggi composti da header + body separato dall header da una riga vuota header Header RFC-822 contiene il messaggio parole chiave a inizio riga From: mittente (logico) Sender: righe di continuazione iniziano mittente con (operativo) uno spazio body Organization: organizzazione del mittente To: separato dall header da una riga vuota Header RFC-822 destinatario Subject: contiene il messaggio argomento From: Date: data e ora mittente di spedizione (logico) Sender: mittente (operativo) Received: passaggi intermedi Organization: organizzazione del mittente Message-Id: ID di spedizione To: destinatario CC: in copia a Subject: Bcc: in copia (nascosta) argomentoa Date: Return-Receipt-To: data ricevuta e ora di spedizione ritorno a Received: passaggi intermedi Message-Id: ID di spedizione CC: in copia a Bcc: in copia (nascosta) a Return-Receipt-To: ricevuta di ritorno a - Politecnico di Torino (1995-2013) 3 - Politecnico di Torino (1995-2013) 3 Un esempio / RFC-822 telnet duke.colorado.edu 25 Trying... Connected to duke.colorado.edu Escape character is ^] 220 duke.colorado.edu Un esempio... / RFC-822 HELO telnet duke.colorado.edu leonardo.polito.it 25 Trying 250 Hello... leonardo.polito.it... Nice to meet you! MAIL Connected FROM: cat to duke.colorado.edu Escape 250 cat... character Sender ok is ^] RCPT 220 TO: duke.colorado.edu franz... HELO 250 leonardo.polito.it franz... Recipient ok DATA 250 Hello leonardo.polito.it... Nice to meet you! MAIL 354 FROM: Enter mail, cat end with. on a line by itself
Ciao Francesco, ti rinnovo l invito a venirmi a trovare nelle tue From: prossime cat@athena.polito.it vacanze in Italia. Fammi (Antonio sapere Lioy) To: quando franz@duke.colorado.edu arrivi. Subject: Antonio vacanze Ciao. Francesco, ti rinnovo 250 Ok l invito a venirmi a trovare nelle tue prossime QUIT vacanze in Italia. Fammi sapere quando 221 duke.colorado.edu arrivi. closing connection Antonio connection closed by foreign host. 250 Ok QUIT 221 duke.colorado.edu closing connection connection closed by foreign host Problematiche sistema connectionless (store-and-forward, anche solo per via dei record MX) MTA non fidati sicurezza del MS Problematiche cifratura per mailing-list sistema compatibilità connectionless l installato (store-and-forward, anche solo per via dei record MX) soluzioni concorrenti: MTA non fidati Internet = PGP, PEM, MOSS, S/MIME sicurezza del MS Mail spamming OSI = X.400 cifratura per mailing-list anche detto UBE (Unsolicited Bulk E-mail) o UCE (Unsolicited compatibilità Commercial con l installato E-mail) soluzioni invio di messaggi concorrenti: indesiderati: Internet pubblicità = PGP, PEM, MOSS, S/MIME Mail spamming OSI attacchi = X.400 (malware, phishing,...) anche oggi è detto circa 88% UBE del (Unsolicited traffico mail Bulk E-mail) o UCE (Unsolicited Commercial E-mail) grosso carico su server (CPU e dischi) e reti invio di messaggi indesiderati: grosso fastidio per gli utenti pubblicità carne di maiale in scatola e Monty Python attacchi (malware, phishing,...) il contrario di spam è ham (termine usato dai oggi programmi è circa di 88% identificazione del traffico mail e filtraggio) grosso carico su server (CPU e dischi) e reti grosso fastidio per gli utenti carne di maiale in scatola e Monty Python il contrario di spam è ham (termine usato dai programmi di identificazione e filtraggio) - Politecnico di Torino (1995-2013) 5 - Politecnico di Torino (1995-2013) 5 Strategie degli spammer nascondere il vero mittente ma usare un mittente esistente spedire spam tramite MTA speciali open Strategie mail relay degli spammer zombie o botnet nascondere il vero mittente con indirizzo IP variabile o inesistente ma usare un mittente esistente content obfuscation spedire spam tramite MTA speciali errori deliberati (es. Vi@gr@) open mail relay immagine invece che testo zombie o botnet Bayesian poisoning (es. testo da un libro) con indirizzo IP variabile o inesistente all interno di una mail di errore content obfuscation
polito.it polito.it mail (Open) mail relay incoming mail outgoing mail polito.it mail relay bouncing spam incoming open mail relay mail = MTA che accetta polito.it posta anche non da / per i suoi utenti mail relay bouncing spam open mail relay = MTA che accetta posta anche non da / per i suoi utenti Anti-spam per MSA non configurare i propri MSA / MTA come open relay ma restringerne l uso solo ai propri utenti autenticare gli utenti dei propri MSA: indirizzo IP del MUA Anti-spam per MSA problema con nodi mobili, IP spoofing e non configurare malware (installato i propri MSA su un / nodo MTA valido) come open relay valore ma del restringerne campo From l uso solo ai propri utenti autenticare aggirabile gli utenti facilmente dei propri con fake MSA: mail Anti-spam indirizzo autenticazione IP del per MUAincoming MTA (I) problema metodi sicuri? con nodi mobili, IP spoofing e rifiutare malware o accettare (installato mail da su un un nodo MTA, valido) controllando una blacklist o whitelist valore del campo From DNSBL (DNS-based BlackList) aggirabile facilmente con fake mail l indirizzo A.B.C.D è usato per inviare spam? Anti-spam autenticazione per incoming MTA (I) nslookup q=a D.C.B.A.dnsbl.antispam.net metodi sicuri? rifiutare se NXDOMAIN o accettare allora mail non da un è uno MTA, spammer controllando una blacklist o whitelist altrimenti viene fornito: DNSBL (DNS-based BlackList) un indirizzo 127.0.0.X (ove X è un codice che l indirizzo indica A.B.C.D perché è è elencato) usato per inviare spam? nslookup un record q=a TXT D.C.B.A.dnsbl.antispam.net per maggiori informazioni se RFC-5782 NXDOMAIN DNS allora blacklists non è and uno whitelists spammer altrimenti viene fornito: un indirizzo 127.0.0.X (ove X è un codice che indica perché è elencato) un record TXT per maggiori informazioni RFC-5782 DNS blacklists and whitelists - Politecnico di Torino (1995-2013) 7 - Politecnico di Torino (1995-2013) 7 Anti-spam per incoming MTA (II) URI DNSBL (~URI reputation data) ritardo nell identificazione di nuovi MTA spammer (e loro vita breve) honeypot / spamtrap per catturare spam e Anti-spam per incoming MTA (II) classificare le URI trovate nei messaggi URI lookup DNSBL delle (~URI URI reputation presenti nel data) body di un messaggio (incoming) rispetto a quelle di spam ritardo nell identificazione di nuovi MTA spammer (e loro vita breve) honeypot / spamtrap per catturare spam e classificare le URI trovate nei messaggi lookup delle URI presenti nel body di un messaggio (incoming) rispetto a quelle di spam
MAPS RBL (Realtime Blackhole List) Spamhaus SBL (Spamhaus Block List) Liste DNSBL SORBS (Spam and Open Relay Blocking System) APEWS (Anonymous Postmaster Early Warning molte System) liste (gratis/commerciali, anonime o meno): non MAPS banale RBL uscirne (Realtime una volta Blackhole che si List) è stati inseriti: meglio Spamhaus configurare SBL (Spamhaus bene il proprio Block MTA List) SORBS (Spam and Open Relay Blocking System) attivare/usare APEWS (Anonymous l indirizzo Postmaster abuse@dominio, Early Warning come richiesto System) da RFC-2142 non banale uscirne una volta che si è stati inseriti: meglio configurare bene il proprio MTA attivare/usare l indirizzo abuse@dominio, come richiesto da RFC-2142 Anti-spam per incoming MTA (III) greylisting gli spammer non hanno tempo da perdere errore temporaneo ( try later ) Anti-spam OK se si ripresenta per incoming lo stesso MTA MTA dopo (III) T (es. 5 ) ritarda anche ham + server carico (history contatti) greylisting nolisting (poor man s greylisting) gli spammer non hanno tempo da perdere gli spammer non hanno tempo da perdere, non errore provano temporaneo gli altri MX ( try e/o contattano later ) MX più elevato Anti-spam OK se si ripresenta per incoming lo stesso MTA MTA dopo (IV) MX primario non risponde, MX secondario T (es. OK, 5 ) MX terziario ritarda anche non risponde DKIM (DomainKeys ham Identified + server carico Mail) (history vari RFC contatti) nolisting ritarda (poor anche man s ham un dominio di posta garantisce: greylisting) gli l identità spammer del mittente non hanno tempo da perdere, non provano gli altri MX e/o contattano MX più elevato Anti-spam l integrità (parziale) per incoming del messaggio MTA (IV) MX primario non risponde, MX secondario OK, MX tramite terziario una non firma risponde digitale DKIM (DomainKeys Identified Mail) vari RFC ritarda apposta anche dall outgoing ham MTA o MSA un dominio di posta garantisce: che copre alcuni header e parte del body l identità del mittente verificabile tramite chiave pubblica (es. nel DNS) l integrità (parziale) del messaggio uso crescente (es. Gmail, Yahoo) tramite una firma digitale permette di scartare messaggi con falso mittente e quindi apposta di fare dall outgoing anti-spam MTA ed anti-phishing o MSA che copre alcuni header e parte del body verificabile tramite chiave pubblica (es. nel DNS) - Politecnico di Torino (1995-2013) 9 - Politecnico di Torino (1995-2013) 9 uso crescente (es. Gmail, Yahoo) permette di scartare messaggi con falso mittente e quindi di fare anti-spam ed anti-phishing Anti-spam per incoming MTA (V) SPF (Sender Policy Framework) RFC 4408 un dominio di posta dichiara quali sono i suoi outgoing MTA, tramite un apposito record nel DNS esempi: Anti-spam per incoming MTA (V) $ nslookup q=txt polito.it. polito.it SPF (Sender text = "v=spf1 Policy ptr Framework) ~all" RFC 4408 $ nslookup q=txt gmail.com. un dominio di posta dichiara quali sono i suoi gmail.com text = "v=spf1 redirect=_spf.google.com" outgoing MTA, tramite un apposito record nel DNS $ nslookup q=txt _spf.google.com. _spf.google.com esempi: text = "v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 $ nslookup ip4:209.85.128.0/17 q=txt polito.it. ip4:66.102.0.0/20 ip4:74.125.0.0/16 polito.it ip4:64.18.0.0/20 text = "v=spf1 ip4:207.126.144.0/20 ptr ~all" ip4:173.194.0.0/16 $ nslookup?all" q=txt gmail.com. gmail.com text = "v=spf1 redirect=_spf.google.com"
non cambia il protocollo base ed il canale i client E devono presentarsi con: E EHLO hostname Extended se il server, ricevente definito parla in E, RFC-1869 deve e quindi incorporato dichiarare le (con estensioni ) che in RFC-2821 supporta, una per riga, nella sua risposta all EHLO non cambia il protocollo base ed il canale i client E devono presentarsi con: EHLO hostname se il server ricevente parla E, deve dichiarare le estensioni che supporta, una per riga, nella sua risposta all EHLO Esempi E positivi mailer E senza estensioni: 220 mail.polito.it - service ready EHLO mailer.x.com 250 Hello mailer.x.com - nice to meet you! Esempi E positivi mailer E senza estensioni: mailer E con estensioni: 220 mail.polito.it - service ready EHLO Esempio mailer.x.come negativo 250-Hello mailer.x.com - nice to meet you! il mailer 250-SIZE non conosce 26214400 il protocollo E: mailer 250 E 8BITMIME con estensioni: 220 220 mail.polito.it - - service service ready ready EHLO EHLO mailer.x.com Esempio E negativo 250-Hello 500 Command mailer.x.com not recognized: - nice to meet EHLO you! il mailer 250-SIZE non conosce 26214400 il protocollo E: 250 8BITMIME - Politecnico di Torino (1995-2013) 11 220 mail.polito.it - service ready EHLO mailer.x.com 500 Command not recognized: EHLO - Politecnico di Torino (1995-2013) 11 -Auth estensione di E definita in RFC-4954 comando AUTH + opzioni di MAIL FROM per autenticare un client -Auth prima di accettarne i messaggi!!! utile contro lo spamming: estensione di E definita in RFC-4954 dopo il comando EHLO il server invia i comando meccanismi AUTH di + autenticazione opzioni di MAIL supportati FROM per il autenticare client ne sceglie un client uno prima viene eseguito di accettarne il protocollo i messaggi!!! di autenticazione utile se contro l autenticazione lo spamming: fallisce, il canale viene chiuso dopo il comando EHLO il server invia i meccanismi di autenticazione supportati
Esempio AUTH negativo 220 example.polito.it - service ready EHLO mailer.x.com il mailer non conosce (o non accetta) la modalità di autenticazione 250-example.polito.it proposta dal client: 250 AUTH LOGIN CRAM-MD5 DIGEST-MD5 AUTH PLAIN 220 504 Unrecognized example.polito.it authentication - service typeready EHLO mailer.x.com 250-example.polito.it 250 AUTH LOGIN CRAM-MD5 DIGEST-MD5 AUTH PLAIN 504 Unrecognized authentication type AUTH: metodo LOGIN 220 example.polito.it - service ready EHLO mailer.x.com 250-example.polito.it 250 AUTH: LOGIN metodo CRAM-MD5 LOGIN DIGEST-MD5 AUTH LOGIN 220 334 VXNlcm5hbWU6 example.polito.it - service ready Username: EHLO bglveq== mailer.x.com lioy 250-example.polito.it 334 AUTH: UGFzc3dvcmQ6 metodo PLAIN Password: YW50b25pbw== 250 AUTH LOGIN CRAM-MD5 antonio DIGEST-MD5 sintassi AUTH (RFC-2595): 235 LOGIN authenticated AUTH PLAIN id_pwd 334 VXNlcm5hbWU6 BASE64 Username: id_pwd bglveq== è definito come: lioy [ authorize_id ] \0 authentication_id \0 pwd 334 AUTH: UGFzc3dvcmQ6 metodo PLAIN Password: YW50b25pbw== antonio sintassi (RFC-2595): 235 220 authenticated example.polito.it - service ready AUTH EHLO PLAIN mailer.x.com id_pwd BASE64 id_pwd è 250-example.polito.it definito come: [ authorize_id 250 AUTH ] LOGIN \0 authentication_id PLAIN \0 pwd AUTH PLAIN bglveqbsaw95agfudg9uaw8= 220 235 authenticated example.polito.it - service lioy \0 lioy ready \0 antonio EHLO mailer.x.com 250-example.polito.it 250 AUTH LOGIN PLAIN AUTH PLAIN bglveqbsaw95agfudg9uaw8= 235 authenticated lioy \0 lioy \0 antonio - Politecnico di Torino (1995-2013) 13 - Politecnico di Torino (1995-2013) 13 AUTH: metodo CRAM-MD5 220 x.polito.it - service ready EHLO mailer.x.com 250-x.polito.it <69.2012010320105807@x.polito.it> 250 AUTH CRAM-MD5 AUTH: DIGEST-MD5 metodo CRAM-MD5 AUTH CRAM-MD5 220 334 x.polito.it PDY5LjIwMTIwMTAzMjAxMDU4MDdAeC5wb2xpdG8uaXQ+ - service ready EHLO bglvesa1mguxnjjizdc5ngzjndnjzmm1zjk1mzq1ndi3mja5nw== mailer.x.com 250-x.polito.it 235 Authentication successful <69.2012010320105807@x.polito.it> 250 AUTH CRAM-MD5 DIGEST-MD5 AUTH CRAM-MD5 lioy hmac(antonio,<69.2012010320105807@x.polito.it>) hex 334 PDY5LjIwMTIwMTAzMjAxMDU4MDdAeC5wb2xpdG8uaXQ+ bglvesa1mguxnjjizdc5ngzjndnjzmm1zjk1mzq1ndi3mja5nw==
STARTTLS = opzione di EHLO e comando se la negoziazione ha successo, si resetta lo stato Protezione di con TLS del protocollo (si riparte da EHLO e le estensioni supportate possono essere diverse) RFC-2487 Service Extension for Secure se il livello over di TLS sicurezza negoziato è insufficiente: STARTTLS il client invia = opzione subito QUIT di EHLO ed esce e comando se la il server negoziazione risponde ha ad successo, ogni comando si resetta col codice lo stato 554 del (refused protocollo due (si to riparte low security) da EHLO e le estensioni supportate possono essere diverse) se il livello di sicurezza negoziato è insufficiente: il client invia subito QUIT ed esce il server risponde ad ogni comando col codice 554 (refused due to low security) Protezione di con TLS: esempio 220 example.polito.it - service ready EHLO mailer.x.com 250-example.polito.it 250-8BITMIME 250-STARTTLS 220 250 DSN example.polito.it - service ready EHLO STARTTLS mailer.x.com 250-example.polito.it 220 Go ahead integrità TLS 250-8BITMIME negotiation (senza comunicazione is started between diretta): client and server il 250-STARTTLS messaggio non può essere modificato autenticazione 250 DSN STARTTLS identifica il mittente 220 Go ahead non ripudio integrità TLS negotiation (senza comunicazione is started between diretta): client and server il mittente non può negare di aver spedito il mail il messaggio non può essere modificato riservatezza (opzionale): autenticazione messaggi non leggibili sia in transito sia nella identifica casella postale il mittente non ripudio il mittente non può negare di aver spedito il mail Protezione di con TLS: esempio Servizi di sicurezza per messaggi di e-mail Servizi di sicurezza per messaggi di e-mail - Politecnico di Torino (1995-2013) 15 - Politecnico di Torino (1995-2013) 15 riservatezza (opzionale): messaggi non leggibili sia in transito sia nella casella postale Sicurezza dell e-mail - idee guida (I) nessuna modifica agli attuali MTA messaggi codificati per evitare problemi nell attraversare i gateway (es. Internet-Notes) oppure gli MTA non 8BITMIME Sicurezza dell e-mail - idee guida (I) nessuna modifica agli attuali UA nessuna interfaccia modifica utente agli scomoda attuali MTA con messaggi modifica codificati agli attuali per UA evitare problemi nell attraversare interfaccia utente i migliore gateway (es. Internet-Notes) oppure gli MTA non 8BITMIME nessuna modifica agli attuali UA interfaccia utente scomoda con modifica agli attuali UA
per la crittografia dei messaggi con chiave di messaggio Sicurezza dell e-mail - idee guida (II) algoritmi asimmetrici per crittografare e scambiare la chiave simmetrica algoritmi simmetrici per la firma digitale per la crittografia dei messaggi usare certificati a chiave pubblica (es. X.509) per il non-ripudio con chiave di messaggio algoritmi la sicurezza asimmetrici del messaggio si basa solo sulla sicurezza per crittografare dell UA del e scambiare destinatario, la chiave non su simmetrica quella degli MTA (non fidati) per la firma digitale usare certificati a chiave pubblica (es. X.509) per il non-ripudio la sicurezza del messaggio si basa solo sulla sicurezza dell UA del destinatario, non su quella degli MTA (non fidati) Tipi di messaggi sicuri clear-signed msg in chiaro (perché tutti possano leggerlo) + firma solo chi ha MUA sicuro può verificare la firma signed Tipi di messaggi sicuri msg + firma codificati (es. base64, uuencode) clear-signed solo chi ha MUA sicuro (o fa uno sforzo manuale) msg può decodificarli in chiaro (perché e verificare tutti possano la firmaleggerlo) + firma encrypted solo chi / ha enveloped MUA sicuro può verificare la firma Messaggi sicuri: creazione signed msg cifrato + chiavi cifrate, codificato canonicalizzazione msg solo chi + firma ha MUA codificati sicuro (es. base64, chiavi!) può uuencode) decifrarlo signed solo formato and chi ha enveloped standard, MUA sicuro indipendente (o fa uno da sforzo OS / manuale) host / net MIC può (Message decodificarli Integrity e verificare Code) la firma encrypted integrità / enveloped Messaggi ed autenticità sicuri: creazione msg tipicamente: cifrato + chiavi msg + cifrate, { h(msg) codificato } Kpri_sender canonicalizzazione cifratura solo chi ha MUA sicuro (e chiavi!) può decifrarlo signed formato and enveloped standard, indipendente da OS / host / net riservatezza MIC (Message Integrity Code) tipicamente: { msg } K M + { K M } Kpub_receiver integrità ed autenticità codifica tipicamente: msg + { h(msg) } Kpri_sender per evitare alterazioni da parte degli MTA cifratura tipicamente: base64 (vecchi: uuencode, binhex) riservatezza tipicamente: { msg } K M + { K M } Kpub_receiver codifica per evitare alterazioni da parte degli MTA tipicamente: base64 (vecchi: uuencode, binhex) - Politecnico di Torino (1995-2013) 17 - Politecnico di Torino (1995-2013) 17 Formati di sicura IETF underground DOD + EU PEM PGP X.400 Formati di sicura MOSS IETF underground MIME-PGP DOD X.421 + EU PEM PGP X.400 S/MIME MOSS MIME-PGP X.421
stessi obiettivi di PEM e struttura simile ma più artigianale PGP (Pretty Good Privacy) peculiare certificazione delle chiavi ("amici" fidati, algebra di propagazione della fiducia) autenticazione, integrità e riservatezza per posta elettronica RFC: o file privati stessi RFC-1991 obiettivi (informational) di PEM e struttura simile ma più artigianale RFC-4880 (OpenPGP) peculiare versioni per certificazione UNIX, VMS, delle MS-DOS, chiavi Mac, ("amici" Amiga, fidati,... algebra di propagazione della fiducia) l autore (Phil Zimmerman) ed il programma sono RFC: ormai diventati un simbolo della libertà in Internet RFC-1991 (informational) RFC-4880 (OpenPGP) versioni per UNIX, VMS, MS-DOS, Mac, Amiga,... l autore (Phil Zimmerman) ed il programma sono ormai diventati un simbolo della libertà in Internet Phil Zimmermann rilascia PGP come freeware nel 1991 incarcerato, rilasciato e investigato sino al 1996, quando le accuse vengono fatte cadere e fonda PGP Inc. acquisita poi da NAI Phil Zimmermann agosto 2002 lascia NAI e fonda PGP Co. rilascia PGP come freeware nel 1991 incarcerato, rilasciato e investigato sino al 1996, quando le accuse vengono fatte cadere e fonda PGP PGP Inc. acquisita - algoritmi poi da (fino NAI alla v. 2.6) agosto 2002 lascia NAI e fonda PGP Co. fissi crittografia simmetrica: IDEA digest: PGP - algoritmi (fino alla v. 2.6) MD5 fissi crittografia asimmetrica (per firma digitale e per crittografia scambio della simmetrica: chiave simmetrica): IDEA RSA digest: tutti gratuiti per usi non commerciali MD5 crittografia asimmetrica (per firma digitale e per scambio della chiave simmetrica): RSA tutti gratuiti per usi non commerciali - Politecnico di Torino (1995-2013) 19 - Politecnico di Torino (1995-2013) 19 Esempio PGP 2.6: firma + cifratura messaggio M MD5 Esempio PGP 2.6: firma + cifratura RSA M+F + ZIP IDEA {M+F}+{K M } + B64 messaggio Mchiave privata del mittente M+F MD5 RSA + { K M } K M chiave di RSA messaggio {M+F}+{K M } ZIP IDEA chiave pubblica + del destinatario { K M } B64
la fiducia si propaga transitivamente con un certo grado di approssimazione: PGP - certificazione delle chiavi completely ogni partially certificato contiene la firma di tutti coloro che si fidano untrusted del proprietario la fiducia unknown si propaga transitivamente con un certo grado di approssimazione: completely partially untrusted unknown PGP web of trust? C PGP web of trust B D A F I M E H C PGP - distribuzione delle chiavi B E YOU le chiavi completely sono conservate partiallyyou untrusted personalmente unknownda ogni Y firma X utente? trusted ( key-ring trusted ) Y le N Dchiavi sono distribuite direttamente A I dal H proprietario (PGP party!) o dai key-server (http, smtp, PGP finger) - distribuzione delle chiavi X progetti per distribuire le chiavi mediante X.500 o le chiavi completely sono conservate partially untrusted personalmente unknownda ogni Y firma X DNS ( pgp.net ): utente trusted ( key-ring trusted ) - Politecnico di Torino (1995-2013) Y 21 www.pgp.net le chiavi sono distribuite direttamente dal proprietario keys.pgp.net (PGP party!) o dai key-server (http, smtp, ftp.pgp.net finger) progetti per distribuire le chiavi mediante X.500 o DNS ( pgp.net ): - Politecnico di Torino (1995-2013) 21 www.pgp.net keys.pgp.net ftp.pgp.net F G G L L M N X PGP & NAI diritti di PGP acquistati nel dicembre 1997 da NAI (Network Associates Inc.) nuova versione, basata su DSA, DH, 3DES a causa di problemi legali con RSA PGP & NAI integrazione in molti mailer diritti tentativo di PGP di imporlo acquistati nel nel mercato dicembre corporate: 1997 da NAI (Network Associates Inc.) pseudo-ca (=super-firmatario) nuova versione, basata su DSA, DH, 3DES accettazione del formato X.509 (set 98) a causa di problemi legali con RSA agosto 2002: diritti ceduti a PGP Co. integrazione in molti mailer tentativo di imporlo nel mercato corporate: pseudo-ca (=super-firmatario)
GPG = riscrittura di PGP sotto licenza GPL e priva di algoritmi brevettati Gnu Privacy Guard (GPG) interopera con messaggi PGP 2.x (con qualche difficoltà) e OpenPGP (RFC-2440) PGP non è più freeware (!) e non esiste per Linux (!!) DSA, RSA, AES, 3DES, Blowfish, Twofish, CAST5, MD5, SHA-1, RIPEMD-160 e TIGER GPG = riscrittura di PGP sotto licenza GPL e priva di numerosi algoritmi front-end brevettati grafici interopera Linux, FreeBSD, con messaggi OpenBSD, PGP 2.x Windows (con qualche difficoltà) (95/98/NT/2000/ME), e OpenPGP...(RFC-2440) DSA, RSA, AES, 3DES, Blowfish, Twofish, CAST5, MD5, SHA-1, RIPEMD-160 e TIGER numerosi front-end grafici per Linux, FreeBSD, OpenBSD, Windows (95/98/NT/2000/ME),... MIME (Multipurpose Internet Mail Extensions) MIME varie codifiche formato MIME dei dati recursivo alfabeti non-usa ogni parte può righe lunghe essere un oggetto dati binari MIME multipart formato varie Posta codifiche elettronica multipart multimediale formato sicura dei dati recursivo (MOSS parti distinte o S/MIME) alfabeti non-usa parti di tipo diverso ogni parte può firma digitale / cifratura con certificati righe lunghe essere un X.509v3 oggetto dati protegge binari messaggi MIME multipart formato firmato firmato multipart e cifrato cifrato (Multipurpose Internet Mail Extensions) Posta elettronica multimediale sicura (MOSS o S/MIME) testo parti distinte testo testo tabella parti di tipo diverso firma Exceldigitale / tabella cifratura Excel con certificati tabella X.509v3 Excel - Politecnico docum. di protegge Torino Word(1995-2013) messaggi docum. MIME Word docum. Word 23 firma digitale in firma digitale in busta cifrata in formato firmato S/MIME firmato e cifrato cifrato formato S/MIME formato S/MIME testo busta testocifrata in testo tabella Excel formato tabella Excel S/MIME tabella Excel - Politecnico docum. di Torino Word(1995-2013) docum. Word docum. Word 23 firma digitale in firma digitale in busta cifrata in formato S/MIME formato S/MIME formato S/MIME busta cifrata in formato S/MIME estensioni MIME per la sicurezza dei messaggi per la firma digitale: Content-Type: multipart/signed; protocol="type/stype"; micalg="..."; RFC-1847 boundary="..." estensioni MIME per la sicurezza dei messaggi per con la due firma body digitale: part: Content-Type: multipart/signed; quella da proteggere (content-type:...) protocol="type/stype"; la firma micalg="..."; (content-type: TYPE/STYPE) rischioso boundary="..." se gateway altera il messaggio con due body part: RFC-1847
promosso da RSA v2 pubblicato come serie di informational RFC: RFC-2311 S/MIME S/MIME v2 message specification RFC-2312 S/MIME v2 certificate handling sicurezza di messaggi MIME RFC-2313 PKCS-1: RSA encryption v.1-5 promosso da RSA RFC-2314 PKCS-10: certification request syntax v2 pubblicato v.1-5 come serie di informational RFC: RFC-2311 RFC-2315 S/MIME PKCS-7: v2 cryptographic message specification message RFC-2312 syntax v.1-5 S/MIME v2 certificate handling RFC-2313 PKCS-1: RSA encryption v.1-5 RFC-2314 PKCS-10: certification request syntax v.1-5 RFC-2315 PKCS-7: cryptographic message syntax v.1-5 S/MIMEv3 proposed standard IETF RFC-2633 S/MIME v3 message specification RFC-2632 S/MIMEv3 S/MIME v3 certificate handling proposed RFC-2634 standard IETF Enhanced Security Services for S/MIME RFC-2633 S/MIME RFC-2314 v3 PKCS-10: message certification specification request syntax v.1-5 RFC-2632 RFC-2634 S/MIME RFC-2630v3 certificate handling CMS RFC-2634 Enhanced (Cryptographic Security Services Message for Syntax) S/MIME Enhanced indirizza le seguenti Security aree: Services for S/MIME RFC-2314 firma per PKCS-10: ricevuta di certification un documento request syntax v.1-5 security label RFC-2634 RFC-2630 mailing-list sicure CMS Enhanced (Cryptographic Security Services Message for Syntax) S/MIME firma degli attributi dei certificati indirizza le seguenti aree: - Politecnico di Torino (1995-2013) 25 firma per ricevuta di un documento security label mailing-list sicure firma degli attributi dei certificati - Politecnico di Torino (1995-2013) 25 Architettura di S/MIME Architetturalmente è basato su: PKCS-7 (S/MIME v2) CMS (S/MIME v3) specifica le caratteristiche crittografiche ed i tipi di Architettura messaggi (equivalente di S/MIME al PEM) PKCS-10 Architetturalmente è basato su: formato della richiesta di certificato PKCS-7 (S/MIME v2) X.509 CMS (S/MIME v3) formato dei certificati a chiave pubblica specifica le caratteristiche crittografiche ed i tipi di messaggi (equivalente al PEM) PKCS-10 formato della richiesta di certificato X.509
SHA-1 (preferito), MD5 firma digitale: DSS (obbligatorio) S/MIME: algoritmi digest + RSA message digest: scambio chiavi: SHA-1 (preferito), MD5 Diffie-Helmann (obbligatorio) firma digitale: chiave cifrata con RSA DSS (obbligatorio) cifratura del messaggio: digest + RSA 3DES con 3 chiavi scambio chiavi: RC2/40 Diffie-Helmann (obbligatorio) chiave cifrata con RSA cifratura del messaggio: 3DES con 3 chiavi RC2/40 MIME type application/pkcs7-mime, usato per: msg. cifrati (PKCS-7 envelopeddata) msg. firmati binari (PKCS-7 signeddata) destinati solo ad utenti S/MIME perché il messaggio è type all interno della busta PKCS-7 application/pkcs7-mime, msg. che contengono solo usato una per: chiave pubblica (= certificato; formato PKCS-7 signeddata msg. cifrati (PKCS-7 envelopeddata) "degenerato", ossia con dati nulli) msg. firmati binari (PKCS-7 signeddata) destinati estensione standard:.p7m solo ad utenti S/MIME perché type il messaggio è all interno sempre codificato della busta in base64 PKCS-7 multipart/signed msg. che contengono solo una chiave pubblica (= messaggi certificato; firmati formato destinati PKCS-7 anche signeddata ad utenti non "degenerato", S/MIME (clear-signed) ossia con dati nulli) estensione il messaggio standard: resta in chiaro.p7m MIME type sempre l ultima parte codificato MIME in è base64 la firma (da RFC-1847) multipart/signed la parte di firma ha estensione standard.p7s ed è messaggi codificata in firmati base64 destinati anche ad utenti non S/MIME (clear-signed) application/pkcs10 il messaggio resta in chiaro l ultima per inviare parte richiesta MIME è di la certificazione firma (da RFC-1847) ad una CA la codificato parte in firma base64 ha estensione standard.p7s ed è codificata in base64 - Politecnico di Torino (1995-2013) 27 - Politecnico di Torino (1995-2013) 27 application/pkcs10 per inviare richiesta di certificazione ad una CA codificato in base64 S/MIME: esempio di firma Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="-----aaaaa" S/MIME: esempio di firma -----aaaaa Content-Type: text/plain Content-Type: Content-Transfer-Encoding: multipart/signed; 7bit protocol="application/pkcs7-signature"; Ciao! micalg=sha1; boundary="-----aaaaa" Content-Type: application/pkcs7-signature -----aaaaa Content-Transfer-Encoding: base64 Content-Type: text/plain Content-Transfer-Encoding: MIIN2QasDDSdwe/625dBxgdhdsf76rHfrJe65a4f 7bit fvvsw2q1ed+sfds543sdwe6+25dbxfder0edsrs5 Ciao! -----aaaaa- -----aaaaa
selezionare il certificato verificare l indirizzo del mittente Naming in S/MIME in S/MIMEv2 consigliato Email= o E= nel DN nel certificato X.509, ma possibile usare l estensione per: subjectaltname con codifica rfc822 in S/MIMEv3 selezionare obbligatorio il certificato usare l estensione subjectaltname con codifica rfc822 verificare l indirizzo del mittente in S/MIMEv2 consigliato Email= o E= nel DN nel certificato X.509, ma possibile usare l estensione subjectaltname con codifica rfc822 in S/MIMEv3 obbligatorio usare l estensione subjectaltname con codifica rfc822 Protocolli di accesso al MS Post Office MUA Protocolli di accesso al MS autenticazione dell utente autenticazione del server Protocolli di accesso al MS riservatezza/integrità della posta Post Office sul server MUA POP durante (Post-Office il trasferimento Protocol) autenticazione POP-2 (RFC-937), dell utente POP-3 (RFC-1939) autenticazione autenticazione del dell utente server mediante password in chiaro (!!!) riservatezza/integrità Protocolli di della accesso posta al MS APOP sul autenticazione server dell utente mediante sfida POP durante (Post-Office il trasferimento Protocol) K-POP POP-2 (RFC-937), POP-3 (RFC-1939) mutua autenticazione grazie ai ticket autenticazione dell utente mediante password in IMAP chiaro (Internet (!!!) Mail Access Protocol) APOP username e password in chiaro autenticazione può usare OTP, dell utente Kerberos mediante o GSS-API sfida K-POP mutua autenticazione grazie ai ticket IMAP (Internet Mail Access Protocol) - Politecnico di Torino (1995-2013) 29 - Politecnico di Torino (1995-2013) 29 username e password in chiaro può usare OTP, Kerberos o GSS-API Esempio POP-3 telnet pop.polito.it 110 +OK POP3 server ready <7831.84549@pop.polito.it> USER lioy +OK password Esempio required for POP-3 lioy PASS antonio +OK telnet lioy mailbox pop.polito.it locked 110and ready +OK STAT POP3 server ready <7831.84549@pop.polito.it> +OK USER 2 320 lioy +OK... password required for lioy PASS QUIT antonio +OK POP3 lioy mailbox server locked signing and off ready STAT
la sfida è la parte della riga di hello tra parentesi acute <... > (parentesi incluse) APOP sintassi: APOP user risposta-alla-sfida comando APOP sostituisce la coppia di comandi USER risposta + PASS = MD5( sfida + password ) la risposta sfida è codificata la parte della in esadecimale riga di hello tra parentesi acute supportato <... > da (parentesi Eudora incluse) sintassi: APOP user risposta-alla-sfida risposta = MD5( sfida + password ) risposta codificata in esadecimale supportato da Eudora Esempio APOP telnet pop.polito.it 110 +OK POP3 server ready <7831.84549@pop.polito.it> APOP lioy 36a0b36131b82474300846abd6a041ff +OK lioy mailbox locked Esempio and ready APOP STAT +OK telnet 2 320pop.polito.it 110 +OK... POP3 server ready <7831.84549@pop.polito.it> APOP QUIT lioy 36a0b36131b82474300846abd6a041ff +OK POP3 lioy mailbox server Sicurezza locked signing and off ready di IMAP STAT per default autenticazione debole +OK 2 LOGIN 320 user password... autenticazione forte: QUIT AUTHENTICATE KERBEROS_V4 +OK POP3 AUTHENTICATE server Sicurezza signing GSSAPI off di IMAP AUTHENTICATE SKEY per default autenticazione debole mutua autenticazione solo se si usa Kerberos LOGIN user password autenticazione forte: AUTHENTICATE KERBEROS_V4 AUTHENTICATE GSSAPI AUTHENTICATE SKEY mutua autenticazione solo se si usa Kerberos - Politecnico di Torino (1995-2013) 31 - Politecnico di Torino (1995-2013) 31 RFC-2595 (TLS per POP / IMAP) RFC-2595 Using TLS with IMAP, POP3 and ACAP prima si apre il canale e poi si negozia la sicurezza tramite un apposito comando: RFC-2595 (TLS per POP / IMAP) STARTTLS per IMAP e ACAP RFC-2595 STLS per POP3 Using client e TLS server with devono IMAP, poter POP3 essere and ACAP configurati per prima rifiutare si user apre e il password canale e poi si negozia la sicurezza tramite client confronta un apposito identità comando: del certificato con l identità STARTTLS del server per IMAP e ACAP STLS per POP3 client e server devono poter essere configurati per rifiutare user e password
implicano URL diverse (es. http e https) implicano un modello sicuro / insicuro non corretto (es. è sicuro SSL a 40 bit? è non sicura Porte separate per SSL/TLS? un applicazione senza SSL ma con SASL?) sconsigliate non facile da implementare IETF per i seguenti usa SSL motivi: se disponibile implicano raddoppia URL il numero diverse porte (es. http necessarie e https) ma implicano presentano un modello alcuni sicuro vantaggi: / insicuro non corretto (es. semplicità è sicuro di SSL filtraggio a 40 sui bit? firewall è non sicura packet-filter un applicazione senza SSL ma con SASL?) SSL con client-authentication permette di non non esporre facile implementare applicazioni ad usa attacchi SSL se disponibile raddoppia il numero di porte necessarie ma presentano alcuni vantaggi: semplicità di filtraggio sui firewall packet-filter SSL con client-authentication permette di non esporre le applicazioni ad attacchi - Politecnico di Torino (1995-2013) 33 - Politecnico di Torino (1995-2013) 33