2x - Politecnico di Torino

Transcript

Sicurezza della posta elettronica
(emailsec - dec'16)
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)
© Antonio Lioy - Politecnico di Torino (1995-2016)
1
(emailsec - dec'16)
E-mail in client-server
SMTP
Mailserver
( MSA )
SMTP
MTA ...
MUA
(es. Thunderbird,
Outlook Express)
Post Office
( MS )
POP, IMAP
... MTA
SMTP
Webmail
Mailserver SMTP
( MSA )
MTA ...
SMTP
HTTP
HTML
web server
HTTP
engine
virtual
MUA
web browser
POP / IMAP
Post Office
... MTA
( MS )
SMTP
2
(emailsec - dec'16)
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
3
(emailsec - dec'16)
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
4
(emailsec - dec'16)
From: [email protected] (Antonio Lioy)
To: [email protected]
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
5
(emailsec - dec'16)
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
6
(emailsec - dec'16)
(Open) mail relay
outgoing
mail
polito.it
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?
7
(emailsec - dec'16)
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”
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
8
(emailsec - dec'16)
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
9
(emailsec - dec'16)
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"
10
(emailsec - dec'16)
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
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:
EHLO mailer.x.com
250-Hello mailer.x.com - nice to meet you!
250-SIZE 26214400
250 8BITMIME
11
(emailsec - dec'16)
Esempio ESMTP negativo

il mailer non conosce il protocollo ESMTP:
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
12
(emailsec - dec'16)
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
EHLO mailer.x.com
250 AUTH LOGIN CRAM-MD5 DIGEST-MD5
AUTH LOGIN
334 VXNlcm5hbWU6
Username:
lioy
bGlveQ==
334 UGFzc3dvcmQ6
Password:
antonio
YW50b25pbw==
235 authenticated
13
(emailsec - dec'16)
AUTH: metodo PLAIN


sintassi (RFC-2595):
AUTH PLAIN id_pwdBASE64
id_pwd è definito come:
[ authorize_id ] \0 authentication_id \0 pwd
EHLO mailer.x.com
250 AUTH LOGIN PLAIN
AUTH PLAIN bGlveQBsaW95AGFudG9uaW8=
235 authenticated
lioy \0 lioy \0 antonio
AUTH: metodi challenge-response


CRAM–MD5
 RFC-2195
 challenge = nonceBASE64
 response = 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
14
(emailsec - dec'16)
AUTH: metodo CRAM-MD5
220 x.polito.it - SMTP service ready
EHLO mailer.x.com
<[email protected]>
250-x.polito.it
250 AUTH CRAM-MD5 DIGEST-MD5
AUTH CRAM-MD5
334 PDY5LjIwMTIwMTAzMjAxMDU4MDdAeC5wb2xpdG8uaXQ+
bGlveSA1MGUxNjJiZDc5NGZjNDNjZmM1Zjk1MzQ1NDI3MjA5Nw==
235 Authentication successful
lioy hmac(antonio,<[email protected]>)hex
Analisi di CRAM-MD5


vantaggi:
 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)
15
(emailsec - dec'16)
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( h(cKey), auth )
per ogni utente il server conserva
{ usr, h(cKey), salt, itc, sKey }
16
(emailsec - dec'16)
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
Channel Binding (CB)



associare un canale sicuro (tipicamente cifrato) ad
uno scambio applicativo
… per evitare un MITM che faccia da end-point per
il canale cifrato e 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)
17
(emailsec - dec'16)
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
 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)
18
(emailsec - dec'16)
Protezione di SMTP con TLS: esempio
EHLO mailer.x.com
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
19
(emailsec - dec'16)
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
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)
20
(emailsec - dec'16)
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 } KM + { KM } Kpub_receiver
codifica
 per evitare alterazioni da parte degli MTA
 tipicamente: base64 (vecchi: uuencode, binhex)
21
(emailsec - dec'16)
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
22
(emailsec - dec'16)
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!
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 (2 partially = 1 completely)
 untrusted
 unknown
23
(emailsec - dec'16)
PGP web of trust
M
F
E
C
B
G
YOU
L
?
D
I
A
N
H
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
24
(emailsec - dec'16)
MIME
(Multipurpose Internet Mail Extensions)
MIME
varie codifiche
dei dati
formato
recursivo
– alfabeti non-USA
– righe “lunghe”
– dati binari
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
firmato e cifrato
cifrato
testo
testo
testo
tabella Excel
tabella Excel
docum. Word
docum. Word
tabella Excel
docum. Word
firma digitale in
formato S/MIME
firma digitale in
formato S/MIME
busta cifrata in
formato S/MIME
busta cifrata in
formato S/MIME
25
(emailsec - dec'16)
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
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”
26
(emailsec - dec'16)
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
27
(emailsec - dec'16)
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
28
(emailsec - dec'16)
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
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
29
(emailsec - dec'16)
MIME type

multipart/signed
 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 (generico)
 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
30
(emailsec - dec'16)
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
31
(emailsec - dec'16)
Protocolli di accesso al MS
Post Office
MUA



autenticazione dell’utente
autenticazione del server
riservatezza/integrità della posta
 sul server
 durante il trasferimento
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
32
(emailsec - dec'16)
Esempio POP-3
telnet pop.polito.it 110
+OK POP3 server ready <[email protected]>
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
33
(emailsec - dec'16)
Esempio APOP
telnet pop.polito.it 110
+OK POP3 server ready <[email protected]>
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 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
34
(emailsec - dec'16)
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
35

2x - Politecnico di Torino

Transcript

Documenti analoghi

6x - Politecnico di Torino

2x - Politecnico di Torino

Introduzione alla sicurezza delle reti e dei sistemi informativi

PUBLIC AFFAIR

Programma - PoliTOcomunica

ARBOR MTA Cod. 3649

Offerta valida per gli studenti ed i dipendenti del Politecnico di Milano

LA “FOLLE CORSA” Antonio Savoldi è un poliziotto, ma è anche

Il formato MIME - Politecnico di Torino

Note per wikipedia biografia bruno pistidda

Sicurezza della posta elettronica MHS (Message Handling

6x - Politecnico di Torino

Avviso - swas.polito.it