Sicurezza della posta elettronica MHS (Message Handling

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