
NSA-proof your e-mail in 2 hours (2013) - 0xmohit
http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/
======
daenney
NSA-proof this is certainly not. It might complicate reading your messages in
transit, just a bit, but that's about it.

E-mail messages leak metadata all over the place. Though according to the
author 1/3 of their email volume is to parties that support TLS, that still
leaves 2/3rds up for grabs. If you happen to send a message to two people, one
who's e-mail provider supports TLS and one who doesn't you're toast too.

There is no mention of encrypting your messages using GPG or any other tool.

Though they do seem to use EncFS for the email database, then there's the RAM
to worry about, CryptKeeper could be interesting (or OpenBSD's encrypted
virtual memory), your CPU and a bajillion other components both hardware and
software.

Then there's passages like this:

> For security reasons, I’m not going to disclose the measures that I take to
> avoid others gaining root on my system.

If that's your security model...

There are still myriads of exploits that would allow you to gain access to a
machine, and as a consequence read the data, which really shouldn't be beyond
the capabilities of the NSA if they really wanted to.

~~~
Terretta
I agree, this essentially cancels out the entire premise:

> _For security reasons, I’m not going to disclose the measures that I take to
> avoid others gaining root on my system. A good start might be changing your
> root password, or keeping your mail server under your pillow at night._

~~~
nanna
Lets not forget the context of this. This was posted one month after the
initial Snowden revelations and the problem it was trying to fix was that all
the major email providers had known backdoors to the the Five Eyes. 'NSA-
Proofing' in this context meant running your own email server which was not
known to be backdoored.

Granted, its title is hyperbolic, but providing a way to get rid of a known
vulnerability in the email chain in a reasonable amount of time (definitely
not two hours though) was (and perhaps remains) a reasonable security measure.

Original HN discussion here:
[https://news.ycombinator.com/item?id=6045194](https://news.ycombinator.com/item?id=6045194)

------
partycoder
"NSA proof".

Running your non-backdoored AMD or Intel processor, on your non backdoored
operating system, with non-backdoored OpenSSL, non-backdoored pseudorandom
generator, on a non-tampered Internet, non-backdoored network equipment... :)

~~~
zschallz
Also the biggest problem is that almost everyone else one sends an unencrypted
email to is not "NSA-proof."

------
ThrustVectoring
Anyone up for turning this into a Docker image or the like? I remember this
being very useful for simplifying the install of the machine learning software
required for running Deep Dream.

~~~
stinos
[https://mailinabox.email/](https://mailinabox.email/) does pretty much
everything listed and more (and is being reviewed by more people so it might
be better and more secure), automated, so doesn't take 2 hours but rather 20
minutes. They have a docker branch in github but atm there's no work on it
anymore. It does work very well though. In a nutshell: if anyone is up for
working on secure email in docker, please continue the work done on MIB
already and contribute.

~~~
neuromute
I'd quite like to run this on a Raspberry Pi (3), but from what I gather,
there is no support at present.

~~~
nanna
From experience, this guide works fine on a Pi 2.

------
z3t4
Prepare to spend a whole day if you want a setup like this. And if you want
web mail, you are only half done ... Then you would also want to make a script
to reproduce it, in case you had to reinstall your server. I'm thinking
there's a business opportunity here, to provide a maintained container, for
e-mail in particular. But also to make linux "apps"/servers more modular.

I would also like to thank everyone who write tutorials like this for free.

~~~
brbsix
Off the top of my head, that sounds just like Mailpile[0]. There's obviously
many other less recognizable solutions.
[https://github.com/tonioo/modoboa](https://github.com/tonioo/modoboa) sounds
pretty similar.

Lots of players in the modular Linux "apps" and server space. For developers,
there are Docker images, OVF virtual appliances, things of that sort. From
more of a user perspective, there's sandstorm.io. I believe Mailpile was even
on the Sandstorm app list at some point, not sure if it still is.

[0]: [https://www.mailpile.is/](https://www.mailpile.is/)

------
giomasce
Running a mail server is much more than its first time daemons configuration,
but it is interesting anyway as a tutorial.

~~~
dest
Not ending in the recipient's spam folder can be difficult when your IP is not
clean enough.

------
dogma1138
As long as one end of the email chain isn't secure this whole exercise is
kinda pointless.

~~~
WireWrap
For that one chain at least. You don't want to be the end that causes all of
your chains to be insecure.

Related: if you use your own server you can setup as many aliases as you need.
You can use a unique one for each company you do business with, for example.
Doing so increases the probability that you will detect when your email
address (and possibly other info) has been shared or leaked at the other end.
It isn't guaranteed to happen, but what often happens is the compromised email
address is used to send you spam. If the email address is properly unique (not
easily guessed or dictionary attacked) you'll immediately know which company
might have leaked it and you can investigate. You can quickly change that one
email alias and registration, without affecting your other accounts.

~~~
dogma1138
Not really, or well really not.

To have email working you need to own a DNS record which means that your
details are on record some where (domain privacy settings don't really work
against an adversary like the NSA or anyone with a decent enough legal team).

To pay for the server you need to pay for hosting which leaves another paper
trail, you can't host mail servers in your home as your ISP will block SMTP
traffic in most cases to combat spam from botnets, if you still want to do it
you have to use your ISP's SMTP relay which isn't "NSA proof" and also quite
likely puts every email you send on a list easily accessible by law
enforcement.

When you run your own server you inherit all the security risks associated
with every piece of software which runs on that server, most people aren't
really good at dealing, zero-days are also usually patched prior to disclosure
by the big players (e.g. Heartbleed) and even when not companies like Google
will have a plethora of mitigating controls that reduce the impact of any
potential non-disclosed vulnerability.

As far as the aliases go if you run your own server aliases mean nothing even
if you buy a separate domain for each alias the MX records will still be the
same which means that all email addresses can be traced to you, if you only
want aliased for disposable mails/spam control then any current mail provider
usually offers unlimited aliases also.

As far as controlling the chain you aren't really, you have little control
over how the mails are being relayed, you might be forced to use an email
relay (some ISP's actually do transparent mail relays), your target might be
behind a mail relay, and even when not you don't know if the guy you are
sending it too doesn't use gmail or any other provider to manage their
mailboxes using POP3.

And the last part and what people usually dislike being brought up is that
actively trying to avoid the NSA puts you on their radar, the NSA has
different levels of wide range and targeted surveillance the more
"interesting" you seem the more likely you are to be tagged by one of their
more targeted programs.

Now this isn't an argument that results in saying "you shouldn't encrypt
anything and send stuff in the clear" but it is an argument that if you
actually care about operation security then not standing out is a critical
part of your opsec. People often point out and say that "security trough
obscurity" is a fallacy, but that on it's own is even a bigger fallacy,
obscurity is a critical part of real world security (whether it's technical or
operational) the important thing to remember is that one must not rely only on
obscurity to ensure security but one that ignores it completely just exposes
them selves to unnecessary risks.

------
the_angry_angel
Probably worth noting that DSPAM is no longer in the Debian repos.

See [https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=754810](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=754810)

------
x5n1
Waste of time considering 50-60% of your e-mail goes to or comes from Gmail.

~~~
cxseven
Gmail, and webapps in general, should support efficient client-side encryption
and signing.

~~~
vbezhenar
Web platform is not suited for client side cryptography, because server can
serve a customized scripts to you and there's no practical way to find that.

~~~
dogma1138
That's not quite true you can validate the scripts the server is sending you,
various hashing algorithms are sufficient and although not prevalent today you
can always use the "archive" attribute[0] in your script tags to provide an
archive with digital signatures (this was a feature in Netscape and even early
IE) it was used in the mid to late 90's when SSL wasn't that prevalent.

But this isn't that relevant today mainly because of SSL, and while it's true
that the server can serve you a modified script even over SSL but it can only
do that in such cases when the server has been compromised (excluding any
attacks that break/MITM SSL) in which case if you can't trust the content that
is served by the server you can't trust the content stored on it either.

But lets say that it's still not enough then well a client side encryption in
the browser either natively or via an addon can provide the required
functionality to make web apps work properly even without providing all the
functionality over the wire. There are quite a few hybrid webapps for Chrome
that do not work without an addon or those for which the addon adds allot of
functionality that could not be efficiently offered by current web only
standards.

[0][https://msdn.microsoft.com/en-
us/library/ms970704.aspx](https://msdn.microsoft.com/en-
us/library/ms970704.aspx)

~~~
vbezhenar
I'll give you an example. There's a software that was audited: Truecrypt. I
know hash of the executable that was audited, so I can download that
executable, verify it's hash signature and use it for my purposes.

But if I use crypto in browser, it's like I'm downloading Truecrypt every time
from the website. And there's no easy way to determine that I downloaded
exactly that binary that was audited and used by everyone else. So if FBI (or
narco cartel) reached authors of that software and they want to attack me,
they have a perfect attack vector: identify me and serve me a modified code.

There could be an addon providing that functionality, but I'm not aware of
any. And installing additional addon isn't much easier than just installing a
separate software. Web apps are only good because they are easy to launch.

~~~
dogma1138
When you use crypto in the browser it will be either natively provided by the
browser or via javascript.

In both cases you can always ensure the integrity of the crypto if you trust
the initial integrity check.

You can verify the hash for every javascript you download it's even integrally
supported by the browser (but not used as SSL solves this issue more easily).

The only thing you need to so is to have a hash of the javascript code that
you know has been audited which you considered to be trusted beyond that if
you download it once or a million times it doesn't matter.

To make it a bit more cleared the TrueCrypts bootloader is not encrypted and
there is little to no integrity checks as it doesn't support TPM or CPU
specific security features in this case you have no ability to validate that
the TC instance that you boot is the actual instance that you have installed
and that it wasn't compromised.

------
prdonahue
This is pretty weak, IMHO. You should at least use on-the-fly PGP encryption
like Mike Cardwell detailed:
[https://grepular.com/Automatically_Encrypting_all_Incoming_E...](https://grepular.com/Automatically_Encrypting_all_Incoming_Email).
You basically just add the public keys to the exim account and it uses a
transport filter to look them up and encrypt automatically. With a properly
configured client, you'll never have decrypted data on disk.

------
libeclipse
>For security reasons, I’m not going to disclose the measures that I take to
avoid others gaining root on my system.

Security by obscurity is certainly not NSA-proof.

------
kozukumi
Email was not designed to be secure, it was designed to be convenient. Trying
to make something that is insecure by design secure is never going to be
secure.

Having said that taking some steps to better protect yourself is a good idea.
Just don't fool yourself into thinking you are secure from a body such as the
NSA.

~~~
brbsix
Isn't that what we have crypto protocols for? To secure something that is
insecure by design? The Internet was not designed to be secure either, which
is why we use HTTPS. If you need the contents of your email to be signed and
confidential, you use public key encryption. Or maybe that was the point of
your comment?

~~~
kozukumi
Yeah that was the point :) You can wrap up the contents but everything else is
open.

------
akshiv
Does it matter? Every person you will communicate with is open to having their
messages read. As far is information gathering goes, you are not making
anything harder to access.

------
exolymph
Potentially useful for 1) paranoid people or 2) people whose threat models
warrant this level of hassle.

~~~
woodman
Or people who knows that email stored on a third party's server for longer
that 180 days is legally considered abandoned. Abandoned property enjoys no
legal protection.

~~~
peteretep
That's incorrect. After 180 days, only a subpoena is needed, rather than a
warrant.

~~~
woodman
You are right, I made an overstatement about a deviously complex situation. An
administrative subpoena, which doesn't come from a judge - just the
investigating federal agency, is required for old mail. They send out tens of
thousands every year, so I don't think it is a stretch to describe the barrier
as essentially a form letter on federal stationery.

------
lolidaisuki
A better way to NSA proof your mail would be just using Freenet's mail or
something else like that.

