Sicurezza della posta elettronica

Transcript

1 Antonio Lioy < polito.it> Politecnico di Torino Dip. Automatica e Informatica MHS (Message Handling System) MTA MSA MTA chain MTA MSA MS MS MUA MUA MUA (Message User Agent) MSA (Message Submission Agent) MTA (Message Transfer Agent) MS (Message Store) Antonio Lioy - Politecnico di Torino ( ) 1

2 in client-server SMTP Mailserver ( MSA ) SMTP MTA... MUA (es. Thunderbird, Outlook Express) POP, IMAP Post Office ( MS ) SMTP... MTA Webmail Mailserver ( MSA ) SMTP MTA... web browser HTTP HTML web server HTTP engine SMTP POP / IMAP virtual MUA Post Office ( MS ) SMTP... MTA Antonio Lioy - Politecnico di Torino ( ) 2

3 Protocolli, porte e formati standard SMTP (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 ( ) 3

4 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 SMTP / 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 Antonio Lioy - Politecnico di Torino ( ) 4

5 From: (Antonio Lioy) To: 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 Antonio Lioy - Politecnico di Torino ( ) 5

6 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 ( ) 6

7 (Open) mail relay polito.it outgoing mail incoming mail polito.it 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 problema con nodi mobili, IP spoofing e malware (installato su un nodo valido) valore del campo From aggirabile facilmente con fake mail autenticazione SMTP metodi sicuri? Antonio Lioy - Politecnico di Torino ( ) 7

8 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 Antonio Lioy - Politecnico di Torino ( ) 8

9 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 ( ) 9

10 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" Antonio Lioy - Politecnico di Torino ( ) 10

11 Anti-spam per incoming MTA (VI) DMARC (Domain-based Message Authentication, Reporting and Conformance) PayPal, Yahoo!, Gmail ed altri principi guida: mittenti scelgono di supportare DMARC pubblicando la loro policy riceventi forniscono feedback così i mittenti possono migliorare e chiudere le falle mittenti aumentano il numero di mail autenticate riceventi possono identificare e bloccare mail non autenticate DMARC sovrastruttura che sfrutta DKIM e SPF le firme DKIM possono funzionare nei casi in cui SPF fallisce SPF può funzionare quando il mittente sbaglia temporaneamente DKIM permette di specificare asserzioni per mettere in quarantena o bloccare mail non autenticate fornisce molte statistiche ed informazioni di dettaglio DMARC OK se anche DKIM o SPF lo sono, ma ci sono requisiti aggiuntivi su DKIM e SPF cosicché DKIM/SPF OK non implica DMARC OK Antonio Lioy - Politecnico di Torino ( ) 11

12 DMARC DMARC migliora DKIM/SPF ma ci sono ancora problemi con mail indirette (es. relay, mailing-list) in ogni caso DMARC è richiesto per tutti gli enti federali USA BOD (Binding Operational Directive) 18-01, ottobre miglioramento sicurezza mail e web no SSL2, SSL3, 3DES, RC4 STARTLS, SPF, DMARC HTTPS-only with HSTS ESMTP Extended SMTP, definito in RFC-1869 e quindi incorporato (con SMTP) in RFC-2821 non cambia il protocollo base ed il canale i client ESMTP devono presentarsi con: EHLO hostname se il server ricevente parla ESMTP, deve dichiarare le estensioni che supporta, una per riga, nella sua risposta all EHLO Antonio Lioy - Politecnico di Torino ( ) 12

13 Esempi ESMTP positivi mailer ESMTP senza estensioni: 220 mail.polito.it - SMTP service ready EHLO mailer.x.com 250 Hello mailer.x.com - nice to meet you! mailer ESMTP con estensioni: 220 mail.polito.it - SMTP service ready EHLO mailer.x.com 250-Hello mailer.x.com - nice to meet you! 250-SIZE BITMIME Esempio ESMTP negativo il mailer non conosce il protocollo ESMTP: 220 mail.polito.it - SMTP service ready EHLO mailer.x.com 500 Command not recognized: EHLO Antonio Lioy - Politecnico di Torino ( ) 13

14 SMTP-Auth estensione di ESMTP 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 Esempio AUTH negativo il mailer non conosce (o non accetta) la modalità di autenticazione proposta dal client: 220 example.polito.it - SMTP service ready EHLO mailer.x.com 250-example.polito.it 250 AUTH LOGIN CRAM-MD5 DIGEST-MD5 AUTH PLAIN 504 Unrecognized authentication type Antonio Lioy - Politecnico di Torino ( ) 14

15 AUTH: metodo LOGIN 220 example.polito.it - SMTP service ready EHLO mailer.x.com 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 - SMTP service ready EHLO mailer.x.com 250-example.polito.it 250 AUTH LOGIN PLAIN AUTH PLAIN bglveqbsaw95agfudg9uaw8= 235 authenticated lioy \0 lioy \0 antonio Antonio Lioy - Politecnico di Torino ( ) 15

16 AUTH: metodi challenge-response CRAM MD5 RFC-2195 challenge = base64 ( nonce ) response = base64 ( usr SP hmac-md5( pwd, nonce) LHEX ) DIGEST MD5 RFC-2831 simile a digest-authentication di HTTP/1.1 dichiarato obsoleto da RFC-6331 (2011) e rimpiazzato con SCRAM AUTH: metodo CRAM-MD5 220 x.polito.it - SMTP service ready EHLO mailer.x.com 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 Antonio Lioy - Politecnico di Torino ( ) 16

17 vantaggi: Analisi di CRAM-MD5 autenticazione del client (password) no replay (challenge = rnd + timestamp + FQDN) resistente allo sniffing (hash non invertibile) svantaggi: no autenticazione del server (ma OK se su TLS) memorizzazione della pwd in chiaro, a meno di memorizzare i passi intermedi di HMAC (ossia K' opad e K' ipad) possibili attacchi dizionario possibile MITM (controllo del canale dopo CRAM) SCRAM Salted Challenge-Response Authentication Method RFC-5802 e RFC-7677 si sceglie funzione di hash h con output =hlen si calcola un hash della pwd con sale e iterazioni spwd = PBKDF2 (HMAC-h, pwd, salt, itc, hlen) scambio client-server cfirst = gs2-cbind-flag, usr, cnonce sfirst = salt, itc, cnonce, snonce cfinal = cbind-input, cnonce, snonce, cproof sfinal = sproof Antonio Lioy - Politecnico di Torino ( ) 17

18 SCRAM client e server calcolano lo stesso autenticatore auth = cfirst, sfirst, cfinalnoproof e ne dimostrano conoscenza tramite una prova incrociata ckey = HMAC-h (spwd, "Client key") skey = HMAC-h (spwd, "Server key") cproof = ckey HMAC-h( h(ckey), auth ) sproof = HMAC-h( skey, auth ) per ogni utente il server conserva { usr, h(ckey), salt, itc, skey } mutua autenticazione Analisi di SCRAM difficile gli attacchi al DB delle pwd (hash, salt, itc) semplice da implementare internazionalizzazione (usr & pwd sono UTF-8) il client può conservare spwd invece che la pwd in chiaro resistente agli attacchi brute-force legata ad uno specifico servizio (se la stessa pwd è usata per altri servizi genererà spwd diverse) permette il channel binding Antonio Lioy - Politecnico di Torino ( ) 18

19 Channel Binding (CB) associare un canale sicuro (tipicamente cifrato) ad uno scambio applicativo che offre mutua autenticazione per evitare MITM che sia end-point per il canale cifrato ma poi intercetti tutto il dialogo applicativo due classi principali: unique (uso di uno specifico canale) tls-unique tls-unique-for-server end-point (stesso end-point per il canale sicuro e quello applicativo) tls-server-end-point (binding col server cert) Channel Binding (CB) il server dichiara i metodi SCRAM che supporta normali (es. SCRAM-SHA-1) con CB (es. SCRAM-SHA-1-PLUS) gs2-cbind-flag n : client non supporta CB y : client supporta CB ma pensa che il server non lo supporti (usato per prevenire attacchi di downgrade) p=cb_method : client richiede lo specifico CB cbind-input : SCRAM [ + channel_data ] channel_data solo se il client aveva richiesto CB Antonio Lioy - Politecnico di Torino ( ) 19

20 Protezione di SMTP con TLS RFC-2487 SMTP Service Extension for Secure SMTP 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 SMTP con TLS: esempio 220 example.polito.it - SMTP service ready EHLO mailer.x.com 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 ( ) 20

21 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 Antonio Lioy - Politecnico di Torino ( ) 21

22 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 Antonio Lioy - Politecnico di Torino ( ) 22

23 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(s) 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 ( ) 23

24 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. non più open-source e non disponibile per Linux! Antonio Lioy - Politecnico di Torino ( ) 24

25 PGP - certificazione delle chiavi 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 PGP web of trust E F M C? B YOU G L D A H I N X completely trusted partially trusted untrusted unknown Y firma X Y Antonio Lioy - Politecnico di Torino ( ) 25

26 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 MIME (Multipurpose Internet Mail Extensions) MIME varie codifiche dei dati alfabeti non-usa righe lunghe dati binari formato multipart formato recursivo ogni parte può essere un oggetto multipart parti distinte parti di tipo diverso Antonio Lioy - Politecnico di Torino ( ) 26

27 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 ( ) 27

28 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) Antonio Lioy - Politecnico di Torino ( ) 28

29 RFC-2634 Enhanced Security Services for S/MIME indirizza le seguenti aree: signed receipt firma per ricevuta di un documento security label classificazione di sicurezza dei messaggi secure mailing list gestione di mailing-list sicure signing certificate inclusione del certificato di firma tra gli attributi firmati del messaggio 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 Antonio Lioy - Politecnico di Torino ( ) 29

30 S/MIME v3.2 algoritmi firma digitale: (MUST) RSA with SHA-256. (SHOULD+) DSA with SHA-256 (SHOULD+) RSASSA-PSS with SHA-256 (SHOULD ) RSA with SHA-1 (SHOULD ) DSA with SHA-1 (SHOULD ) RSA with MD5 scambio chiave: (MUST) RSA encryption (SHOULD+) RSAES-OAEP (SHOULD ) DHE S/MIME v3.2 algoritmi riservatezza: (MUST) AES-128 CBC (SHOULD+) AES-192 CBC e AES-256 CBC (SHOULD ) DES EDE3 CBC micalg (dipende anche da firma digitale): MD5 SHA-1 SHA-224, SHA-256, SHA-384, SHA-512 Antonio Lioy - Politecnico di Torino ( ) 30

31 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 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 Antonio Lioy - Politecnico di Torino ( ) 31

32 Esempi S/MIME cifrato B64( P7_enveloped( msg )) firmato (solo utenti S/MIME) B64( P7_signed( msg )) firmato (generic, ossia clear-signed) MIME( msg ) + B64( P7_signed_detached( msg )) firmato e cifrato B64( P7_enveloped( P7_signed( msg ))) B64( P7_signed( P7_enveloped( msg ))) nota: msg è il body RFC-822 del messaggio 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- Antonio Lioy - Politecnico di Torino ( ) 32

33 per: Naming in S/MIME 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 Protocolli di accesso al MS Post Office MUA autenticazione dell utente autenticazione del server riservatezza/integrità della posta sul server durante il trasferimento Antonio Lioy - Politecnico di Torino ( ) 33

34 Protocolli di accesso al MS 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 Esempio POP-3 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 ( ) 34

35 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 Antonio Lioy - Politecnico di Torino ( ) 35

36 RFC-2595 (TLS per POP / IMAP) RFC-2595 Using TLS with IMAP, POP3 and ACAP prima si apre il canale applicativo 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 TLS ma con SASL?) non facile implementare usa TLS se disponibile raddoppia il numero di porte necessarie ma presentano alcuni vantaggi: semplicità di filtraggio sui firewall packet-filter TLS con client-authentication permette di non esporre le applicazioni ad attacchi Antonio Lioy - Politecnico di Torino ( ) 36