MHS (Message Handling System) Sicurezza della posta elettronica. in client-server. Webmail. Messaggi RFC-822

Transcript

1 MHS (Message Handling System) Sicurezza della posta elettronica MTA MSA MTA chain MTA MSA Antonio Lioy < polito.it> MS MUA MUA MS Politecnico di Torino Dip. Automatica e Informatica MUA (Message User Agent) MSA (Message Submission Agent) MTA (Message Transfer Agent) MS (Message Store) in client-server Webmail Mailserver ( MSA ) MTA... Mailserver ( MSA ) MTA... MUA (es. Thunderbird, Outlook Express) web browser HTTP HTML web server HTTP engine virtual MUA POP, IMAP Post Office ( MS )... MTA POP / IMAP Post Office ( MS )... MTA Protocolli, porte e formati standard (Simple Mail Transfer Protocol) 25/tcp (MTA) 587/tcp (MSA) POP (Post Office Protocol) 110/tcp IMAP (Internet Message Access Protocol) 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 parole chiave a inizio riga righe di continuazione iniziano con uno spazio body separato dall header da una riga vuota contiene il messaggio Antonio Lioy - Politecnico di Torino ( ) 1

2 Header RFC-822 From: mittente (logico) Sender: mittente (operativo) Organization: organizzazione del mittente To: destinatario Subject: argomento Date: data e ora di spedizione Received: passaggi intermedi Message-Id: ID di spedizione CC: in copia a Bcc: in copia (nascosta) a Return-Receipt-To: ricevuta di ritorno a Un esempio / RFC-822 telnet duke.colorado.edu 25 Trying... Connected to duke.colorado.edu Escape character is ^] 220 duke.colorado.edu... HELO leonardo.polito.it 250 Hello leonardo.polito.it... Nice to meet you! MAIL FROM: cat 250 cat... Sender ok RCPT TO: franz 250 franz... Recipient ok DATA 354 Enter mail, end with. on a line by itself From: cat@athena.polito.it (Antonio Lioy) To: franz@duke.colorado.edu Subject: vacanze Ciao Francesco, ti rinnovo l invito a venirmi a trovare nelle tue prossime vacanze in Italia. Fammi sapere quando arrivi. Antonio. 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 cifratura per mailing-list compatibilità con l installato soluzioni concorrenti: Internet = PGP, PEM, MOSS, S/MIME OSI = X.400 Mail spamming anche detto UBE (Unsolicited Bulk ) o UCE (Unsolicited Commercial ) invio di messaggi indesiderati: pubblicità attacchi (malware, phishing,...) oggi è circa 88% del traffico mail 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) Strategie degli spammer nascondere il vero mittente ma usare un mittente esistente spedire spam tramite MTA speciali open mail relay zombie o botnet con indirizzo IP variabile o inesistente content obfuscation errori deliberati (es. Vi@gr@) immagine invece che testo Bayesian poisoning (es. testo da un libro) all interno di una mail di errore Antonio Lioy - Politecnico di Torino ( ) 2

3 polito.it (Open) mail relay outgoing mail incoming mail polito.it mail relay open mail relay = MTA che accetta posta anche non da / per i suoi utenti bouncing spam 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 problema con nodi mobili, IP spoofing e malware (installato su un nodo valido) valore del campo From aggirabile facilmente con fake mail autenticazione metodi sicuri? Anti-spam per incoming MTA (I) rifiutare o accettare mail da un MTA, controllando una blacklist o whitelist DNSBL (DNS-based BlackList) l indirizzo A.B.C.D è usato per inviare spam? nslookup q=a D.C.B.A.dnsbl.antispam.net se NXDOMAIN allora non è uno spammer altrimenti viene fornito: un indirizzo X (ove X è un codice che indica perché è elencato) un record TXT per maggiori informazioni RFC-5782 DNS blacklists and whitelists 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 classificare le URI trovate nei messaggi lookup delle URI presenti nel body di un messaggio (incoming) rispetto a quelle di spam Liste DNSBL molte liste (gratis/commerciali, anonime o meno): MAPS RBL (Realtime Blackhole List) Spamhaus SBL (Spamhaus Block List) SORBS (Spam and Open Relay Blocking System) APEWS (Anonymous Postmaster Early Warning System) 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 ) OK se si ripresenta lo stesso MTA dopo T (es. 5 ) ritarda anche ham + server carico (history contatti) nolisting (poor man s greylisting) gli spammer non hanno tempo da perdere, non provano gli altri MX e/o contattano MX più elevato MX primario non risponde, MX secondario OK, MX terziario non risponde ritarda anche ham Antonio Lioy - Politecnico di Torino ( ) 3

4 Anti-spam per incoming MTA (IV) DKIM (DomainKeys Identified Mail) vari RFC un dominio di posta garantisce: l identità del mittente l integrità (parziale) del messaggio tramite una firma digitale apposta dall outgoing MTA o MSA che copre alcuni header e parte del body verificabile tramite chiave pubblica (es. nel DNS) 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: $ nslookup q=txt polito.it. polito.it text = "v=spf1 ptr ~all" $ nslookup q=txt gmail.com. gmail.com text = "v=spf1 redirect=_spf.google.com" $ nslookup q=txt _spf.google.com. _spf.google.com text = "v=spf1 ip4: /19 ip4: /19 ip4: /20 ip4: /18 ip4: /17 ip4: /20 ip4: /16 ip4: /20 ip4: /20 ip4: /16?all" E Extended, definito in RFC-1869 e quindi incorporato (con ) in RFC-2821 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 250 Hello mailer.x.com - nice to meet you! mailer E con estensioni: 220 mail.polito.it - service ready 250-Hello mailer.x.com - nice to meet you! 250-SIZE BITMIME Esempio E negativo il mailer non conosce il protocollo E: 220 mail.polito.it - service ready 500 Command not recognized: EHLO -Auth estensione di E definita in RFC-4954 comando AUTH + opzioni di MAIL FROM per autenticare un client prima di accettarne i messaggi!!! utile contro lo spamming: dopo il comando EHLO il server invia i meccanismi di autenticazione supportati il client ne sceglie uno viene eseguito il protocollo di autenticazione se l autenticazione fallisce, il canale viene chiuso Antonio Lioy - Politecnico di Torino ( ) 4

5 Esempio AUTH negativo il mailer non conosce (o non accetta) la modalità di autenticazione proposta dal client: 220 example.polito.it - service ready 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 250-example.polito.it 250 AUTH LOGIN CRAM-MD5 DIGEST-MD5 AUTH LOGIN 334 VXNlcm5hbWU6 Username: bglveq== lioy 334 UGFzc3dvcmQ6 Password: YW50b25pbw== antonio 235 authenticated AUTH: metodo PLAIN sintassi (RFC-2595): AUTH PLAIN id_pwd BASE64 id_pwd è definito come: [ authorize_id ] \0 authentication_id \0 pwd 220 example.polito.it - service ready 250-example.polito.it 250 AUTH LOGIN PLAIN AUTH PLAIN bglveqbsaw95agfudg9uaw8= 235 authenticated lioy \0 lioy \0 antonio AUTH: metodo CRAM-MD5 220 x.polito.it - service ready 250-x.polito.it < @x.polito.it> 250 AUTH CRAM-MD5 DIGEST-MD5 AUTH CRAM-MD5 334 PDY5LjIwMTIwMTAzMjAxMDU4MDdAeC5wb2xpdG8uaXQ+ bglvesa1mguxnjjizdc5ngzjndnjzmm1zjk1mzq1ndi3mja5nw== 235 Authentication successful lioy hmac(antonio,< @x.polito.it>) hex Protezione di con TLS RFC-2487 Service Extension for Secure over TLS STARTTLS = opzione di EHLO e comando se la negoziazione ha successo, si resetta lo stato del protocollo (si riparte 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 250-example.polito.it 250-8BITMIME 250-STARTTLS 250 DSN STARTTLS 220 Go ahead TLS negotiation is started between client and server Antonio Lioy - Politecnico di Torino ( ) 5

6 Servizi di sicurezza per messaggi di integrità (senza comunicazione diretta): il messaggio non può essere modificato autenticazione identifica il mittente non ripudio il mittente non può negare di aver spedito il mail riservatezza (opzionale): messaggi non leggibili sia in transito sia nella casella postale Sicurezza dell - 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 nessuna modifica agli attuali UA interfaccia utente scomoda con modifica agli attuali UA interfaccia utente migliore Sicurezza dell - idee guida (II) algoritmi simmetrici per la crittografia dei messaggi con chiave di messaggio algoritmi asimmetrici per crittografare e scambiare la chiave simmetrica 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 (come allegato o parte del messaggio) solo chi ha MUA sicuro può verificare la firma signed msg + firma codificati (es. base64, uuencode) solo chi ha MUA sicuro (o fa uno sforzo manuale) può decodificarli e verificare la firma encrypted / enveloped msg cifrato + chiavi cifrate, codificato solo chi ha MUA sicuro (e chiavi!) può decifrarlo signed and enveloped Messaggi sicuri: creazione canonicalizzazione formato standard, indipendente da OS / host / net MIC (Message Integrity Code) integrità ed autenticità tipicamente: msg + { h(msg) } Kpri_sender cifratura riservatezza tipicamente: { msg } K M + { K M } Kpub_receiver codifica per evitare alterazioni da parte degli MTA tipicamente: base64 (vecchi: uuencode, binhex) Formati di posta elettronica sicura IETF underground DOD + EU PEM PGP X.400 MOSS MIME-PGP X.421 S/MIME Antonio Lioy - Politecnico di Torino ( ) 6

7 PGP (Pretty Good Privacy) autenticazione, integrità e riservatezza per posta elettronica o file privati stessi obiettivi di PEM e struttura simile ma più artigianale peculiare certificazione delle chiavi ("amici" fidati, algebra di propagazione della fiducia) RFC: 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 agosto 2002 lascia NAI e fonda PGP Co. PGP - algoritmi (fino alla v. 2.6) fissi crittografia simmetrica: IDEA digest: MD5 crittografia asimmetrica (per firma digitale e per scambio della chiave simmetrica): RSA tutti gratuiti per usi non commerciali messaggio M MD5 Esempio PGP 2.6: firma + cifratura RSA chiave privata del mittente M+F + ZIP IDEA K M chiave di messaggio {M+F}+{K M } + RSA { K M } chiave pubblica del destinatario B64 PGP - certificazione delle chiavi PGP web of trust ogni certificato contiene la firma di tutti coloro che si fidano del proprietario la fiducia si propaga transitivamente con un certo grado di approssimazione: completely partially untrusted unknown? D C A B E YOU H F G I L M N X completely trusted partially trusted untrusted unknown Y firma X Y Antonio Lioy - Politecnico di Torino ( ) 7

8 PGP - distribuzione delle chiavi le chiavi sono conservate personalmente da ogni utente ( key-ring ) le chiavi sono distribuite direttamente dal proprietario (PGP party!) o dai key-server (http, smtp, finger) progetti per distribuire le chiavi mediante X.500 o DNS ( pgp.net ): keys.pgp.net ftp.pgp.net 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 integrazione in molti mailer tentativo di imporlo nel mercato corporate: pseudo-ca (=super-firmatario) accettazione del formato X.509 (set 98) agosto 2002: diritti ceduti a PGP Co. Gnu Privacy Guard (GPG) PGP non è più freeware (!) e non esiste per Linux (!!) GPG = riscrittura di PGP sotto licenza GPL e priva di algoritmi brevettati interopera con messaggi PGP 2.x (con qualche difficoltà) 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) varie codifiche dei dati alfabeti non-usa righe lunghe dati binari MIME formato recursivo ogni parte può essere un oggetto multipart formato multipart parti distinte parti di tipo diverso Posta elettronica multimediale sicura (MOSS o S/MIME) firma digitale / cifratura con certificati X.509v3 protegge messaggi MIME firmato testo tabella Excel docum. Word firma digitale in formato S/MIME firmato e cifrato testo tabella Excel docum. Word firma digitale in formato S/MIME busta cifrata in formato S/MIME cifrato testo tabella Excel docum. Word busta cifrata in formato S/MIME RFC-1847 estensioni MIME per la sicurezza dei messaggi per la firma digitale: Content-Type: multipart/signed; protocol="type/stype"; micalg="..."; boundary="..." con due body part: quella da proteggere (content-type:...) la firma (content-type: TYPE/STYPE) rischioso se un gateway altera il messaggio Antonio Lioy - Politecnico di Torino ( ) 8

9 S/MIME sicurezza di messaggi MIME promosso da RSA v2 pubblicato come serie di informational RFC: RFC-2311 S/MIME v2 message specification RFC-2312 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/MIME v3 certificate handling RFC-2634 Enhanced Security Services for S/MIME RFC-2314 PKCS-10: certification request syntax v.1-5 RFC-2630 CMS (Cryptographic Message Syntax) RFC-2634 Enhanced Security Services for S/MIME indirizza le seguenti aree: firma per ricevuta di un documento security label mailing-list sicure firma degli attributi dei certificati Architettura di S/MIME Architetturalmente è basato su: PKCS-7 (S/MIME v2) CMS (S/MIME v3) specifica le caratteristiche crittografiche ed i tipi di messaggi (equivalente al PEM) PKCS-10 formato della richiesta di certificato X.509 formato dei certificati a chiave pubblica S/MIME: algoritmi message digest: SHA-1 (preferito), MD5 firma digitale: DSS (obbligatorio) digest + RSA scambio chiavi: 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 è all interno della busta PKCS-7 msg. che contengono solo una chiave pubblica (= certificato; formato PKCS-7 signeddata "degenerato", ossia con dati nulli) estensione standard:.p7m sempre codificato in base64 Antonio Lioy - Politecnico di Torino ( ) 9

10 multipart/signed MIME type messaggi firmati destinati anche ad utenti non S/MIME (clear-signed) il messaggio resta in chiaro l ultima parte MIME è la firma (da RFC-1847) la parte di firma ha estensione standard.p7s ed è codificata in base64 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" -----aaaaa Content-Type: text/plain Content-Transfer-Encoding: 7bit Ciao! -----aaaaa Content-Type: application/pkcs7-signature Content-Transfer-Encoding: base64 MIIN2QasDDSdwe/625dBxgdhdsf76rHfrJe65a4f fvvsw2q1ed+sfds543sdwe6+25dbxfder0edsrs aaaaa- Naming in S/MIME Protocolli di accesso al MS per: selezionare il certificato verificare l indirizzo del mittente in S/MIMEv2 consigliato = 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 MUA autenticazione dell utente autenticazione del server riservatezza/integrità della posta sul server durante il trasferimento Post Office Protocolli di accesso al MS Esempio POP-3 POP (Post-Office Protocol) POP-2 (RFC-937), POP-3 (RFC-1939) autenticazione dell utente mediante password in chiaro (!!!) APOP autenticazione dell utente mediante sfida K-POP mutua autenticazione grazie ai ticket IMAP (Internet Mail Access Protocol) username e password in chiaro può usare OTP, Kerberos o GSS-API telnet pop.polito.it 110 +OK POP3 server ready < @pop.polito.it> USER lioy +OK password required for lioy PASS antonio +OK lioy mailbox locked and ready STAT +OK QUIT +OK POP3 server signing off Antonio Lioy - Politecnico di Torino ( ) 10

11 APOP comando APOP sostituisce la coppia di comandi USER + PASS la sfida è la parte della riga di hello tra parentesi acute <... > (parentesi 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 < @pop.polito.it> APOP lioy 36a0b36131b abd6a041ff +OK lioy mailbox locked and ready STAT +OK QUIT +OK POP3 server signing off Sicurezza di IMAP per default autenticazione debole LOGIN user password autenticazione forte: AUTHENTICATE KERBEROS_V4 AUTHENTICATE GSSAPI AUTHENTICATE SKEY mutua autenticazione solo se si usa Kerberos 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: STARTTLS per IMAP e ACAP STLS per POP3 client e server devono poter essere configurati per rifiutare user e password client confronta identità del certificato con l identità del server Porte separate per SSL/TLS? sconsigliate da IETF per i seguenti motivi: implicano URL diverse (es. http e https) implicano un modello sicuro / insicuro non corretto (es. è sicuro SSL a 40 bit? è non sicura un applicazione senza SSL ma con SASL?) non facile implementare usa 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 Antonio Lioy - Politecnico di Torino ( ) 11