The data is unencrypted some of the time on their servers.
You shouldn't use ZumoDrive if you're a Chinese dissident because it's presumptively insecure against your risks.
(1) It jumps on a company for talking about security in reasonable language that is meaningful to lay customers. Talking about security in rigorous technical terms in your marketing material is a terrible idea. When you yell at one startup for calling SSL and AES "military grade", you're making an untenable argument against most startup marketing.
(2) It makes the inane assertion that SSL/TLS is inferior to hand-rolled cryptography (paraphrased, "because when you own the client and the server you can pre-distribute keys and avoid all of SSL's complexity"). Hold two thoughts together in your head: first, that when Colin implements something like this, he's apt to be correct; and second, that when anybody else does it, they're apt to go catastrophically awry. If Zumodrive had done anything but TLS, they'd have me yelling at them, not Colin. And based on generalist developer crypto, I'm betting my yelling would be a lot scarier.
(3) It's sniping at a competitor about security. Talking up your own security is good. Talking down someone else's security is dangerous. It's bad marketing (it's turned me --- at least for the day --- from an advocate to a detractor) and it's bad business.
There's a lot of content in Colin's post I didn't feel the need to address. Am I wrong about any of those 3 points though? If not, I'm happy with my comment.
See http://chargen.matasano.com/chargen/2009/8/27/a-working-theo... for another example of a common misconfiguration of TLS implementations.
I'm not sure what my RC4 post has to do with this discussion. RC4 vulnerabilities are what you wind up with when you don't use TLS.
The choice of CAs to trust is about excluding CAs that you won't ever use, to prevent somebody from using one of those CAs to create a certificate to impersonate your server. If you are running your own CA then you are basically doing the same thing that Tarsnap does with its hard-coded RSA keys, except that Tarsnap will trust only its hard-coded RSA keys instead of a set of dozens of other RSA keys that a default TLS configuration will accept.
Either way, the question of whether you're using ephemeral keys or not is not relevant to this discussion. Nobody is going to choose backup software based on whether the encrypted transport has forward secrecy.
It would be very interesting to read why people would ban DHE. I know DHE key exchange is tricky in TLS because TLS doesn't allow proper negotiation of the parameters like it does with ECDHE and there are no commonly agreed-upon (named) DHE parameters like there are for ECDHE and IPSEC. Luckily, things are pretty straightforward if you use the Suite B profile of TLS (RFC5430), AFAICT.
There's a big difference between whether people would choose backup software based on the algorithms being used, and what algorithms should be implemented. Many people would choose backup software without any encryption if it was easy to use and cheap.
Knowing the difference between a an ephemeral keying scheme and a basic RSA key exchange does not make you prepared to implement either.
The Tor developers thought they knew enough to implement DH. Roger Dingledine has publications going back before 2000 and did his doctorate under Rivest. But they forgot to check DH parameters for 0-mod-p (a mistake lots of people manage to make) and so fielded an anonymity network that provided very little anonymity for several years.
Cryptography isn't rocket science. It's more like pyrotechnics. There aren't that many things to remember (though there are more of them than most people think; look how the browsers screwed up RSA a few years ago). It's just that the things you need to remember aren't obvious, and when you get them wrong, you blow your f'ing hands off.
I'm not saying that anybody should go out and implement all the primitives (D-H, ECC, AES, GCM) themselves.
You sound very clueful but I don't think you've thought this through. Off the top of my head I can think of zero popular cryptosystems that haven't been burned by terrible implementation flaws. I just told you that Tor, which was implemented by someone who got a PhD under Rivest, managed to screw up DH. Your response is, "if you picked better libraries, you'd do better than Roger Dingledine". No, you wouldn't.
If Tor would have used an off-then-shelf D-H implementation that already performed that check, it wouldn't have had the vulnerability. It is definitely easier to pick a TLS implementation that is unlikely to have such flaws (now)--just pick what lots of others have been using for a long time. You could do the same with crypto primitive implementations, but you run into problems because the interfaces for different libraries are all different, and in particular the preconditions and postconditions of various operations might be different. So, user of a crypto library has to fully understand all the details in order to verify what is his responsibility and what is the library's responsibility. It would be great if there was a specification that specified what every D-H implementation must do, and what the user of a D-H implementation must do to be safe.
Actually, a similar problem exists with TLS. Right now there is a draft TLS spec. that attempts to standardize how TLS implementations check a server's certificate against the server's domain name. Since there's no standard way of doing it, its harder to verify that a given TLS implementation is actually doing it the right way. And, actually, this is something that OpenSSL and other TLS implementations punt on and force the application to deal with manually. As I'm sure you've seen, lots of applications actually don't even check at all!
In particular, your post says we shouldn't be using RC4. But, RC4 is enabled by default in most/all TLS stacks, so if you want to follow that advice, you need to change the defaults in the TLS stack.
(2) SSL/TLS isn't inferior, it's the wrong tool for the job. Using the wrong tool in encryption almost always means opening up unnecessary attacks.
(3) When the competitor has such obvious holes and not only do they have them but are trumpeting them as their strong security; I think it makes a lot of sense to point out how bad it is.
In a client/server protocol, there are all sorts of things besides your data that you need secured: metadata, command & control, identification. You need an encrypted transport. TLS is the right answer for that problem regardless of what you're doing with the underlying data.