Che passi fai Gmail, Yahoo! Mail e Hotmail per impedire l'intercettazione di e-mail?

Una sessione SMTP tra due server di posta può essere crittografata, ma solo se entrambe le estremità la supportano e se entrambe le estremità scelgono di usarlo . Pertanto, se invii posta da Gmail a example.net, Google potrebbe crittografare solo se example.net fosse pronto e disponibile. Per questo motivo, non ti puoi fidare che l'email sia anche moderatamente sicura a livello di trasporto. (L'unico metodo end-to-end sicuro è quello di crittografare la tua e-mail usando S / MIME o PGP, ma anche le persone con cui stai scambiando email devono essere a bordo ... proprio come i server di posta).

Per quanto riguarda il fatto che i tre grandi stiano utilizzando STARTTLS opportunistici, non ho visto alcuna prova di ciò, ma passo meno tempo a leggere i registri del mio server di posta di quanto mi ero abituato. E se lo sono, sono ancora solo la metà di ogni connessione SMTP che fanno e non possono garantire l'uso della crittografia.

Aggiornamento:

Ho appena provato gli host MX testati per gmail.com, yahoo.com e hotmail.com. Solo Gmail pubblicizza STARTTLS, vale a dire, solo Gmail sarebbe disposto a crittografare la sessione SMTP se l'altra parte lo desiderava.

Ho provato Gmail in uscita inviando posta a un server che possiedo e guardando il cavo; Google si avvantaggia effettivamente di STARTTLS se viene offerto e crittografa la transazione SMTP quando un utente gmail invia la posta. Puntelli su Google.

Quindi per quanto riguarda l'invio della crittografia e-mail: Google 1, Yahoo 0, Microsoft 0.

Come per i commenti sottostanti, se vuoi testarli da soli, è molto semplice:

1. Determina gli host MX (Mail eXchangers) per il dominio
2. Telnet alla porta 25 su uno di essi
3. Digita "ehlo yourhostname.domain.com"
4. Se non vedi "250-STARTTLS" come una delle risposte, non supportano la crittografia opportunistica.

In questo modo:

$ host -t mx yahoo.com
yahoo.com mail is handled by 1 mta5.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta7.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta6.am0.yahoodns.net.
$ telnet mta5.am0.yahoodns.net 25
Trying 66.196.118.35...
Connected to mta5.am0.yahoodns.net.
Escape character is '^]'.
220 mta1315.mail.bf1.yahoo.com ESMTP YSmtpProxy service ready
ehlo myhost.linode.com
250-mta1315.mail.bf1.yahoo.com
250-8BITMIME
250-SIZE 41943040
250 PIPELINING
quit
221 mta1315.mail.bf1.yahoo.com
Connection closed by foreign host.
$

Come nota a margine, Yahoo chiuderà la connessione se non lo fai subito. Ho dovuto tagliare & incollare il mio ehlo perché digitarlo è durato troppo a lungo.

ULTERIORI AGGIORNAMENTI:

A partire da gennaio 2014, Yahoo ora sta crittografando - ho appena testato (come sopra) e verificato. Tuttavia, entrambi Il registro e Computerworld sta segnalando che le intracanze della configurazione SSL (come Perfect Forward Secrecy) lasciano molto a desiderare come implementato da Yahoo.

AGGIORNAMENTO MORER ANCHE:

Google ora include i dati di crittografia SMTP nella sezione Posta sicura per i rapporti sulla trasparenza . Stanno condividendo i loro dati su chi altro è disposto a crittografare, e puoi guardare i numeri migliori e interrogare i singoli domini.

Addendum:

@SlashNetwork sottolinea che è possibile configurare un server di posta per richiedere che TLS sia negoziato prima di scambiare la posta. Questo è vero, ma per citare la documentazione di Postfix :

You can ENFORCE the use of TLS, so that the Postfix SMTP server announces STARTTLS and accepts no mail without TLS encryption, by setting "smtpd_tls_security_level = encrypt". According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced Postfix SMTP server. This option is off by default and should only seldom be used.

Ora, il mondo è pieno di implementazioni che violano le RFC, ma questo genere di cose - ad esempio, qualcosa che può interrompere la funzionalità richiesta di routine come accettare i rimbalzi e la posta per il postmaster - è probabilmente più probabile che abbia conseguenze negative. / p>

Una soluzione migliore che i gateway di posta spesso consentono è l'imposizione dei requisiti TLS su una base di criteri per dominio . Ad esempio, di solito è possibile dire "Richiedi TLS con un certificato valido firmato da Entrust quando si parla con example.com". Ciò viene solitamente implementato tra organizzazioni che fanno parte della stessa società madre ma che hanno un'infrastruttura diversa (think: acquisitions) o organizzazioni con una relazione commerciale (si pensi: ACME, Inc. e la loro società di call center di supporto esternalizzata). Questo ha il vantaggio di garantire che specifici sottoinsiemi di posta che ti interessano vengano crittografati, ma non rompere l'architettura (accetta da chiunque di default) dell'email SMTP.

Addendum ++

Google ha annunciato che gmail filtrerà le informazioni sulla sicurezza se il percorso di posta verso il lettore . Pertanto, questi passaggi di crittografia dietro le quinte verranno riportati un po 'di più all'utente.

(Probabilmente ancora non si preoccupa della provenienza del certificato, solo un indicatore della crittografia dei bit).

Ci sono tre punti nella catena che devi considerare: Trasporto tra server di posta (ad esempio tra Google e example.org), trasporto tra server di posta e client e server di posta stessi.

Il traffico tra i server di posta può essere o non essere crittografato; non dovresti fare affidamento su di esso, e AFAIK, non c'è modo di applicarlo dal client.

Il traffico tra client e server di posta può essere o non essere crittografato; se ti connetti tramite SSL (tramite un'interfaccia web o SMTP), la tua estremità della catena è sicura, ma non puoi dire nulla sul destinatario. Al contrario, se si è il destinatario, è possibile recuperare la posta in modo sicuro, ma se il mittente (o chiunque nel CC / BCC) non fa lo stesso, allora c'è una falla.

E infine, ci sono i server di posta stessi. Se qualcuno vi ha hackerato, o se si occupa di social engineering, e il server di posta memorizza il contenuto in modo non criptato, allora ancora una volta sei sfortunato.

TL; DR: A meno che non si controlli l'intera catena (sia i client che tutti i server di posta coinvolti), che non è praticamente mai il caso, l'unico modo per inviare e-mail con sicurezza affidabile è crittografare e decrittografare localmente, usando qualcosa come PGP.

Qui ci sono due domande diverse:

1. Il sistema di posta elettronica consente l'invio di e-mail su un canale crittografato e l'invio di e-mail lungo un canale crittografato quando il server di posta del destinatario lo supporta.
2. Il sistema di posta elettronica crittografa il contenuto di una casella di posta quando lo visualizza al proprietario.

gownfawr address (1) well.

Gmail cripta per impostazione predefinita per (2), quindi quando vedendo la tua posta, per impostazione predefinita viene effettuata tramite HTTPS, quindi un ficcanaso non sarà in grado di osservare gmail che invia la posta al tuo browser. Credo che gli altri non abbiano ancora seguito la suite. (Divulgazione completa, lavoro per Google).

Gmail is set to use the 'Always use https' setting by default, ...

"Rendi più sicura la tua posta elettronica" contiene istruzioni per evitare letture di testo in chiaro di una casella di posta per un numero di grandi dimensioni fornitori di webmail, ma non posso garantire che sia aggiornato.

Puoi testare da solo utilizzando i siti web menzionati nella test di configurazione STARTTLS di Server SMTP . Assicurati di testare sia la ricezione che l'invio.