The only way to stop this is to actively resist FISA orders. That is a dangerous proposition, with the possibility that you will die, as you are challenging the world's largest intelligence apparatus. For many people, that is too risky of a position to take.
I noticed that in many countries. They are laws to protect privacy but they don't count because of fear. Whenever the force of the executive is greater than the custody of the judiciary somethings goes terribly wrong.
They should never mix but are always mixed to gain more power. History tells us a lot of how this will end.
In regards to email, the entire hassle of reverse DNS, non moving server target, etc. poses a clear privacy and monitoring issue, so giving a server mobility, ability to change IP, etc. is a mass improvement --- but of course we are comparing email to something entirely different.
Well, to reduce sniffing by the feds you must:
1. Deal only in highly encrypted data - real crypto and crypto within crypto --- different layers and types of crypto on same message
2. Be able to tunnel the data in and out through many proxies as to confuses/hide origin and destination
3. None of the routing, sender or end data should be plaintext
4. SSL-only methods of encrypting are woefully inadequate and likely already keyed into by the feds.
That's a start to the conversation.
To 1: Yup. But cryptography only works if the secret is on a different place as the information itself. Mixing cryptos does not gain much security. There are good ways to check what crypto algo is used.
Just thought about this again.
You are right - use GnuPG for encryption of the emails and e.g. ecryptfs for the encryption of your GnuPG keys.
To 2: Won't help much. They do have to many observation points.
To 3: Right. All communication of the mail server itself should be at least using TSL.
To 4: If you use self signed certificates you can choose key length and key algo at your choice. But how to secure the access to the ssl cert on a shared environment?
It looks like it is just a shift of the problem. "It is secure if you are using X". But you have to check if "X" is secure too.
If someone has full server access regardless of platform, there is always total packet dumps as well as reading the raw disk files.
It is in part why shared environments are unsecured unknowns.
Securing such an environment for virtualized customer, well, can it actually be done? Would require full cryptoed packet traffic and crptoed disk. The disk part is a puzzle I've never figured out since the OS would need to have credentials to read and write and that would require full access to the volume.
Yup. Crypto disks are fine on KVM - but you have to connect to an not encrypted VNC to enter your password on boot.
Everything else can be done via OpenVPN.
But like SSL - the OpenVPN connection is only secure if no one does have access to your keys...
Someone should write-up some good tutorials... Just sayin'.
Been wanting to set up my own mail stuff for a long while, more as a learning project than for privacy reasons, but it can be both now.
Allready in the works.
