4 ms·

This isn't quite fair to the original post. He makes at least two points you ignore: The data is unencrypted some of the time on their servers. You shouldn't

by three14 17y ago

This isn't quite fair to the original post. He makes at least two points you ignore: 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.

tptacek 17y ago
I have three issues with this post. (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.
- briansmith 17y ago
  TLS is not so easy to implement correctly. You still have to decide (a) which version of TLS to support, (b) which ciphersuites to support, (c) which signature algorithms to support, (d) which CA(s) to trust, and (e) which certificate revocation checking scheme(s) to use, at least. People tend to choose the defaults, which mostly works. But, Colin does make a valid point that the default list of CAs in particular is probably not the best choice considering the policies of the companies making these default lists. See http://chargen.matasano.com/chargen/2009/8/27/a-working-theory-about-rc4.html http://chargen.matasano.com/chargen/2009/8/27/a-working-theo... for another example of a common misconfiguration of TLS implementations.
  - tptacek 17y ago
    The defaults on TLS work just fine. It's not 1999 anymore; your code isn't going to accept SSL2. No decision about ciphersuites, signature algorithms, or CAs (note: just run your own) are going to impact your security. 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.
    - briansmith 17y ago
      I disagree. The choice of ciphersuite is important. In particular, it is much better to choose DHE/ECDHE ciphersuites over the non-DHE/ECDHE ciphersuites to protect against the compromise of your server's private key. 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.
      - tptacek 17y ago
        The funny thing about that comment is that I've worked in several environmens where DHE was not only not preferred, but explicitly banned. Not only that, but DHE is even more complicated than SSL as most people understand it --- if you're in favor of it, you're making an even stronger argument for TLS (DH is remarkably easy to screw up). 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.
        briansmith 17y ago
        The main thing I am trying to say is that, if you understand crypto enough to configure your TLS optimally, you can do the crypto without TLS. And, if you don't understand crypto and TLS this well, you shouldn't be trying to store the public's private data in a way that you claim to be secure. (This isn't about ZumoDrive; They may know quite a lot about these issues, and their choices might very well be optimal for the use cases they are trying to address.) 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.
- janzer 17y ago
  (1) Calling their security/cryptography "military grade" should be a warning signal. (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.
  - tptacek 17y ago
    SSL/TLS is exactly the right tool for securing data in transit. That Zumodrive lacks the security feature of encrypting the data clientside before transmitting it under cover of TLS is not relevant to the argument. 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.
- three14 17y ago
  Agreed -- and this is an easier read than your top comment :)

by three14 17y ago

tptacek 17y ago

I have three issues with this post. (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.

briansmith 17y ago
TLS is not so easy to implement correctly. You still have to decide (a) which version of TLS to support, (b) which ciphersuites to support, (c) which signature algorithms to support, (d) which CA(s) to trust, and (e) which certificate revocation checking scheme(s) to use, at least. People tend to choose the defaults, which mostly works. But, Colin does make a valid point that the default list of CAs in particular is probably not the best choice considering the policies of the companies making these default lists. See http://chargen.matasano.com/chargen/2009/8/27/a-working-theory-about-rc4.html http://chargen.matasano.com/chargen/2009/8/27/a-working-theo... for another example of a common misconfiguration of TLS implementations.
- tptacek 17y ago
  The defaults on TLS work just fine. It's not 1999 anymore; your code isn't going to accept SSL2. No decision about ciphersuites, signature algorithms, or CAs (note: just run your own) are going to impact your security. 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.
  - briansmith 17y ago
    I disagree. The choice of ciphersuite is important. In particular, it is much better to choose DHE/ECDHE ciphersuites over the non-DHE/ECDHE ciphersuites to protect against the compromise of your server's private key. 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.
    - tptacek 17y ago
      The funny thing about that comment is that I've worked in several environmens where DHE was not only not preferred, but explicitly banned. Not only that, but DHE is even more complicated than SSL as most people understand it --- if you're in favor of it, you're making an even stronger argument for TLS (DH is remarkably easy to screw up). 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.
      - briansmith 17y ago
        The main thing I am trying to say is that, if you understand crypto enough to configure your TLS optimally, you can do the crypto without TLS. And, if you don't understand crypto and TLS this well, you shouldn't be trying to store the public's private data in a way that you claim to be secure. (This isn't about ZumoDrive; They may know quite a lot about these issues, and their choices might very well be optimal for the use cases they are trying to address.) 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.
janzer 17y ago
(1) Calling their security/cryptography "military grade" should be a warning signal. (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.
- tptacek 17y ago
  SSL/TLS is exactly the right tool for securing data in transit. That Zumodrive lacks the security feature of encrypting the data clientside before transmitting it under cover of TLS is not relevant to the argument. 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.
three14 17y ago
Agreed -- and this is an easier read than your top comment :)