NSA-proof email via DirectAdmin?

As the article says in the 'edit:', encrypting the stored mail won't stop anything happening in traffic. Also the directories are always decrypted when the box is running, so hackers/nsa who login can still access it as well.

See this thread on e-mail encryption: https://forum.directadmin.com/showthread.php?t=35322 - as it says there, you would need the clients to encrypt/decrypt.

If you want to encrypt something, I would suggest to encrypt the whole system, but it's only for when you're worried someone might steal your hardware.

Also you would like to use TLS between smtps, but I believe it's still not *required* by todays standards, and even less required is the validation of the certificates used by tls. Only recently Exim has enabled logging when a certificate doesn't match the server. Most servers (and probably yours) don't have a matching, validated by known issuer, certificate, and most smtps don't check them (so even if you do everything right, the other end probably wont)

To the title: NSA proof e-mail, when using a private setup like DA you're a big step ahead, as I believe that NSA and the such have direct access to gmail/hotmail etc. In order to get your e-mail, they would either have to intercept your traffic or would have to hack/confiscate your box. Also keep in mind that the other party you e-mail to or are receiving from shouldn't use these big email providers or else it's meaningless anyway. For the record I personally still just use gmail and assume everything I do on the internet can somehow be compromised.
 
Last edited:
You certainly have a valid point in that before doing anything, I should think more thoroughly about the scenario I am actually trying to protect myself from. :)

I guess it's just the hunch that I've been encrypting my hard drives and my email traffic for many years, yet the server storing my mail has all data in plain text. But thinking about it, it's probably rather pointless to go to great lengths as long as the senders and recipients of the messages I have don't encrypt their mail as well.

I actually came across the email encryption thread you linked to before starting this topic, but it's 5 years old and for this specific topic, that seems like ages. (Not only, but also because it recommends using a Blackberry, which is hardly commonplace and useful advice nowadays.)

But yeah, hardware theft (or even confiscation) is probably not the actual concern.

By "TLS between smtps", you simply mean it's good practice to use a secure connection for sending mail, or is there anything else I'm missing?
 
About TLS in smtp, I looked up the RFC about it:
A publicly-referenced SMTP server MUST NOT require use of the
STARTTLS extension in order to deliver mail locally. This rule
prevents the STARTTLS extension from damaging the interoperability of
the Internet's SMTP infrastructure. A publicly-referenced SMTP
server is an SMTP server which runs on port 25 of an Internet host
listed in the MX record (or A record if an MX record is not present)
for the domain name on the right hand side of an Internet mail
address.

Any SMTP server may refuse to accept messages for relay based on
authentication supplied during the TLS negotiation. An SMTP server
that is not publicly referenced may refuse to accept any messages for
relay or local delivery based on authentication supplied during the
TLS negotiation.
Click to expand...
In short, it means that traffic between two smtps do not need to be encrypted. If you do configure Exim to require encryption, you'd simply be not getting all e-emails.
It also says that it's OK to require TLS from your users to your smtp.

The problem is that everyone running a mailserver would need to have purchased a certificate, although with the letsencrypt.org initiative things might be getting into the right direction. They will offer free trusted certificates for everyone. At one point in time I expect they will have to modify the RFC to make TLS required.

About the old thread, the idea behind it seems to be still valid I think, with GPG you've got clients issuing their own certificates in a way. Just with SSL/TLS you've got a private and public key, with GPG this is the same. But the clients are signing the e-mails with the public known key of the recipient, and the recipient is decrypting it with their private key. But GPG never became popular because it's too much hassle to work with. But in the sense that it is the clients who encrypt their messages, not the server is quite valid if you really want to secure your messages. Simply because the encrypted data can be transfered, stored and it doesn't matter because only the receiver can decrypt it with his own key.

So to communicate secure, you need the other party to participate:
- GPG, both parties need to know how this works
- Requiring TLS: both smtps need to have trusted certificates + both have to validate them, also configure strong ciphers

What a best practice is in the current state of things, I would say configure TLS for your clients. A lot of snooping takes place between client<>server, with open wifi's etc.
 
You must log in or register to reply here.
Back
Top