TLS Cipher Suites per MTA

Anche con i cifrari che usano 3DES o RC4 un attaccante non è in grado di decifrare il codice con costi moderati. E anche i servizi segreti probabilmente farebbero lo spoofing del DNS MX o semplicemente toglieranno STARTTLS dalle funzionalità del MTA ricevente perché questo è molto più economico rispetto al tentativo di decifrare tali cifrari.

Pertanto raccomando di accettare le cifrate con RC4 e 3DES nel caso in cui il MTA peer non possa avere cifrari migliori, perché la crittografia errata è decisamente migliore del semplice testo e in molti casi è anche meglio che non consegnare affatto la posta. Ovviamente dovresti mettere questi codici deboli solo alla fine della tua lista e preferisci quelli forti. E non dovresti usare codici cifrati come i cifrari EXPORT.

Tuttavia, se in un ambiente con requisiti di sicurezza più elevati dovresti configurare il tuo MTA per utilizzare solo cifrari forti e rendere TLS obbligatorio, ovvero senza fallback, anche se il peer non sembra supportare TLS. Inoltre, dovresti proteggerti dallo spoofing MX, ad esempio rinforzando DNSSec. A parte questo, è meglio utilizzare la crittografia end-to-end (PGP, S / MIME) in tale ambiente comunque.

Questa è una buona domanda e non sono sicuro che ci sia una buona risposta.

Quindi ci sono due tipi di attacchi: attivi e passivi. Per un attaccante passivo, i protocolli rotti potrebbero andare bene fino a quando l'attacco richiede qualche tipo di modifica / iniezione del traffico. Non possono fare cose come generare certificati falsi e firmarli con una firma md5 in conflitto perché, come un attaccante passivo, non possono iniettarli nello stream.

Gli attaccanti attivi possono fare cose con la connessione, come apparire come se il server di posta all'altra estremità non supporta affatto TLS.

Quindi, in generale, a meno che tu non voglia forzare TLS e disabilitare completamente le normali connessioni, penso che dovresti capire quali protocolli sono sicuri contro gli attaccanti passivi. O almeno gli attacchi che sono al di sotto del livello di rischio: ad es. se costasse $ 2 milioni per crackare un cifrario (ad esempio, RSA con chiavi a 1024 bit) e gli stati nazione non sono un avversario di cui sei preoccupato, potrebbe essere accettabile.

Scusa se non ho il tempo di capire quali versioni e cifrari TLS sono utilizzabili contro attaccanti passivi, ma spero che ciò sia stato di aiuto.

Personalmente avrei abilitato cifrature forti (ad esempio, utilizzando i suggerimenti del link ).

RC4 è effettivamente rotto ( link ), quindi abilitandolo è al massimo di valore dubbio (può proteggere contro un osservatore casuale).

Detto questo: quanto dell'email che ricevi sarà influenzata? Dalla mia esperienza personale, l'argomento è simile a quello fatto per quanto riguarda i browser web; di tanto in tanto alcuni motivi convincenti si discostano dall'approccio crittografico di alta qualità, ma l'approccio predefinito è di non farlo. Nel mio caso, si scopre che una piccola parte della posta che mi interessa potrebbe essere compromessa.

So che gli MTA non sono browser e l'immagine non è così rosea, ma sospetto anche che l'immagine non sia così male come molti potrebbero pensare (i provider di posta gestiti aiutano).

Quindi, a conti fatti, mi atterrerei sull'approccio HTTPS, piuttosto che sul lato di supportare la crittografia di bassa qualità (che in alcuni casi non è in grado di proteggere i dati in primo luogo).