L'applicazione della crittografia per SMTP è una buona idea (ancora)?

Sto eseguendo un server di posta elettronica che è attualmente impostato per utilizzare TLS, se possibile, durante l'invio e la ricezione di e-mail.

Quando leggi nella documentazione a riguardo, c'è anche la possibilità di applicare TLS e di non accettare la trasmissione di messaggi di posta elettronica in chiaro. Ti avverte inoltre che alcuni server di posta potrebbero non supportare ancora la crittografia e l'applicazione della crittografia potrebbe bloccare questi server.

Ma questo è ancora un problema a cui dovresti pensare o è sicuro dire che l'applicazione della crittografia non sarà più un problema?

C'è forse qualche grande fornitore che lo sta già facendo o cosa consideri la migliore pratica in questi giorni?

Il problema pratico è che non tutti i server conformi a SMTP (RFC sono piuttosto vecchi) possono parlare TLS al tuo server, quindi potresti non ricevere alcuni messaggi e-mail.

Il problema filosofico è che è impossibile dire come l'e-mail viene inoltrata dopo (o prima) che è arrivata sul tuo server.

Ciò significa che l'e-mail potrebbe essere già stata trasmessa in chiaro tramite un relay.

Chiunque sia seriamente interessato a proteggere il contenuto della propria e-mail dovrebbe effettivamente crittografare il corpo. Con la crittografia in rotta è sempre plausibile che sia già stato trasmesso in chiaro.

Quindi, rispondere alla tua domanda imporre la crittografia a livello di SMTP è probabilmente inutile, aumenta le possibilità di perdere la posta elettronica e non vi è alcun vantaggio garantito garantito.

Modifica: si riferisce all'applicazione SMTP a scopo di inoltro, non di invio di e-mail. Nelle comunicazioni via posta elettronica è necessario applicare la crittografia poiché la conversazione SMTP (non l'e-mail effettiva) probabilmente contiene credenziali di autenticazione.

No

RFC 821 ha 33 anni. Troverai e -mail inoltrate da programmi che non supportano STARTTLS. A volte saranno stub mittenti di e-mail (es. Script interni), a volte sistemi completi che sono vecchi, hanno TLS disabilitato / non compilato, sistemi senza abbastanza entropia ...

Ho assistito non molto tempo fa alle e-mail in uscita non riuscite perché l'estremità ricevente lo aveva configurato per consentire solo SMTP su TLS. Era un problema nel mittente (non avrebbe dovuto usare quella configurazione), ma mostra che succede.

Vorrei limitare i messaggi in arrivo solo dagli indirizzi IP configurati manualmente. Se il tuo elaboratore di carte di credito non riesce ad avviare STARTTLS, probabilmente preferisci interrompere la connessione (e sfogliare l'amministratore locale in modo che possa avvertirli!) Piuttosto che ricevere quei dati (potenzialmente sensibili) non crittografati. Per i messaggi in uscita, se ti sei connesso a quell'host utilizzando STARTTLS in precedenza, potresti voler non farlo di nuovo in modo insicuro, trattandolo invece come un potenziale compromesso. Potresti anche avere un elenco di host STARTTLS noti da usare sempre, come gmail o yahoo.

Esiste il progetto https://www.eff.org/starttls-everywhere che fornisce un elenco di server smtp per i quali è possibile (si dovrebbe?) Imporre con sicurezza l'utilizzo di starttls.

È completamente inutile, e probabilmente attivamente dannoso, rifiutare la posta elettronica da colleghi incapaci di crittografia.

Finché il tuo server è impostato per eseguire la crittografia opportunistica con qualsiasi altro peer che lo offre, ottieni il meglio da entrambi i mondi: crittografia quando è disponibile e posta elettronica su testo normale quando non lo è.

Finché ci sono server che non supportano la crittografia, il loro mandato significa semplicemente che non possono parlare con te; questo è male. Una volta che tutti lo supportano, non c'è differenza tra crittografia opportunistica e obbligatoria.

E come altri hanno sottolineato, la crittografia on-the-wire e la crittografia end-to-end sono due cose completamente diverse, che affrontano diversi modelli di minaccia. Non confondere i due.

Questa è una questione politica.

In genere, quando TLS viene applicato per inbound e outbound, viene eseguito per un numero limitato di domini concordati dalle parti per soddisfare un'esigenza (ad esempio, i partner commerciali potrebbero avere un accordo per crittografare tutta la posta tra le loro società).

A meno che non sia stato stipulato un accordo del genere, non attivare la modalità di applicazione.

No, è una pessima idea.

In effetti, a quanto pare, la maggior parte dei server / client STARTTLS non implementano alcun tipo di algoritmo di tentativo senza StartTLS nel caso in cui una connessione TLS non riesca a negoziare.

Pertanto, anche pubblicizzare STARTTLS come opzione riduce già le possibilità di ricevere (e inviare) e-mail!

Basta cercare e scoprirai che molte persone non sono in grado di inviare QUALSIASI email ai domini di Microsoft Outlook gestiti dal cluster * .protection.outlook.com:

Messaggi Sendmail rifiutati da Microsoft quando si utilizza TLS

motivo: 403 4.7.0 Handshake TLS non riuscita

Riassumendo i problemi presentati nei due post precedenti:

• può inviare posta a qualsiasi host diverso da quelli gestiti da Outlook, con o senza STARTTLS,
• può inviare posta senza un certificato client e senza STARTTLS a Outlook,
• o con un certificato client di lunghezza zero,
• ma non con un certificato che non piace a Microsoft e, in caso di errore, i client (beh, i server che agiscono in modalità client) non tentano di inviare nuovamente il messaggio senza STARTTLS se il server del destinatario pubblicizza STARTTLS!

Allo stesso modo, quando il tuo host funge da server, una situazione simile può verificarsi al di fuori del tuo controllo se decidi di abilitare STARTTLS - quando un server client vede che il tuo server in modalità server offre STARTTLS, prova a negoziare TLS, ma se la negoziazione fallisce , semplicemente aspettano e riprovano a ripetere gli stessi passaggi, continuano a non riuscire fino a quando il messaggio non deve essere rispedito al mittente!

E questo succede abbastanza frequentemente con vari domini nella terra di STARTTLS!

Purtroppo, per quanto fossi un sostenitore di STARTTLS in passato, ora sono molto privato del diritto di essere stato ingannato dalla pubblicità priva di rischi di ciò che pensavo dovesse essere una crittografia opportunistica.

Non solo non dovresti richiedere STARTTLS, ma potrebbe anche essere prudente disabilitarlo completamente, se vuoi garantire l'interoperabilità.

Devo concordare sull'idea di utilizzare un TLS opportunistico. Anche se ne ho anche alcuni da aggiungere all'idea. Alcuni saranno probabilmente disturbati dai suggerimenti, tuttavia, poiché i miei suggerimenti qui non sono formulati alla leggera e senza la dovuta considerazione, prima di esprimere un giudizio, ti chiedo di leggere la discussione completa dal link allegato.

L'uso del TLS opportunistico è di gran lunga la soluzione migliore. L'angolo MITM come argomento contro di esso è un'aringa rossa. Dopotutto, come menzionato MH in un commento, anche un SMTP "legittimo" con connessione TLS può essere MITM e l'utente finale non è il più saggio a causa della stragrande maggioranza dei client di posta che non si preoccupa di convalidare i certificati accoppiati con la stragrande maggioranza degli MTA là fuori che fanno TLS usano certificati autofirmati (almeno se non si usano DNSSEC e TLSA / DANE). Come risultato di questo e forse di altri fattori, è persino discutibile che fino a quando tu e il resto del mondo ha implementato DANE / TLSA e DNSSEC, che durante l'esecuzione di TLS opportunistico è meglio che non avere anche diffie-hellman anonimo (pur usando anche PFS). Dovuto almeno in parte, se non principalmente, al fatto che crittografa comunque il traffico proteggendolo dall'osservatore occasionale. A ulteriore supporto di questa configurazione (con una spiegazione molto più elaborata della mia), vedere i commenti di Viktor Dukhovni in questo post in un forum postfix:http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html

Per quanto riguarda il motivo per cui uno potrebbe prendere i suggerimenti di Viktor su quelli degli altri, beh, ha scritto il codice TLS e il codice DNSSEC, TLSA / DANE per l'MTA Postfix oltre ad essere stato quello che ha scritto le bozze IETF su entrambi i DNSSEC e TLSA / DANE. In quanto tale, direi che le sue parole sull'argomento hanno molto peso, probabilmente più di quelle della maggior parte.

Spero che sia di aiuto.

Dal punto di vista dell'email marketing, l'uso di TLS è una buona pratica e sicuro quando si sa che è implementato attraverso l'intera catena di consegna. Tuttavia, se la sicurezza è il tuo requisito principale, crittografare l'e-mail stessa prima di inviarla è l'opzione più sicura (ad esempio con PGP).