Quali standard di sicurezza email stiamo verificando?

La piattaforma MECSA valuta la sicurezza e la privacy offerta dai provider email verificando il loro supporto di standard che noi abbiamo identificato in una pubblicazione precedente.

1. StartTLS

Il comando StartTLS [RFC3207, RFC7817] è un’estensione di Simple Mail Transfer Protocol [RFC5321] (SMTP) utilizzato per attivare la crittografia Transport Layer Security [RFC5246] (TLS) nelle comunicazioni tra client e server (mittente e destinatario). Seguendo il protocollo SMTP, il server dichiara il supporto del comando StartTLS in risposta al comando EHLO.
Il client invia il comando StartTLS per indicare che intende iniziare la negoziazione. Nel corso della negoziazione due azioni avranno luogo:

1. Il server si autentica usando un certificato X.509. In alternativa, il client deve richiedere di essere autenticato.
2. Il client e il server negoziano una chiave segreta K, che sarà usata per criptare le comunicazioni tra i due.

Esempio di dialogo SMTP estratto da RFC3207:

S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.imc.org SMTP service ready
C: EHLO mail.example.com
S: 250-mail.imc.org offers a warm hug of welcome
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 DSN
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
C: EHLO mail.example.com
S: 250-mail.imc.org touches your hand gently for a moment
S: 250-8BITMIME
S: 250 DSN

2. x509 Certificates

I certificati X.509 sono usati per validare l’identità e/o la chiave pubblica di server (es. durante la negoziazione TLS). I certificati X.509 (a volte chiamati anche certificati Secure Socket Layer (SSL)) prendono il proprio nome dal formato di certificato adottato da Netscape al momento della realizzazione della prima versione del protocollo SSL. Un certificato X.509 agisce come contenitore per informazioni specifiche riguardanti l’identità a cui è stato rilasciato e l’identità che lo ha emesso.
Tra i campi più importanti salvati in un certificato X.509 troviamo:

Versione versione del formato X.509 utilizzato nel certificato.
Numero di serie: numero unico assegnato da chi lo ha rilasciato.
Informazioni sull’algoritmo: descrizione dell’algoritmo usato per la firma digitale del certificato.
Nome distintivo di chi lo ha rilasciato: nome di chi ha rilasciato (generalmente un’autorità di certificazione) il certificato.
Periodo di validità del certificato: inizio e fine della validità del certificato.
Nome distintivo del soggetto: il nome del soggetto a cui è stato rilasciato il certificato.
Informazioni sulla chiave pubblica del soggetto: chiave pubblica del proprietario del certificato.

Il formato del certificato è definito in RFC5280. Le modalità di accesso e di gestione sono descritti in RFC4210. RFC3739 definisce ciò che viene chiamato Certificato Qualificato, che è relativo alla Direttiva Europea sulla Firma Elettronica (Direttiva 1999/93/EC).

3. SPF

Sender Policy Framework [RFC7208, RFC7372] (SPF) è un protocollo che permette ai provider email di dichiarare la lista di host (indirizzi IP) autorizzati a consegnare email da parte sua. Seguendo il protocollo SMTP, quando un client si identifica (comandi HELO o EHLO), dovrà indicare il nome host o l’indirizzo IP e quando inizia la trasmissione di un messaggio email, dovrà inviare il comando MAIL-FROM, indicando l’indirizzo email del mittente.

Questi due campi, il nome di host (o indirizzo IP) dal comando HELO (or EHLO) e l’email dal comando MAIL-FROM devono essere confrontati con il record SPF pubblicato dal provider email per verificare se il client ha il permesso di inviare email per conto del provider. I record SPF sono pubblicati sotto forma di record TXT nel dominio DNS del provider email. Esempio: record SPF del dominio et.dcslab.eu:

v=spf1 a mx ip4:139.191.36.5 -all

v=spf1 versione
a accettare l’IP se contenuto in un record A di et.dcslab.eu
mx accettare l’IP se contenuto in un record MX et.dcslab.eu
ip4:139.191.36.5 accettare l’IP se è presente nell'intervallo dato
-all fallimento di default

4. DKIM

DomainKeys Identified Mail [RFC6376] (DKIM) è un meccanismo di autenticazione usato per verificare l’origine legittima dei messaggi email.

DKIM fa uso di firme digitali per verificare l’identità dell'host mittente. Un provider email genera un paio di chiavi pubbliche/private per un dominio e presenta la chiave pubblica come registrazione DNS.
Per ogni invio di email, viene usata la chiave privata per la firma. Una volta che il server destinatario riceve il messaggio, lo potrà validare grazie al record pubblicato. In questo modo, il destinatario può verificare due elementi:

• Il mittente ha l’autorizzazione del controllo di dominio, ovvero la persona che gestisce il dominio DNS.
• Il messaggio non è stato modificato durante il trasferimento dal mittente al destinatario.

Esempio di intestazione DKIM per una email ricevuta:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=et.dcslab.eu; s=102016; t=1476792726; bh=HS0o/CkH/ZCpSrfolDyH8IR5hX6n8GxWLzY59OuvtWo=; h=Date:From:From:Subject; b=OOlOO/jae1cPF2pllIF2QiENPJdUvGL70FdPMkKa89qkhXdvr D89eZwK6OZzEdLYncAbYCrEVi58jFqFAjKBcASrRpjSQXTJX6hM cRNZ295/1xp8vR/J9CQl9baqGxhYWID8Z0OrN/tbwXNN2UiNTmk MIm90UDJHdQnw/rd9rX4=

Nell’esempio precedente, per recuperare la chiave che permette di verificare la firma DKIM, è necessario richiedere il record DNS di tipo TXT per il dominio 102016._domainkey.et.dcslab.eu.

5. DMARC

Domain-based Message Authentication, Reporting and Conformance [RFC7489] (DMARC) è un meccanismo che consente ai provider email di pubblicare le politiche relative ad SPF e DKIM.

In particolare, permette ai provider email di indicare cosa fare quando un messaggio non è conforme con SPF o DKIM (rifiutato, in quarantena, niente) e di indicare un indirizzo email per ricevere rapporti.

Può anche essere usato per definire una politica di accettazione/rifiuto di una certa percentuale di messaggi falliti per permettere lo sviluppo graduale di queste tecnologie. Esempio, registrazione DMARC del dominio et.dcslab.eu:

v=DMARC1; p=reject; rua=mailto:dmarc_reports@et.dcslab.eu

v=DMARC1 versione lingua DMARC
p=reject politica da applicare per il destinatario: nessuno/quarantena/rifiutato
rua=mailto.. indirizzo per l’invio dei rapporti

6. DANE

DNS-based Authentication of Named Entities [RFC6698, RFC7218, RFC7671, RFC7672] (DANE) è un meccanismo che lega i certificati X.509 (o chiavi pubbliche) ai servizi, specificando la porta, protocollo e dominio dove il servizio è in funzione. Il collegamento del certificato e del servizio è pubblicato con un record DNS di tipo TLSA. DANE può essere applicato a qualsiasi servizio, ma nel caso specifico delle comunicazioni email, abbiamo l'RFC7672 che descrive l’applicazione di DANE e DNSSEC alle comunicazioni (SMTP) tra MTAs. In particolare, l'RFC7672 raccomanda l’uso di DANE-TA o di DANE-EE con DNSSEC.

Una registrazione TLSA contiene 4 valori: il Campo d’Uso, il Campo Selettore, il Campo di Tipo di Corrispondenza e i Dati Associati. I diversi campi di un record TLSA sono descritti qui di seguito.

Per esempio, il record TLSA per un server SMTP attivo con porta di default (25), su host mx.example.com, con DANE-EE e che pubblica l’hash SHA2-256 della chiave pubblica (SPKI) del certificato del punto finale, sarebbe:

_25._tcp.mx.example.com TLSA 3 1 1 1cf...6ab

7. DNSSEC

Domain Name System Security Extensions [RFC4033, RFC6014, RFC6840] (DNSSEC) è un protocollo usato per autenticare le risposte dei server DNS. Questo meccanismo è utile alle applicazioni per evitare l’uso di record DNS alterati o falsificati. Il protocollo è in grado di autenticare un set di record DNS grazie alla verifica di una firma crittografica associata. Per ottenere ciò, DNSSEC introduce alcuni tipi di record aggiuntivi:

• Resource Record SIGnature (RRSIG): contiene una firma criptata di un Resource Record SET (RRSET).
• DNS KEY record (DNSKEY): contiene una chiave pubblica di firma.
• Delegation Signer (DS): contiene l’hash di un record DNSKEY.
• Next SECure record (NSEC) and NSEC3: per il rifiuto esplicito dell’esistenza di un record DNS.
• Child copy of DNSKEY record (CDNSKEY) and Child copy of DS record (CDS): per una zona figlio che richiede aggiornamenti ai record DS nella zona padre.

Per attivare DNSSEC, il server deve avere due coppie di chiavi (pubbliche e private). La prima coppia contiene le chiavi di firma private e pubbliche della zona (ZSKs) e la seconda coppia contiene le chiavi per la firma della chiave (KSKs). Con le chiavi private ZSK, il server firma in modalità digitale tutti gli RRSET sul DNS (gruppo di record DNS dello stesso tipo. Es. MX, TXT, ecc.) e salva le firme corrispondenti in un record RRSIG. La chiave pubblica ZSK è necessaria per verificare le firme ed è pubblicata come record DNSKEY. La registrazione DNSKEY della ZSK pubblica è firmata con la KSK privata. La KSK pubblica è anche pubblicata come record DNSKEY e può essere auto-firmata, cioè firmata con la KSK privata. Questa sequenza stabilisce l’affidabilità all'interno della zona.

Tenuto conto che il DNS è un sistema gerarchico, l’affidabilità all’interno di una zona deve essere collegata alla zona padre (parent). A tale scopo, il server codifica la chiave pubblica KSK e pubblica questo hash come un record DS nella sua zona padre.