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.
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.
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.
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... :)
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.
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.
https://github.com/sovereign/sovereign is a series of Ansible scripts for setting up your own sovereign server. It requires a bit of TLC, and the move to Jessie is not without growing pains, but once you have it working, it just works.
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.
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 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.
It's almost the same setup (and inspired by) the OP's link but in a simple script that you can deploy to a cheap VPS. I've been running my own email server for years, but I've considered switching to this just for the reduced maintenance.
I have my own ansible scripts to setup my mail server. It took a couple hours of hacking. Centos 7 provides a pretty good mail setup out of the box. All you need is to setup dkim and ssl certs (easy with letsencrypt).
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.
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.
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.
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.
The problem here is that there is no way for the average user to tell if the server itself is serving you client-side code that will actually encrypt your data before sending it to the server. The browser security model explicitly depends on trusting the remote server (whose identity you verified using TLS, and with whom you can communicate securily) with whatever data you enter client-side.
With end-to-end encryption of e-mail, the server is not part of the immediate trust model; it is to act only as a transfer agent. This is why end-to-end e-mail encryption is easy with a dedicated mail user agent (MUA) such as Thunderbird with Enigmail, but awkward with webmail, where you need a third party browser plugin (such as Mailvelope) to provide the encryption step.
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.
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.
it could be if that was an open source extension provided as a plugin that you could use a custom version of... so that the encryption script was not being served by the webapp. Say the EFF maintained such an extension.
Most people who have an OpenPGP key upload their public key to one of the on-line key-servers. These key-servers sync keys with each other, so you can find any published public key from any one of them.
> What does Google do when it receives a legal request for user data?
> Respect for the privacy and security of data you store with Google underpins our approach to producing data in response to legal requests. When we receive such a request, our team reviews the request to make sure it satisfies legal requirements and Google's policies. Generally speaking, for us to produce any data, the request must be made in writing, signed by an authorized official of the requesting agency and issued under an appropriate law. If we believe a request is overly broad, we'll seek to narrow it.
There are rare narrowly defined circumstances when Google will voluntarily hand over data without those legal checks:
> Sometimes we voluntarily disclose user information to government agencies when we believe that doing so is necessary to prevent death or serious physical harm to someone. The law allows us to make these exceptions, such as in cases involving kidnapping or bomb threats. Emergency requests must contain a description of the emergency and an explanation of how the information requested might prevent the harm. Any information we provide in response to the request is limited to what we believe would help prevent the harm.
A B C
United Kingdom 3,146 75% 6,056
United States 12,002 78% 31,343
A = User data requests
B = Percentage of requests where some data produced
C = Users/Accounts specified
> What's current best practice for people using gmail who want client side encryption?
Use OpenPGP and access GMail through IMAP with a mail user agent (MUA) such as Thunderbird with Enigmail, or one of the other mail clients that support OpenPGP (either directly or by means of a plugin).
By doing this you strictly separate mail transfer (which GMail does for you) and encryption (which you and the receiver perform locally with OpenPGP key-pairs). GMail sees only strongly encrypted data for which it has no keys.
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.... 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.
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.
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?
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.
>people whose threat models warrant this level of hassle
If gmail is too insecure for your threat model you should stay away from email all together and find better ways to communicate. Methods like electronic dead drops, or sending encrypted communication over saturated media like online games or any real time P2P messaging service are probably more suited for this situation.
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.
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.
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.