AWS: We’ll go to court to fight government requests for data
itworld.com
itworld.com
That strikes me as a little misleading. I'm sure the subpoena would request a snapshot of all running VMs's memory & CPU state, from which (I believe) it's relatively easy to extract encryption keys. If the first subpoena didn't, the second one sure would!
Using AWS the way cpercival does for tarsnap (with keys managed outside, and S3 as dumb storage) is reasonable. Using AWS to run a game or other toy app is reasonable. Using AWS if you yourself are a USG entity (and thus immune to lesser legal action) is fine.
I can't imagine using AWS (or any outsourced cloud provider) to run sensitive apps using current EC2-type technology in the current legal climate in the US. The other scary thing is AWS is probably among the best providers for technical security, and still has this vulnerability (disclaimer: I haven't yet checked out Google Cloud Engine much).
Colocation or managed hosting is borderline in some situations too (particularly if you allow the provider unlimited access to singleuser mode on your boxes, don't encrypt drives, manage keys and credentials through the provider, etc.), but it's a lot better than virtual hosting for anything at all sensitive.
It's not just official USG action to fear; it's provider staff or technical compromise as well.
That's interesting. I couldn't find anything that describes the hushmail compromise in this way. Do you have a link that explains it?
(Am currently thinking about how to make a more secure email service)
The enemy made Hushmail serve a "bad" applet to certain users which (in addition to decrypting) sent back either credentials or key to hushmail (and thus allowed decrypting of the mail).
There are ways to address this attack but they're essentially in the realm of release engineering and separation of control; you have one group develop, another group serve, another group execute, and the groups have to be mutually distrustful and audit everything that passes between them. This is hard.
The irony is I worked for the company which developed the initial hushmail product back in 1998/1999. It had to be done by non-US Citizens due to export control, so I wasn't involved, but pretty much as soon as it was clear they weren't going to address this (obvious) attack in their threat model, I assumed they were either incredibly incompetent or an active honeypot, so I ceased any involvement and never used the product. (an adequate solution for java applets would have been putting the signing key under neutral third-party control; I don't think a java applet based solution is viable today, since java is such a clusterfuck; I'd just do a secure iOS or Android app instead and stick to mobile users, like silenttext does from silentcircle).
I'd personally skip webmail or even desktopmail and just build something which is mobile-secure-mail/messages/voice.
Silentcircle is my favorite voice product right now, but it's fundamentally doomed (IMO) due to being commercial on both sides. I'd want something where at most one party in every communication is a paid user, and the counterparty uses a free and lightweight app. And/or something with great group management functionality, which it also doesn't do. The market for discrete individuals who both pay for the service and only communicate with other discrete disconnected individuals is kind of zero.
Crypto.cat internally implements OTR now, so it has forward secrecy. So all of these attacks are around gaining limited access -- to the contents sent using the exploited application.
The old javascript version was at risk to cloudflare, the crypto.cat team, and everyone else. Plus browser exploits. It was horrible. The worst part was the crypto.cat developers responded very...emotionally...to any criticism of their security, which kind of detracted from the whole thing.
This whole "binaries distributed by a third party" model used on mobile and for browsers does expose a lot of problems. Since there isn't a strong cryptographic signature on the binaries linked to a key uniquely controlled by a developer and securely distributed to the end user and verified in something the user can trust, the platform or store vendors (Apple, Microsoft, Google, Mozilla, ...) can pretty much screw users at will. (they can just use a different trusted key to sign the binary).
The old "distribute source code with PGP signatures or signed hashes of the tarballs" is still the best way to distribute secure software.
My #1 feeling about crypto.cat is extreme envy for the Catalan domain name.
Could the FEDs incentivize AWS to be quite about it? I'd guess yes.
To date I still don't believe what Google/Amazon are saying. It all feels like weasel words. Like when Obama stated that the NSA "cannot" listen to your calls. He meant that they cannot by law, rather than cannot because they dont have access. The way he phrased it though meant that 80% of people listening would've thought it was the latter definition.
And to have the National Intelligence guy on record lie to Congress? Who is controlling whom here? It really does feel like the US government has lost control of its intelligence services.
Now don't mind me, I'm busy trying to find somewhere on the map I can relocate my services to.
Really what he meant is that the NSA can't target their listening at you, but they certainly can listen to your calls accidentally or in a mission targeted at some other person or targeted at you if they don't know for a fact that you're a U.S. person, and once they do listen to your calls, they certainly can forward that information to any appropriate law enforcement agency to take action against you, and they certainly can use that information to get a warrant to legalize targeting you if need be.
So really what he meant is that yes, the NSA can listen to your calls, "legally", in almost all circumstances. By taking care not to initially link up phone numbers and names/addresses, they can maintain that they didn't know you were a U.S. person for as long as they need to.
If you didn't understand that from his use of the word "cannot", well, I guess that's just your poor listening skills at fault.
> “If a U.S. entity is serving us with a legally binding
> subpoena, we contact our customer and work with that
> customer to fight the subpoena. We will do that proactively
> and help the customer in any way to comply with the
> subpoena or fight it.”
> If Amazon faced a subpoena that required it to keep the order secret, such encryption would be useful to customers. “If the data is encrypted, all we’d be handing over would be the cypher text,” he said.
It does protect you for S3 if and only if you conduct the crypto outside AWS and generate/manage the keys yourself (e.g. how tarsnap does it). It may protect you for some of the other AWS services IFF you use them in the same hybrid way, but I don't know of anyone who uses AWS's database services without just using EC2 nodes primarily to talk to them.
It's missing a few elements you'd need to build a really awesome secure cloud, though. (actually, intel hardware was missing it)
http://www.blackhat.com/presentations/bh-dc-09/Wojtczuk_Rutk...
This tells me two things: First, that Amazon gets these requests often enough to have a well-tested procedure for handling them; and second, that it's still very much a manual process -- and that government agencies can't just reach in and grab data on their own.
They're in Switzerland and seem committed to maintaining your data/security (and they have the full force/support of Swiss law).
Their UI is super usable. It's a true pleasure to use. You can choose from several posix distros and a Windows one. There's decent selection for different sizing. But they're in beta now, so there's not a full lineup of features. The pricing is very good. And the support is awesome. I've raised a couple of tickets and they were responded to in a couple of hours.
Also, AWS recently signed a huge deal with the CIA (http://www.businessinsider.com/cia-600-million-deal-for-amaz...). I doubt that a company that works so closely with US government agencies is jumping through hoops to protect its customers from government snooping.
http://www.wired.com/threatlevel/2013/04/google-fights-nsl/
NSL's are a serious issue and as much a threat to our liberty as what was disclosed by Snowden's leak. The outrage sparked by Snowden's effort is hopefully something that leads to good reform and protection of our liberties, but the fodder for outrage has existed for a long time now.