Tesi laurea triennale Peter Vogric

1. Laurea triennale in Ingegneria Elettronica ed Informatica
Summary of
“Neither Snow Nor Rain Nor MITM... An Empirical
Analysis of Email Delivery Security”
Laureando: Peter Vogric Relatore: prof. Alberto Bartoli
Anno Accademico 2019/2020

2. Indice degli argomenti
1. Introduzione
2. Argomenti di analisi
3. Analisi dei dati
- Gmail ed altri popolari gestori di posta elettronica
- “Alexa Top Million domains”
- Sperimentazione software
4. Attacchi al protocollo SMTP
5. Conclusione
6. Fonti

3. 1. Introduzione
Tramite la posta elettronica vengono spesso condivise informazioni personali ed altri dati
sensibili. Gli utenti ripongono la loro fiducia nei gestori di tali servizi, dando per scontato che
i messaggi rimangano privati ed inaccessibili agli altri. In realtà, il protocollo SMTP utilizzato
per l’invio di posta elettronica, non garantisce affatto questa sicurezza. Quest’ultima viene
infatti gestita dalle varie estensioni aggiunte successivamente, che però non sono
obbligatoriamente presenti su ogni server di posta elettronica.
Tramite questo documento si vuole misurare il tasso d’adozione delle estensioni di
sicurezza applicate al protocollo SMTP e l’impatto di esse nell’utilizzo degli utenti finali. I
dati in possesso si basano sulla posta elettronica scambiata con i server Gmail tra gennaio
2014 e aprile 2015. Inoltre sono stati presi in considerazione i server SMTP dalla classifica
“Alexa Top Million domains”[1], un campione dei domini più popolari per un totale di un
milione di indirizzi diversi.
Negli scorsi anni sono stati svolti tre lavori simili a quello presentato in questo documento.
Di particolare rilievo sono gli studi svolti da Facebook, Foster e Sean Rijs, indicati nelle fonti
in fondo al documento.
La scarsa presenza di queste estensioni e dell’utilizzo della crittografia, permettono ai
malintenzionati di intercettare e sorvegliare la posta elettronica. Basandosi sui dati presi in
considerazione, si vuole discutere della sicurezza del trasporto di posta elettronica,
proponendo nuove metodologie di sviluppo per la ricerca futura.
2. Argomenti di analisi
SMTP (Simple Mail Transfer Protocol) permette di inviare messaggi di posta elettronica da
un server ad un altro. Essendo un protocollo risalente al 1981, di base esso non possiede
alcuna misura di sicurezza, permettendo a chiunque di accedere ai messaggi scambiati
senza troppo impegno. In seguito sono state fortunatamente aggiunte delle estensioni di
sicurezza come START-TLS, DKIM, DMARC e SPF per criptare i messaggi e autenticare i
mittenti.
START-TLS è nato per proteggere il messaggio di posta elettronica durante il tragitto tra i
vari server SMTP. L’estensione lavora emulando SMTP in una sessione TLS (Transport
Layer Security) e protegge il messaggio con l’utilizzo della crittografia. Il problema sorge
quando uno degli intermediari nel tragitto dal mittente al destinatario non supporta questo
protocollo di sicurezza. In questo caso infatti, il messaggio viene convertito e trasferito in
chiaro verso il server successivo.
Oltre alla sicurezza durante il tragitto, i server di posta elettronica adottano varie estensioni
per verificare l’integrità di una mail ricevuta. Così facendo, è possibile rilevare se il
messaggio sia stato aperto o modificato durante il percorso dal mittente al destinatario. In
seguito vengono citate alcune delle estensioni comuni:

4. - DKIM (DomainKeys Identifield Mail): conferma l’integrità di un messaggio e può essere
usata come complemento con la SPF. L’83% della posta elettronica ricevuta da Gmail
nell’aprile 2015 conteneva questa estensione di sicurezza.
- SPF (Sender Policy Framework): verifica se il messaggio in entrata proviene da una
lista di indirizzi IP considerati sicuri. Gmail supporta pienamente questa estensione,
mentre solamente il 47% degli “Alexa Top million domains” possiedono la SPF.
- DMARC (Domain-based Message Autenthication): oltre ad includere le protezioni offerte
da DKIM e SPF, informa il destinatario su come trattare i messaggi che non sono stati
validati con la DMARC. Solamente il 26% dei messaggi ricevuti da Gmail contiene
questa protezione. La situazione peggiora ulteriormente quando si considera gli altri
domini selezionati nella “Alexa Top million domains”, dove l’estensione è presente nel
1.1% dei messaggi ricevuti.
3. Analisi dei dati
Sono stati quindi misurati i dati sulla confidenzialità della posta elettronica, basandosi sul
volume di messaggi ricevuti ed inviati tramite START-TLS.
- Gmail ed altri popolari gestori di posta elettronica
START-TLS viene utilizzato per l’80% dei messaggi in uscita ed il 60% dei messaggi in
entrata dai server Gmail. L’aumento in un anno è stato notevole (54% in uscita e 82% in
entrata), dove ha sicuramente influito l’adozione dell’estensione TLS di numerosi gestori
di posta elettronica di spessore come Yahoo e Outlook. A confermare i dati ottenuti su
Gmail ci sono quelli diffusi da Facebook. Nello stesso periodo di tempo il social network
ha infatti registrato un aumento simile di mail di notifica rispetto al passato, inviate
utilizzando START-TLS.
La maggior parte del traffico di posta elettronica proviene da un piccolo insieme di
server. Per questo motivo sono stati selezionati i 19 gestori di posta elettronica più
popolari, presso i quali è stato registrato un nuovo account utente. Successivamente è
stato configurato un server di posta che supporta il START-TLS, per verificare quanti dei
gestori più popolari avrebbero adottato questa estensione di sicurezza comunicando
con il server appena creato.
Solamente un gestore (Lycos) non supporta START-TLS in entrata. Nessuno degli altri
gestori di posta elettronica possiede un certificato contenente il loro stesso dominio,
quindi nessuno di essi poteva utilizzare un’autenticazione sicura in presenza di un
malintenzionato in grado di falsificare l’indirizzo di posta elettronica.

5. - “Alexa Top Million domains”
Analizzando invece i dati relativi al milione di domini secondo “Alexa Top Million
domains”, l’81,8% di essi utilizza l’estensione TLS. Il 25% di questi domini si affida
direttamente ai servizi sicuri come Gmail per la gestione della posta elettronica. La
maggior parte di essi usa chiavi di cifratura da 2048 bit, mentre solamente due server
non le utilizzano affatto. Per utilizzare START-TLS, ogni server mail deve possedere un
certificato X.509, che contiene le informazioni sul dominio del server sul quale viene
utilizzato. Il 18,1% dei domini considerati hanno un certificato che non contiene
l’indirizzo dello stesso dominio, rendendolo così un servizio meno sicuro.
- Sperimentazione software
Per capire meglio come mai START-TLS non viene ancora usato a dovere, si è fatto
uso delle cinque più popolari implementazioni di SMTP su un una macchina con Ubuntu
14.04 LTS. Questi sistemi vengono utilizzati sul 97% dei server mail presenti nella lista
“Alexa Top Million domains” e quindi rappresentano un campione valido per lo scopo
dell’analisi.
Exim 4.82, presente sul 34% dei domini considerati supporta START-TLS solamente in
uscita, in entrata non è attivo di default. La validazione del server e dominio nei
certificati è completamente assente. Postfix 2.11.10, utilizzato sul 18% dei server di
posta elettronica, ha invece il STARTTLS attivo di default solamente sulla posta di
entrata, ma non su quella in uscita. Supporta però la validazione del server e dominio
nei certificati, ma non è attivo di default. Altri esempi si possono notare nella tabella
soprastante.
I risultati dimostrano come l’adozione di START-TLS sia nettamente cresciuta nell’ultimo
anno. La crescita però viene attribuita principalmente ai gestori di posta elettronica più
utilizzati. Circa la metà dei server mail non dispone di questa estensione di sicurezza,
impedendo al messaggio protetto da crittografia di proseguire in maniera sicura.

6. 4. Attacchi al protocollo SMTP
Successivamente sono state sperimentato due tipologie di attacco alla rete, per cercare di
superare le misure di sicurezza applicate al protocollo SMTP. In particolare si è fatto uso
dello START-TLS Corruption e del DNS Hijacking.
Manipolando i pacchetti per l’inizializzazione della sessione START-TLS è possibile
compromettere la sua attivazione, per poter monitorare il traffico SMTP senza crittografia. I
risultati ottenuti dal test effettuato non sono molto uniformi e variano da stato a stato, ma i
dati confermano una grande frequenza di STARTTLS “stripping” (tabella sottostante). E’
importante evidenziare che effettuare lo “stripping” non è necessariamente attribuito ad un
attacco malevolo. Può infatti rappresentare un semplice e legittimo filtraggio del traffico di
posta elettronica.
Invece di attaccare direttamente il protocollo SMTP è possibile prendere di mira la
sicurezza dei server DNS. Cambiando il registro di un server DNS è possibile reindirizzare il
traffico di posta elettronica su un server controllato dall’utente malintenzionato. Nel test
svolto circa il 2% dei server DNS pubblici hanno risposto alle richieste inoltrate da
gmail.com, yahoo.com ed altri tre popolari server SMTP con un indirizzo IP non valido.
Entrambe le tipologie d’attacco, malevole o meno, evidenziano come la mancata apertura
di una sessione START-TSL può portare ad un elevato numero di rischi all’interno della
rete.

7. 5. Conclusione
I miglioramenti nell’ambito della sicurezza del protocollo SMTP, attribuiti alle estensioni START-
TLS, SPF, DKIM e DMARC sono stati notevoli negli ultimi anni, grazie soprattutto al lavoro svolto
dai maggiori gestori di posta elettronica. Molti però non si sono ancora mossi in questa direzione,
lasciando gli utenti esposti a potenziali attacchi. Si spera che il lavoro svolto in questa analisi
sproni le aziende a migliorare i propri servizi di posta elettronica in modo da avere una maggiore
sicurezza per gli utenti.
Il funzionamento e l’efficacia delle estensioni di sicurezza dipende molto dalla loro diffusione e
raggiunge l’apice solamente quanto tutti i server le adottano. Mancano però ancora diverse
tecnologie, che potrebbero ulteriormente migliorare la gestione della sicurezza. Non esiste, per
esempio, un meccanismo che obbliga la mail a proseguire all’interno della rete, solamente lungo
un tragitto protetto da TLS, similmente a quanto accade con HTTPS. Allo stesso modo non è
ancora presente un metodo di verifica della veridicità del server di provenienza del messaggio di
posta elettronica, dovuto alle potenziali manomissioni dei server DNS. Nemmeno la tecnologia di
crittografia end-to-end non potrebbe aiutare, in quanto, i dati del mittente e destinatario
andrebbero comunque condivisi in chiaro.
6. Fonti
Fonte principale: http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf
Fonti specifiche: [1] Alexa Internet, Inc. Alexa Top 1,000,000 Sites. http://s3.amazonaws.com/alexa-static/top-1m.csv.zip. [2] N. J.
AlFardan, D. J. Bernstein, K. G. Paterson, B. Poettering, and J. C. Schuldt. On the security of RC4 in TLS. In 22nd USENIX Security Symposium,
pages 305–320, Aug. 2013.
[3] B. Arkin. Adobe important customer security announcement, Oct. 2013. http://blogs.adobe.com/conversations/2013/10/ important-customer-
security-announcement.html. [4] J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and R. Thayerj. OpenPGP message format. RFC 4880, 2007.
https://www.ietf.org/rfc/rfc4880.txt. [5] D. Campbell. Update on security incident and additional security measures, 2015. https://sendgrid.com/blog/
update-on-security-incident-and-additional-security-measures/. [6] Certificate Transparency, 2015. http://www.certificate-transparency.org/. [7]
Cisco. Cisco ASA 5500-X series next-generation firewalls, 2015. http://www.cisco.com/c/en/us/products/security/ asa-5500-series-next-generation-
firewalls/index.html. [8] Cisco. Cisco IOS Firewall, 2015. http://www.cisco.com/c/en/us/ products/security/ios-firewall/index.html. [9] Cisco. SMTP
and ESMTP inspection overview, 2015. http:// www.cisco.com/c/en/us/td/docs/security/asa/asa93/configuration/ firewall/asa-firewall-cli/inspect-
basic.html#pgfId-2490137. [10] L. Constantin. Yahoo email anti-spoofing policy breaks mailing lists, 2014. http://www.pcworld.com/article/2141120/
yahoo-email-antispoofing-policy-breaks-mailing-lists.html. [11] D. Crocker, T. Hansen, and M. Kucherawy. DomainKeys Identified Mail (DKIM)
signatures. RFC 6379, Sept. 2011. https://tools.ietf.org/html/rfc6376. [12] D. Crocker and T. Zink. M3AAWG trust in email begins with
authentication, 2015. https://www.m3aawg.org/sites/maawg/files/ news/M3AAWG_Email_Authentication_Update-2015.pdf. [13] H. Duan, N.
Weaver, Z. Zhao, M. Hu, J. Liang, J. Jiang, K. Li, and V. Paxson. Hold-on: Protecting against on-path DNS poisoning. In Workshop on Securing and
Trusting Internet Names, 2012. [14] V. Dukhovni and W. Hardaker. SMTP security via opportunistic DANE TLS, July 2013.
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-12. [15] Z. Durumeric, D. Adrian, J. Kasten, D. Springall, M. Bailey, and J. A. Halderman.
POODLE attack and SSLv3 deployment, 2014. https://poodle.io. [16] Z. Durumeric, D. Adrian, A. Mirian, M. Bailey, and J. A. Halderman. A search
engine backed by Internet-wide scanning. In 22nd ACM Conference on Computer and Communications Security, Oct. 2015. [17] Z. Durumeric, M.
Bailey, and J. A. Halderman. An Internet-wide view of Internet-wide scanning. In 23rd USENIX Security Symposium, Aug. 2014. [18] Z. Durumeric,
J. Kasten, M. Bailey, and J. A. Halderman. Analysis of the HTTPS certificate ecosystem. In 13th ACM Internet Measurement Conference, Oct.
2013. [19] Z. Durumeric, E. Wustrow, and J. A. Halderman. ZMap: Fast Internet-wide scanning and its security applications. In 22nd USENIX
Security Symposium, Aug. 2013. [20] P. Eckersley and J. Burns. An observatory for the SSLiverse. Talk at Defcon 18 (2010).
https://www.eff.org/files/DefconSSLiverse.pdf. [21] C. Evans, C. Palmer, and R. Sleevi. Public key pinning extension for HTTP. RFC 7469, 2015.
http://tools.ietf.org/html/rfc7469. [22] Facebook. The current state of SMTP STARTTLS deployment, May 2014.
https://www.facebook.com/notes/protect-the-graph/ the-current-state-of-smtp-starttls-deployment/1453015901605223/. [23] Facebook. Massive
growth in SMTP STARTTLS deployment, Aug. 2014. https://www.facebook.com/notes/protect-the-graph/ massive-growth-in-smtp-starttls-
deployment/1491049534468526. [24] I. Foster, J. Larson, M. Masich, A. Snoeren, S. Savage, and K. Levchenko. Security by any other name: On
the effectiveness of provider based email security. In 22nd ACM Conference on Computer and Communications Security, Oct. 2015. [25] Golden
Frog. The FCC must prevent ISPs from blocking encryption. http://www.goldenfrog.com/blog/ fcc-must-prevent-isps-blocking-encryption. [26] N.
Heninger. Factoring as a service. Rump session talk, Crypto 2013. [27] N. Heninger, Z. Durumeric, E. Wustrow, and J. A. Halderman. Mining your
Ps and Qs: Detection of widespread weak keys in network devices. In 21st USENIX Security Symposium, Aug. 2012.38

8. [28] P. Hoffman. SMTP service extension for secure SMTP over transport layer security. RFC 3207, Feb. 2002. http://www.ietf.org/rfc/rfc3207.txt.
[29] J. Hoffman-Andrews. Isps removing their customers’ email encryption. https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks. [30]
J. Hoffman-Andrews and P. Eckersley. STARTTLS everywhere, June 2014. https://github.com/EFForg/starttls-everywhere. [31] R. Holz, L. Braun,
N. Kammenhuber, and G. Carle. The SSL landscape: A thorough analysis of the X.509 PKI using active and passive measurements. In 11th ACM
Internet Measurement Conference, 2011. [32] L.-S. Huang, S. Adhikarla, D. Boneh, and C. Jackson. An experimental study of TLS forward secrecy
deployments. In Web 2.0 Security and Privacy (W2SP), 2014. [33] S. Kitterman. Sender policy framework (SPF) for authorizing use of domains in
email. RFC 7208, Apr. 2014. http://tools.ietf.org/html/rfc7208. [34] J. Klensin. Simple mail transfer protocol. RFC 5321, Oct. 2008.
http://tools.ietf.org/html/rfc5321. [35] M. Kucherawy and E. Zwicky. Domain-based message authentication, reporting, and conformance (DMARC).
RFC 7489, Mar. 2015. https://tools.ietf.org/html/rfc7489. [36] G. Lowe, P. Winters, and M. L. Marcus. The great DNS wall of China. Technical
report, New York University, Dec. 2007. http://cs.nyu.edu/~pcw216/work/nds/final.pdf.
[37] Microsoft. TLS functionality and related terminology, June 2014. http://technet.microsoft.com/en-us/library/
bb430753%28v=exchg.150%29.aspx. [38] Mozilla Developer Network. Mozilla Network Security Services (NSS).
http://www.mozilla.org/projects/security/pki/nss/. [39] Z. Nabi. The anatomy of web censorship in Pakistan. arXiv preprint arXiv:1307.1144, 2013.
[40] J. B. Postel. Simple mail transfer protocol. RFC 821, Aug. 1982. [41] http://www.postfix.org/postconf.5.html#smtp_tls_security_level. [42] B.
Ramsdell and S. Turner. Secure/multipurpose Internet mail extensions (S/MIME) version 3.2 message specification. RFC 5751, 2010.
https://tools.ietf.org/html/rfc5751. [43] S. Rijs and M. van der Meer. The state of StartTLS, June 2014. https:// caldav.os3.nl/_media/2013-
2014/courses/ot/magiel_sean2.pdf. [44] Telecom Asia. Google, Yahoo SMTP email severs hit in thailand. http://www.telecomasia.net/content/
google-yahoo-smtp-email-severs-hit-thailand. [45] M. Vanhoef and F. Piessens. All your biases belong to us: Breaking RC4 in WPA-TKIP and TLS.
In 24th USENIX Security Symposium, Aug. 2015. [46] Verisign Labs. DNSSEC scoreboard, 2015. http://scoreboard.verisignlabs.com/. [47] J.-P.
Verkamp and M. Gupta. Inferring mechanics of web censorship around the world. 3rd USENIX Workshop on Free and Open Communications on
the Internet (FOCI), Aug. 20