2

With regards to encryption and preventing a 3rd party from viewing my emails (and ignoring validity/signing), is encrypting an email via PGP or S/MIME useful when I control my server and my recipient controls their server?

I'm assuming the servers are not compromised and do not have other untrustworthy admins. And, for the sake of this argument, they are both physical servers, so there shouldn't be a problem of virtual machine vulnerabilities.

From my understanding, email between servers is encrypted, as long as they are both set up to support that. Are there other security concerns that are still valid that would be negated by email encryption?

1
  • Do you trust your backup tapes, where they are archived off site? Commented Mar 25, 2015 at 14:06

4 Answers 4

3

With regards to encryption and preventing a 3rd party from viewing my emails (and ignoring validity/signing), is encrypting an email via PGP or S/MIME useful when I control my server and my recipient controls their server?

In practice: No, but you need to make sure many other elements of the network aren't fooling you. I will concentrate on the transmission here. End-to-End encryption gives to extra security on top of other elements, described here. If some elements fail, GPG still protects the content of your mails.

First, you want to make sure, you can contact the right recipient’s server. To do that, your sending mail servers does a DNS-Lookup for the MX-Record of the domain. Then the resulting FQDN has to be resolved to get an IP. This is the first possible attack vector, as the used DNS-Server must be trustworthy and not controlled by the attackers. Additionally, the DNS can also be fooled. You may have a look on DNSSEC or DNScurve, both want to ensure, the answer from a DNS is authoritative, as the DNS protocol is completely unencrypted and tampering is very easy.

A possible solution is to overwrite the domain -> MX and A lookup on your server, by specifying a custom transport in your mailserver explicitly ("use this server to deliver mails to that domain").

The next possible problem is, you can't be sure you're talking with the real other side, even with SMTPS (SMTP over TLS) or SMTP+STARTTLS, as usually server certificated are not checked. Thus, the sending server must check the other's server certificate, and also the other way round: The receiving server has to check the client certificate of the sending server, because otherwise the receiver can't be sure, the trusted server sent the mail. Also make sure the connection can't be downgraded to plain SMTP.

As CA's and the PKI-System also have their problems, certificate pinning is appropriate. Others already brought up the issue of backups.

1

If you are going to rely on STARTTLS (assuming that is what you mean by supporting encryption between servers), the servers will need to be configured to enforce the use of STARTTLS rather than the normal default, which is opportunistic.

The opportunistic 'mode' is vulnerable to a man in the middle attack.

1
  • 2
    Enforcing StartTLS is not enough to prevent a MITM attack. In principle there is no relation between the domain name and the server repsonsible for receiving the email. The mx records tell you to which server you must send the mail to. Since DNS cannot always be trusted, StartTLS by itself is not enough. Things will be different if you do not rely on mx records though (i.e., deliver directly to IP address) Commented Mar 25, 2015 at 19:47
1

In a perfect world with no untrustworthy people we'd never need any security at all. We don't live in that world, and there's far more people we need to trust than merely administrators and ISPs. Adversaries can range from the NSA armed with National Security Letters, hackers and packet sniffers to skilled attackers using zero day exploits. Rogue admins are really the least of your worries.

Look at the actual email breaches that have occurred. Sony is among the biggest and most embarassing and having their email hosted on their servers didn't prevent a massive leak. There's countless other email breeches with causes ranging from bad password management to sophisticated hacks.

Rogue admins are rare enough that you never hear of them.

1
  • Right... just that one guy what's his name... stuck in Russia...
    – RoraΖ
    Commented Mar 25, 2015 at 15:51
0

When your systems are completely save and trustworth you would not need additional encryption. But can you be sure that your systems realy are that save? For example if one of your servers gets hacked or if (as makerofthings7-c-lamont pointed out) your backups are compromised your entire security is broken.

When you use something like PGP or S/MIME an attacker would have to steal every private key of any user he wants to wiretap. This may mean that the attacker needs to hack a dozen computers instead of one server to get the same amount of information.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .