Major browsers like Chrome and Firefox are being more and more aggressive at displaying the security level of websites, for instance warning you when you try to enter passwords on a non-HTTPS website.

I just saw in GMail that emails from major websites are actually signed and use TLS (for instance an email from PayPal: "signed by mail.paypal.fr") but you have to click on a small arrow to reveal a menu to see this, and it's written in small without any colors.

OK, for the colors, GMail reserves the green for S/MIME; But still, is there a reason for not displaying a big "SIGNED by mail.paypal.fr" or "NOT SIGNED" immediately visible? This would prevent a lot of phishing, right? Why such a difference with HTTPS?


OK, I guess my question was not very clear.

The comment of @shroeder (here) partly answered it though: dumping non-signed emails is the kind of things I meant as "aggressive pushing". Again I guess I don't know enough about email security because I do have many emails in my GMail where there's not "signed by XXX" in the "more informations" bubble, so I guess it's another signature @shroeder is referring to?

I'm sorry if my question was not well formulated; it's just that I received yet another phishing email so I was wondering how come I still have to rely on myself to identify a spoofed email from a legitimate one in an era where all the important websites I have an account on have HTTPS (so they're already signing stuff all the time and my browser will freak out when something is wrong with the signature).

Turns out I didn't receive this phishing email on my GMail account but on my work one, on Thunderbird. So I guess my "true" question would be:

How come emails from my company are not signed even though they have an HTTPS website? Is it a lot more work? And how come I never saw any info in thunderbird about the "security level" of the emails I receive? Because I know thunderbird does show it when an email is signed with PGP for instance.

Instead of telling my personal story I tried to come up with a more "general" question, and... well apparently I didn't go that well.

closed as off-topic by Steffen Ullrich, ISMSDEV, John Deters, StackzOfZtuff, Tobi Nary Nov 13 '17 at 7:07

  • This question does not appear to be about Information security within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 6
    I'm voting to close this question because the OP is mixing several things up which essentially means that the question in the current form cannot be answered. The 'signed by mail.paypal.fr' is about DKIM which does not offer any encryption at all and is only part of anti-spoofing protection. DKIM is not TLS or S/MIME. S/MIME is not TLS either. – Steffen Ullrich Nov 10 '17 at 17:26
  • Some ISPs have actually started to block port 25 to prevent spam. – mroman Nov 10 '17 at 17:35
  • Ok, let's put aside the whole S/MIME thing and answer your title question. Why does it matter if the email you received was sent over TLS? Why would you need a visual indicator? Phishing is not a use case here for spoofed or invalid sender emails. – schroeder Nov 10 '17 at 17:37
  • Now let's answer your question about 'signed' emails as a phishing defense. Actually, Gmail and Outlook are really good about this. Anything not signed by an official domain (where signing is set up by the domain owner) is dumped to Spam or blocked entirely. That's a pretty big UI flag right there. – schroeder Nov 10 '17 at 17:41
  • So, the question is: what is it that you are actually asking about? – schroeder Nov 10 '17 at 17:42

There are a lot of questions embedded in your "question". I'll try to explain a few if I can. There is also a lot of confusion here between different aspects of security. Certainly there seems to be a fallacy that, because an organisation has a certificate that helps assure you that their website is actually theirs, that means you can somehow provide email security with it. That is simply not true. Web sites and email services are entirely different things, running on different servers and possibly different platforms. Quite probably run by entirely different 3rd parties.

There are two separate parts to Email encryption. The mail itself and the transport between mail systems. The former uses S/MIME or GPG and the latter uses TLS (similar to a website).

If you look at definitions for secure email services such as government ones. You will see that TLS encryption between mail services is a requirement. This is easy enough to achieve using, for example, transport rules in Exchange. Because you typically secure a limited number of end points, this is reasonably easy to manage. Ideally, mail servers would all talk to each other over TLS and mutually authenticate - to do that, the public certificates for the mail servers from each organisation have to be shared with each other. So you can see that even this can get out of hand very quickly without a complex Public Key Infrastructure in place.

On the other hand, to encrypt individual emails is an even more difficult job. The technology is easy enough. Again. it is managing the certificates and keys that is difficult. That is why this is rarely done anywhere as a blanket requirement. Even governments rarely encrypt emails except for the most sensitive information and even then, you are more likely to find an encrypted attachment than an encrypted email since attachments can be encrypted with a simple password which can then be distributed via another channel.

Very little actual innovation has happened on email clients for years. I was hitting my Microsoft contacts over the head about this the other day and encryption is one area that lacks innovation. Everyone seems to be focused on other forms of communication - maybe they think email is "done"? Likely, they think (perhaps rightly) that there is no money in it. So that is one reason you are not getting what you want.

Other reasons come from how you would calculate the security "level"? That is not an easy question and will be different for each person, organisation, mail system, content classification and more. Unless some parties come up with an agreed standard, it is unlikely this could ever just happen.

There is also a third area that impacts on your questions however and that is directly related to controlling at least some forms of phishing, namely emails that appear to come from a legitimate service but actually don't. For that, there are a number of standards that work together: SPF, DKIM and DMARC. All mail services should have definitions for these (they are stored in your DNS). They enable mail services to verify whether an incoming email actually came from an authorised mail server. This is gaining traction across mail services but is not always enforced as yet.

So the bottom line is that cryptographic signatures on emails is difficult because of the need to manage access to millions of certificates allowing verification of the signatures. However, a measure of security is provided at the server level by requiring validation of sending servers which at least gives assurance that the email came from the correct service - which I'm guessing is what GMail is actually doing. This is not generally exposed in mail clients since there is so little development and innovation happening in that area (Google are something of an exception). But on the other hand, if a mail service enforces SPF/DKIM/DMARC, you wouldn't need to see an indicator since only mail from verified servers would get through - though that could still allow spam through, just not from faked origins.

Not the answer you're looking for? Browse other questions tagged or ask your own question.