4 ms·

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

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.
      - tptacek 17y ago
        This is so absolutely, completely untrue I hardly know where to start. 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.
        briansmith 17y ago
        If you choose a bad implementation of your crypto primitives (ones that don't make these kinds of checks) then you will get bad results. That's not surprising. The same thing happens when you choose a bad TLS implementation. Your argument is that you should use a well-known TLS stack because the bugs have been shaken out over the years. I agree with that. But, the same thing applies to the lower-level crypto protocol implementations. The common TLS implementations are implemented with the common crypto primitive implementations. For example, IIRC the checks of D-H parameters in OpenSSL are in the D-H code, not in the TLS code. So, you don't need to use the TLS part of OpenSSL to get the benefits of its carefully-written D-H implementation. I'm not saying that anybody should go out and implement all the primitives (D-H, ECC, AES, GCM) themselves.
- briansmith 17y ago
  I forgot to respond to this in my other reply. Your post regarding RC4 was the first one that popped into my mind when I was trying to find a post regarding sub-optimal TLS settings commonly in use. 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.

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.
    - tptacek 17y ago
      This is so absolutely, completely untrue I hardly know where to start. 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.
      - briansmith 17y ago
        If you choose a bad implementation of your crypto primitives (ones that don't make these kinds of checks) then you will get bad results. That's not surprising. The same thing happens when you choose a bad TLS implementation. Your argument is that you should use a well-known TLS stack because the bugs have been shaken out over the years. I agree with that. But, the same thing applies to the lower-level crypto protocol implementations. The common TLS implementations are implemented with the common crypto primitive implementations. For example, IIRC the checks of D-H parameters in OpenSSL are in the D-H code, not in the TLS code. So, you don't need to use the TLS part of OpenSSL to get the benefits of its carefully-written D-H implementation. I'm not saying that anybody should go out and implement all the primitives (D-H, ECC, AES, GCM) themselves.
briansmith 17y ago
I forgot to respond to this in my other reply. Your post regarding RC4 was the first one that popped into my mind when I was trying to find a post regarding sub-optimal TLS settings commonly in use. 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.