I was reading through different posts here about email security. After reading these I still have some questions.
I understand that S/MIME can be used to transfer email securely between servers.
Is S/MIME used by Gmail, Yahoo, or Hotmail when I send e-mail from one of their accounts?
Or is SSL/TLS the sole mechanism for providing security?
Do all major e-mail providers use SSL/TLS?
Under what conditions are e-mails commonly sent unsecured?
TL;DR - Without end-to-end encryption, such as S/MIME or PGP, being supported and used by both sender and recipient, it's a fair presumption that your e-mail has been transmitted or stored in the clear, or otherwise readable by a third-party, somewhere along the way.
I think you have some mis-conceptions of what S/MIME and SSL/TLS are, or how they work.
S/MIME is a mechanism for providing end-to-end message security. Encryption, digital signature, decryption, and signature verification are all done at the endpoints by the client software. The intervening e-mail servers and service providers have nothing to do with this, as the messages get passed along just like any other. Further, and perhaps most importantly, S/MIME must be supported by both the sending and receiving clients in order to work. This is beyond the ability of any single e-mail provider to ensure.
That being said, I'm not aware of any common freemail provider (i.e.: GMail, Yahoo, Hotmail) that is currently facilitating S/MIME in their browser-based clients. Certainly none of them are, nor would they want to be, enabling it as a default.
The reason this cannot work at the service provider level is because of the requirement for both endpoint clients to support the protocol. Since the service provider of the sender has no control over the client software used by the recipient, enforcing S/MIME use on outbound messages would result in many (if not most) recipients not being able to read the sender's e-mails.
The only conditions under which S/MIME will work are when all participants in the e-mail conversation have S/MIME-compatible clients, and everyone has (and has verified) each others' public keys. Again, this is not something that any individual e-mail service provider can effect. They may conceivably be able to facilitate this between their own users, but they do not have the same power to protect e-mails going to/from external endpoints.
SSL/TLS are technologies commonly used to secure communications between clients and servers and from server-to-server. However, here we again run into a similar situation as with S/MIME - both parties to the conversation must support it. While some service providers may do this, no service provider can guarantee you that SSL/TLS will be applied to every message you send because they do not have control over what the receiving server is configured to support.
To address your concerns more concisely, point-by-point:
None of the above use S/MIME. While it would be a nice feature for them to support in their web clients, it would be infeasible for them to guarantee that it will work for all recipients. You can get around this to some degree by using your own e-mail client with S/MIME support, instead of using the web interfaces. However, again, this will only work where you have coordinated this with your intended recipients.
SSL/TLS is commonly used to protect the web sessions by which e-mails are composed, and the client connections by which they are sent. It's also used to protect server-to-server communications along the way, but no service provider can guarantee that every recipient's e-mail servers or client will support and maintain that protection along the way.
Many providers do use SSL/TLS, but you should check with yours yourself if you're concerned. Again, though, this cannot guarantee that your e-mail is protected through transmission and storage every step along the way to every recipient.
Any time you are sending/receiving e-mail which is not protected by S/MIME, PGP, or a similar end-to-end encryption solution, you must assume that the message has been transmitted or stored in the clear, or in another form readable by a third-party, somewhere.
The last point touches on an issue I've not yet addressed - e-mail storage on the server. All e-mail service providers, by the nature of their service, must store e-mails exactly as they were received or by using some form of encryption that they themselves can reverse. Otherwise, they will not be able to forward the e-mail on in a readable format to others or display it to you in your web browser. If you're not using end-to-end encryption, that means your e-mail is being effectively stored in the clear. This leaves it vulnerable to malicious insiders, or anyone who manages to hack into your e-mail account or the server's database.
2 SSL is used in two ways and while the providers seem to be pretty consistent about using it for server to client communications, they vary using it for server to server communication.
I ran some tests and while Gmail and Yahoo both use encryption if both sides support it, Hotmail never uses it for server to server communications. This means that communication between Hotmail and other internet providers is always in clear text
1) In general S/MIME is not supported by Gmail, Yahoo, etc when using their web-based email client (i.e. going to www.gmail.com). If you want to use S/MIME with these services you have to use a 3rd party email client (i.e Mozilla Thunderbird, MS Outlook, etc) and have a way to manage and distribute your public and private keys. The reason it is not easy to use S/MIME with Gmail etc is because the primary source of revenue for these companies is targeted advertising. The primary source of information used to target that advertising is the content of your emails. If they make it easy for you to use S/MIME for end-to-end encryption (so that they can no longer scan your emails) it undercuts their primary source of revenue (information about you).
2) Yes, but keep in mind that protection is often partial or incomplete. Just because the email service provider allows you to connect via SSL/TLS does not mean they support SSL/TLS connections to other email service providers. See 4) below.
3) No, ~50% of emails travel to or through providers that do not support SSL/TLS. I believe AOL only started supporting SSL/TLS connections in 2014 (via their web-based email client). See 4) below.
4) Under common conditions emails are not secure for several reasons. First, the email provider is scanning the incoming and outgoing emails to provide targeted advertising. Second, ~50% of the time the connections between the various email service providers do not support ANY encryption so the emails traveling between these providers must be sent as plain text. You have no ability to control this process because it is the connection between the providers. For example, if you send a email from your Gmail account to a friend with a Yahoo account the email must be transmitted from Google's servers to Yahoo's servers. The security of that connection depends he willingness of on Google and Yahoo to work together. I believe Google and Yahoo only recently started supporting encrypted connections to each-other. Google posted some data about this in June (2014). You can read the details here: http://googleblog.blogspot.com/2014/06/transparency-report-protecting-emails.html
How commonly is SSL/TLS used by e-mail providers?
Google provides some great up-to-date stats on domains that are using TLS to encrypt email between hops.
http://www.google.com/transparencyreport/saferemail/
