What steps do Gmail, Yahoo! Mail, and Hotmail take to prevent eavesdropping on email?
An SMTP session between two mail servers may be encrypted, but only if both ends support it and if both ends choose to use it. So if you're sending mail from Gmail to example.net, then Google could only encrypt if example.net was ready and willing. For this reason, you cannot trust email to be even moderately secure at the transport layer. (The only safe end-to-end method is to encrypt your email using S/MIME or PGP, but the people you're exchanging email with need to be on board too... just like the mail servers).
As to whether the big three are performing opportunistic STARTTLS, I haven't seen any evidence of it, but I spend less time reading my mail server logs than I used to. And if they are, they're still only half of every SMTP connection they make, and cannot guarantee the use of encryption.
Update:
I just banner tested MX hosts for gmail.com, yahoo.com, and hotmail.com. Only gmail advertises STARTTLS, which is to say, only gmail would be willing to encrypt the SMTP session if the other party wanted to.
I tested gmail outbound by sending mail to a server I own and watching the wire; Google does indeed take advantage of STARTTLS if it is offered and encrypts the SMTP transaction when a gmail user is sending mail. Props to Google.
So as far as "sending" email encryption goes: Google 1, Yahoo 0, Microsoft 0.
As per the comments below, if you want to test these yourself, it's very simple:
- Determine the MX hosts (Mail eXchangers) for the domain
- Telnet to port 25 on one of them
- Type in "ehlo yourhostname.domain.com"
- If you don't see "250-STARTTLS" as one of the responses, they don't support opportunistic encryption.
Like this:
$ 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.
$
As a side note, Yahoo will close the connection if you don't ehlo right away. I had to cut & paste my ehlo because typing it in took too long.
MORE UPDATE:
As of January 2014, Yahoo is now encrypting - I just tested (as above) and verified. However, both The Register and Computerworld are reporting that the intracacies of SSL setup (such as Perfect Forward Secrecy) leave a lot to be desired as implemented by Yahoo.
EVEN MORER UPDATE:
Google is now including SMTP encryption data in their Transparency Report Safer Email section. They're sharing their data about who else is willing to encrypt, and you can look at the top numbers as well as query individual domains.
Addendum:
@SlashNetwork points out that it is possible to configure a mail server to require that TLS be negotiated before exchanging mail. This is true, but to quote the Postfix documentation:
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.
Now, the world is full of implementations that violate the RFCs, but this sort of thing - e.g., something that may break routine required functionality like accepting bounces and mail for the postmaster - is probably more likely to have negative consequences.
A better solution which mail gateways often allow is the imposition of TLS requirements on a per-domain policy basis. For example, it is usually possible to say "Require TLS with a valid Certificate signed by Entrust when talking to example.com". This is usually implemented between organizations that are part of the same parent company but have different infrastructure (think: acquisitions) or organizations with a business relationship (think: ACME, Inc., and their outsourced support call center company). This has the advantage of ensuring that specific subsets of mail that you care about get encrypted, but doesn't break the open (accept from anyone by default) architecture of SMTP email.
Addendum++
Google has announced the gmail will percolate information about the security if the mail path out to the reader. So these behind-the-scenes encryption steps will be brought to the notice of the user a little bit more.
(Probably still doesn't care about the certificate provenance; just an indicator of encryption of bits).
There are three points in the chain you need to consider: Transport between mail servers (e.g. between Google and example.org), transport between mail servers and clients, and the mail servers themselves.
Traffic between mail servers may or may not be encrypted; you shouldn't rely on it, and AFAIK, there is no way to enforce it from the client.
Traffic between clients and mail servers may or may not be encrypted; if you connect over SSL (either via a web interface or SMTP), your end of the chain is secure, but you can't say anything about the recipient. Conversely, if you're the recipient, you can fetch mail securely, but if the sender (or anyone in the CC/BCC) doesn't do the same, then there's your leak.
And finally, there's the mail servers themselves. If someone hacks into them, or social-engineers their way in, and the mail server stores content unencrypted, then again you're out of luck.
TL;DR: Unless you control the entire chain (both clients, and all mail servers involved), which is practically never the case, the only way to send emails with reliable security is to encrypt and decrypt locally, using something like PGP.
There's two different questions here:
- Does the email system allow emails to be sent to it over an encrypted channel and send email along an encrypted channel when the recipient's mail server supports it.
- Does the email system encrypt the contents of a mailbox when displaying it to the owner.
gownfawr addresses (1) well.
Gmail does encrypt via default for (2) so when viewing your mail, by default it is done via HTTPS, so a snooper will not be able to observe gmail sending the mail to your browser. I believe the others have not yet followed suite. (Full disclosure, I work for Google).
Gmail is set to use the 'Always use
https' setting by default, ...
"Make Your Webmail More Secure" has instructions for avoiding plain-text reads of a mailbox for a number of large webmail providers, but I cannot vouch for it being up-to-date.