Quale nome host deve contenere il certificato SSL per un server SMTP?

Ho un server foo.example.com in 192.0.2.1

Funziona exim per ricevere e-mail per molti dei miei domini.

Ciascuno dei miei domini ha un record MX che punta a mx.example.com, che si risolve in 192.0.2.1

Se voglio fare in modo che exim offra la crittografia TLS per le connessioni e-mail in arrivo, quale nome host devo inserire nel certificato SSL?

• foo.example.com perché è quello che il server dirà in HELO?
• mx.example.com perché è il nome host a cui i client si saranno connessi?

http://www.checktls.com suggerisce che quest'ultimo è corretto, ma non riesco a trovare una risposta definitiva.

Questo in realtà non è definito esplicitamente da nessuna parte, e se il server debba essere "fidato" dipende dal client (che potrebbe ovviamente essere un altro server di posta) che si collega ad esso; citando dalla RFC pertinente ( RFC 2487 ):

Se il client SMTP decide che il livello di autenticazione o di
privacy non è sufficientemente elevato da consentire il proseguimento, DOVREBBE emettere un
comando QUIT SMTP immediatamente dopo il completamento della negoziazione TLS.
Se il server SMTP decide che il livello di autenticazione o di
privacy non è abbastanza alto da poter continuare, DOVREBBE rispondere a
ogni comando SMTP dal client (diverso da un comando QUIT) con
il codice di risposta 554 (con una possibile stringa di testo come come "Comando
rifiutato per mancanza di sicurezza").

La decisione di credere o meno all'autenticità
dell'altra parte in una negoziazione TLS è una questione locale. Tuttavia, alcune
regole generali per le decisioni sono:

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

Ciò significa sostanzialmente che, quando il server offre la crittografia TLS utilizzando un determinato certificato, la decisione di accettarla o rifiutarla dipende interamente dall'altra parte, che probabilmente vorrà che il nome sul certificato sia lo stesso a cui è collegato, ma potrebbe accettalo molto bene anche se non corrisponde.

Ma aspetta, c'è di più. Citando di nuovo dallo stesso RFC:

Al completamento dell'handshake TLS, il protocollo SMTP viene ripristinato allo
stato iniziale (lo stato in SMTP dopo che un server emette un
annuncio pronto per il servizio 220 ). Il server DEVE scartare qualsiasi conoscenza
ottenuta dal client, come l'argomento al comando EHLO,
che non è stato ottenuto dalla negoziazione TLS stessa. Il client
DEVE eliminare qualsiasi conoscenza ottenuta dal server, ad esempio l'elenco
delle estensioni del servizio SMTP, che non è stato ottenuto dalla
negoziazione TLS stessa. Il client DOVREBBE inviare un comando EHLO come
primo comando dopo una negoziazione TLS riuscita.

Quindi, ciò che il server sta dicendo in risposta a HELO / EHLO prima dell'handshake TLS non sembra affatto importare.

Nella mia esperienza, i certificati autofirmati funzionano abbastanza bene sui server di posta con connessione a Internet, il che significa che gli altri server di posta non si preoccupano nemmeno di convalidarli, accetteranno felicemente tutto ciò che può fornire la crittografia TLS, indipendentemente dall'emissione nome dell'autorità o soggetto.

Un MTA che consegna posta al tuo dominio cercherà il record MX (che produrrà un nome host), quindi cercherà un record A per quel nome host. Il nome host a cui si connette è quindi il nome host MX, quindi è ciò che verrà verificato rispetto al nome comune del certificato SSL. La verifica del nome host HELO non ha senso perché il server può fornire qualsiasi nome host HELO desiderato, ma non fornisce ulteriore sicurezza.

Detto questo, la verifica rigorosa dei certificati SSL al momento della consegna della posta non è particolarmente utile al momento, dal momento che gli MTA ricorrono (quasi sempre) al recapito non SSL, poiché al momento funziona così SMTP. La configurazione ragionevole è quindi utilizzare SSL se il server MX lo offre, indipendentemente dal fatto che il certificato SSL verifichi o meno (poiché la crittografia senza autenticazione è migliore di nessuna crittografia e nessuna autenticazione). Pertanto, è possibile utilizzare anche un certificato autofirmato per questo scopo.

Il compito di verificare il certificato del server e che corrisponda al nome host del server è puramente il ruolo del client, per qualsiasi protocollo che utilizza SSL / TLS.

Pertanto, il nome host nel certificato deve corrispondere al nome a cui il client sta tentando di accedere.

Quando la connessione SSL / TLS viene avviata in anticipo (SMTPS), il server non ha modo di vedere cosa dice il messaggio HELO prima di stabilire la connessione, quindi deve usare quello con cui ha effettuato la richiesta.

Quando si utilizza SSL / TLS in seguito STARTTLS, il client intende ancora parlare con il server con cui è stato configurato, quindi è ancora ciò che dovrebbe verificare. In caso contrario ciò renderebbe possibili gli attacchi MITM:

• C-> S: Ciao, sono Alice, voglio parlare con Bob.
• S-> C: Ciao, sono Chuck, ecco la mia richiesta per Chuck.
• C-> S: Oh sì, il tuo certificato è effettivamente valido per Chuck. Procediamo
• ... C'è un difetto lì ovviamente, dal momento che Alice voleva una comunicazione sicura con Bob.

In entrambi i casi, è l'indirizzo MX che dovrebbe essere usato.

Le regole di corrispondenza del nome host sono state recentemente raccolte attraverso i protocolli in RFC 6125 , ma pochi client lo implementano completamente (è più una RFC delle migliori pratiche che una modifica completa, ed è ancora piuttosto recente).

Nella sua appendice , riassume ciò che esisteva prima di SMTP (tratto da RFC 3207 e RFC 4954 ). In particolare " Il client NON DEVE utilizzare alcuna forma del nome host del server derivato da una fonte remota non sicura (ad es. Ricerca DNS non sicura). " (Che si applica ovviamente al banner del server). Oltre a questo, le regole legacy SMTP erano un po 'più rilassato di HTTPS per quanto riguarda i nomi soggetto alternativi ( dovrebbe invece che deve essere utilizzato).

Il modo moderno è sicuramente quello di inserire il nome host in una voce DNS Nome alternativo soggetto. Si sconsiglia anche l'utilizzo di caratteri jolly .

Penso che il migliore sarebbe copiare ciò che viene fatto in pratica. Ho controllato un indirizzo e-mail di yahoo.com usando http://checktls.com Spero che, su yahoo, abbiano usato un dominio diverso per il loro nome host e per il loro dominio mx. Quindi, il loro nome host è yahoo.com e il loro dominio mx termina con yahoodns.net

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others

Risultato dei checktls: il certificato SSL CN = MX domain (* .yahoodns.net)

Ho fatto lo stesso con Cisco e ho avuto lo stesso risultato.

Nella crittografia SSL / TLS il client controlla sempre la corrispondenza tra il nome host "reale" / "dichiarato" sulla macchina remota e le informazioni contenute nel certificato.

Quindi, probabilmente dovresti impostare foo.example.com o generare un certificato jolly ;-)