L'utilizzo di un certificato SSL autofirmato su un server di posta ostacola la comunicazione?

Stai bene con un certificato autofirmato.

Nella mia esperienza da diversi anni, non ho mai avuto problemi con un certificato autofirmato sul mio server di posta. Alla fine sono passato a uno firmato da StartSSL e non c'era alcuna differenza visibile nell'interoperabilità.

Vedi anche questo post su ServerFault .

La linea di fondo è che STARTTLS riguarda la crittografia, non l'autenticazione. Anche se può essere bloccato per eseguire l'autenticazione, il default di molti (se non tutti) server SMTP è crittografia opportunistica . L'SMTP è in testo semplice per impostazione predefinita e richiedeva la crittografia più del necessario per l'autenticazione, quindi l'enfasi.

È possibile bloccare le connessioni - ad esempio, ho visto un Ironport configurato per richiedere un certificato valido firmato da una CA nota a cui piaceva (in questo caso, è piaciuto Entrust ma non Comodo, quindi abbiamo finito per cambiare il cert perché era più facile del debug di Ironport di qualcun altro). Ma per bloccare determinati domini che vogliono garantire la crittografia associata, non ho mai visto qualcuno farlo con la crittografia opportunistica.

La crittografia con SSL comprende i seguenti passaggi:

1. Identifica il peer usando un certificato.
2. Crea e scambia le chiavi per la seguente comunicazione.
3. Scambia i dati, crittografati con le chiavi scambiate in precedenza.

Di solito utilizzi la crittografia perché pensi che chiunque possa ascoltare la connessione. Un piccolo passo da questo ascolto passivo è la manipolazione attiva della connessione che anche l'SSL può rilevare. Ma per questo ha bisogno di identificare correttamente il tuo peer, altrimenti chiunque nel mezzo potrebbe pretendere di essere il server giusto.

Con un certificato autofirmato, l'identificazione corretta non è possibile, perché chiunque può creare un tale certificato con le stesse credenziali di te. Ciò significa che nessuno dovrebbe fidarsi di un certificato autofirmato da solo. Deve solo fidarsi di un certificato autofirmato se può verificarlo utilizzando un altro modo. Questo altro modo potrebbe essere una configurazione manuale sul lato server (di solito non è il caso a meno che il mittente conosca direttamente il destinatario) o la verifica del certificato attraverso DANE , dove il proprietario del dominio fornisce il proprio certificato o impronta digitale all'interno di un record DNS attendibile (richiede DNSSec ).

Ciò che i server effettivamente fanno quando rilevano un certificato non attendibile è diverso: alcuni accetteranno il certificato e scriveranno verify=NO nell'intestazione Received della posta, mentre altri potrebbero rifiutarsi di connettersi con SSL perché considerano la connessione non sicura e il downgrade in chiaro testo o non connettere affatto. Dipende dalle impostazioni del server mittente.

Attualmente probabilmente la maggior parte dei server di posta si connetterà correttamente ad altri server, anche se non possono verificare il loro certificato. Ma sempre più utilizzano certificati "veri" (verificabili). Se confronti i rapporti di Facebook da maggio 2014 a Agosto 2014 puoi vedere l'uso di certificati verificabili passare dal 30% al 95% in soli 4 mese. Ciò significa che l'uso di certificati reali sarà probabilmente richiesto da più server nel prossimo futuro.

Ciò significa che l'utilizzo di un certificato firmato da una CA ben nota è decisamente migliore rispetto all'utilizzo di un certificato autofirmato. Ma anche quello potrebbe non fornire la sicurezza che stai cercando di raggiungere. Uno qualsiasi dei 100 di CA attendibili dal sistema operativo può emettere un certificato di questo tipo, quindi un utente malintenzionato potrebbe tentare di ottenere anche un certificato per il proprio dominio. Ma questo è almeno molto più difficile che creare un altro certificato autofirmato, perché l'hacker deve hackerare la CA o controllare il dominio di posta in qualche modo per catturare i messaggi che la CA utilizza all'interno del processo di identificazione.

Un altro attacco di un uomo man-in-the-middle è di reinstradare la posta attaccando il DNS: per instradare una posta dal server di posta mittente al server responsabile del tuo dominio, il server mittente deve una ricerca DNS per il record MX del tuo dominio, che contiene i nomi dei tuoi server di posta. Un attaccante attivo vicino al server mittente potrebbe attaccare questa ricerca DNS e fornire un record MX falso che punta ai propri server. TLS non aiuterà più qui. Invece devi usare DNSSec per proteggere i tuoi record DNS e il mittente deve verificare questo record.

Oltre a ciò TLS non fornisce sicurezza end-to-end per la posta, solo hop-by-hop. Qualsiasi server di posta in mezzo ha accesso alla posta semplice e quindi deve essere completamente affidabile. Per ottenere la crittografia end-to-end è necessario utilizzare S / MIME o PGP. E a causa di ciò alcuni amministratori di server non si preoccupano affatto del TLS corretto, perché TLS non offrirà sicurezza reale (end-to-end) per i messaggi, anche se implementati correttamente.

L'autenticità di un certificato è verificata utilizzando la chiave pubblica della persona fidata. Uno spoofer di certificati può inserire tutti i dati desiderati in qualsiasi certificato che fanno ma non può firmare il certificato con la chiave privata (firma) della parte fidata poiché non ce l'ha. Quando il pub della parte fidata o se ti piace la chiave di verifica viene utilizzata sulla chiave privata (firma) sbagliata, la firma verrà considerata falsa.

Questo non è diverso per un certificato firmato o autofirmato dalla CA.

I problemi sorgono tuttavia nella distribuzione della chiave pubblica. È qui che le "autorità" dei certificati eccellono come possono, apparentemente, distribuire in modo più sicuro le loro chiavi pubbliche a un numero maggiore di persone semplicemente inviandole in modo sicuro a un numero relativamente ristretto di fornitori di applicazioni chiave disposti ad installarlo nella loro app, ad esempio: "fornitori di browser", provider di server di posta elettronica ecc. che sanno per certo che sono loro a inviarlo. Pertanto, le loro chiavi pubbliche, utilizzate per verificare le proprie firme, sono "di sicuro" le loro e possono essere utilizzate in modo sicuro per verificare se abbiano effettivamente firmato qualcosa. Vale a dire un certificato.

Se un autore autonomo può distribuire in modo sicuro la propria chiave pubblica, ovvero distribuirla in modo che siano utenti sappiamo per certo che è loro quindi la loro firma, e quindi il loro certificato autofirmato, è altrettanto buono se non migliore, considerando che la loro identità è assicurata dalla distribuzione delle chiavi rispetto alla verifica dell'idore del certificato CA, come quella di qualsiasi CA.

In questa luce la domanda diventa quanto in modo sicuro e costo (o tempo) efficace può essere distribuita la tua chiave di pub e installato negli altri server di posta e se qualunque cosa ti sta spingendo a farlo, sia meglio la sicurezza, CA $ upport avversione o qualche altro ne vale la pena.

Questo non è più vero. Alcuni server di posta elettronica hanno iniziato a verificare la catena di affidabilità del certificato offerto e rifiutare la connessione se non lo supera. Questo può impedire l'invio e la ricezione di email.

Nel nostro caso, stiamo usando il mailgun e c'è un piccolo interruttore nella loro interfaccia di configurazione che per impostazione predefinita richiede che il server ricevente abbia un certificato appropriato.