Antonio Lioy < 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) E-mail in client-server SMTP Mailserver ( MSA ) SMTP MTA... MUA (es. Thunderbird, Outlook Express) POP, IMAP Post Office ( MS ) SMTP... MTA Antonio Lioy - Politecnico di Torino (1995-2018) 1
Webmail Mailserver ( MSA ) SMTP SMTP MTA... web browser HTTP HTML web server HTTP engine POP / IMAP virtual MUA Post Office ( MS ) SMTP... MTA 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 (1995-2018) 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 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 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 Antonio Lioy - Politecnico di Torino (1995-2018) 3
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 E-mail) o UCE (Unsolicited Commercial E-mail) 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 (1995-2018) 4
(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? 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 127.0.0.X (ove X è un codice che indica perché è elencato) un record TXT per maggiori informazioni RFC-5782 DNS blacklists and whitelists Antonio Lioy - Politecnico di Torino (1995-2018) 5
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 (1995-2018) 6
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:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16?all" 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 Antonio Lioy - Politecnico di Torino (1995-2018) 7
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 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 2017 https://cyber.dhs.gov/ 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 (1995-2018) 8
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 26214400 250 8BITMIME 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 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 Antonio Lioy - Politecnico di Torino (1995-2018) 9
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 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 (1995-2018) 10
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 <69.2012010320105807@x.polito.it> 250 AUTH CRAM-MD5 DIGEST-MD5 AUTH CRAM-MD5 334 PDY5LjIwMTIwMTAzMjAxMDU4MDdAeC5wb2xpdG8uaXQ+ bglvesa1mguxnjjizdc5ngzjndnjzmm1zjk1mzq1ndi3mja5nw== 235 Authentication successful lioy hmac(antonio,<69.2012010320105807@x.polito.it>) hex 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) Antonio Lioy - Politecnico di Torino (1995-2018) 11
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 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 } Analisi di SCRAM mutua autenticazione 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 (1995-2018) 12
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 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) Antonio Lioy - Politecnico di Torino (1995-2018) 13
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 Servizi di sicurezza per messaggi di e-mail 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 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 nessuna modifica agli attuali UA interfaccia utente scomoda con modifica agli attuali UA interfaccia utente migliore Antonio Lioy - Politecnico di Torino (1995-2018) 14
Sicurezza dell e-mail - 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(s) codifica per evitare alterazioni da parte degli MTA tipicamente: base64 (vecchi: uuencode, binhex) Antonio Lioy - Politecnico di Torino (1995-2018) 15
Formati di posta elettronica sicura IETF underground DOD + EU PEM PGP X.400 MOSS MIME-PGP X.421 S/MIME 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 (1995-2018) 16
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 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 ): www.pgp.net keys.pgp.net ftp.pgp.net Antonio Lioy - Politecnico di Torino (1995-2018) 17
MIME (Multipurpose Internet Mail Extensions) MIME varie codifiche dei dati alfabeti non-usa righe lunghe dati binari 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 (1995-2018) 18
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: 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 Antonio Lioy - Politecnico di Torino (1995-2018) 19
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 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 (1995-2018) 20
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 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 Antonio Lioy - Politecnico di Torino (1995-2018) 21
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+25dbxfder0edsrs5 -----aaaaa- Naming in S/MIME per: selezionare il certificato 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 autenticazione dell utente autenticazione del server riservatezza/integrità della posta sul server durante il trasferimento Antonio Lioy - Politecnico di Torino (1995-2018) 22
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 <7831.84549@pop.polito.it> USER lioy +OK password required for lioy PASS antonio +OK lioy mailbox locked and ready STAT +OK 2 320... QUIT +OK POP3 server signing off 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 Antonio Lioy - Politecnico di Torino (1995-2018) 23
Esempio APOP telnet pop.polito.it 110 +OK POP3 server ready <7831.84549@pop.polito.it> APOP lioy 36a0b36131b82474300846abd6a041ff +OK lioy mailbox locked and ready STAT +OK 2 320... QUIT +OK POP3 server signing off 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 (1995-2018) 24