SMTP e SSL / TLS

L'SSL opportunistico scoraggerà gli attaccanti passivi che si limitano a spiare la linea. Alza anche leggermente la barra per gli attaccanti attivi: per poter alterare i dati trasmessi (ad esempio per iniettare un'e-mail falsificata nello stream), l'attaccante ora deve fare un MitM completo con certificato falso e decrittografare / ricodificare l'intera connessione.

Ma, davvero, questo è per le pubbliche relazioni. I grandi server di ritrasmissione della posta come Gmail usano SSL / TLS quando possono principalmente dimostrare di essere responsabili e hanno fatto uno sforzo verso "maggiore sicurezza". In definitiva, questa non è una mossa sbagliata: se la moda prende piede e diventa tradizione, allora possiamo sperare che contemporaneamente SSL / TLS diventerà obbligatorio . Se i server SMTP decidono quindi di usarlo correttamente (cioè con un'adeguata convalida del certificato peer, completo di controlli di revoca), allora la sicurezza generale sarà aumentata.

SMTP è intrinsecamente un protocollo inoltrato, con qualsiasi relay non appartenente al dominio di origine o di destinazione che sia un man-in-the-middle. L'SMTP si avvicinerebbe alla riservatezza offerta da HTTPS se un server SMTP controllato dalla tua organizzazione dovesse cercare un server di posta dai record MX MX del dominio di destinazione e quindi trasmettere l'email solo via TLS a quel server.

Ovviamente, questo escluderebbe tutta la webmail - dove il client Javascript consegna la posta tramite HTTPS al server HTTPS del provider webmail, che poi la decrittografa e poi la memorizza / trasferisce in chiaro ai suoi server SMTP e quindi può o potrebbe non inviarlo su TLS al server SMTP del dominio di destinazione.