8 ms·

One of the things I'm taking from this episode is just how worthless a lot of prognostication about security by a load of "experts" on the internet is, especial

One of the things I'm taking from this episode is just how worthless a lot of prognostication about security by a load of "experts" on the internet is, especially of the "trust us to get it right" variety. Frankly, their whining about how hard crypto is is partly responsible for the monoculture we have. Yes, it's difficult (more so in protocol than implementation), but they are so offputting to new people coming into the field it is insane. Clearly OpenSSL dev is broken, at least partly because everyone assumes everyone else is auditing all 300k lines of it, but also I can't help wondering if this calls for stronger component isolation within cryptosystems. For example, protocol implementation, encoding and decoding seem like they should all be totally isolated, so a disaster like this doesn't mean you could be leaking information from the rest of the system. I imagine many a HSM vendor has been quite pleased by this news.

dvanduzer 13y ago
There's a few different "just trust us" mentalities, but I've become more comfortable with the "don't roll your own if you missed the first 10 minutes of the lecture" worldview. Separating algorithm from implementation seems like it shouldn't be so difficult, but retrospect is a great teacher. So now we have approaches like NaCl, where the algorithms are designed to be hard to implement badly. And we have projects like LibTom, which aims to implement existing algorithms clearly. Both seem to be enjoying varying degrees of success.
- deleted 13y ago
  [deleted]
- tptacek 13y ago
  NaCl is designed to be user-proof. Part of its appeal is that it uses state-of-the-art primitives and constructions, but the reason it's so widely recommended, and the thesis behind its design, is that it's hard to misuse. The same isn't true of LibTomCrypt. Use NaCl. Be very, very careful with LibTomCrypt.
  - dvanduzer 13y ago
    Hmm. I was definitely oversimplifying, but if I need AES-256-GCM, how do I choose between OpenSSL and LibTom? (If you have particular insight into the strength of LibTom's GCM table acceleration implementation, I'm quite curious.) What multiplication factor on "very" careful do I need to be with OpenSSL? :) edit: Maybe I should've posted this link[0], because tables vs CLMUL is a little more complicated than that. [0] https://github.com/pyca/cryptography/issues/846 https://github.com/pyca/cryptography/issues/846
    - tptacek 13y ago
      IIRC, LibTom is table-driven, and OpenSSL will use CLMUL, so I'd have to give GCM to OpenSSL.
mikeash 13y ago
This is (I hope) a once-in-a-lifetime incident, so we have to be careful not to extrapolate it too hard. On the other hand, it's seriously big deal. Overall, it seems to strongly challenge a couple of important assumptions. As you say, it's a strong challenge to the mantra of "never implement your own crypto". I think (think) it still holds for the crypto primitives. If you're reimplementing AES you're probably doing it wrong. But the protocols? I'm not so sure now. Common wisdom seemed to be that if you implement the protocols yourself you'd screw them up, and you should stick with tried-and-true existing implementations. Now it's apparent that "tried" doesn't have to imply "true". Something being used by millions of people for years doesn't prevent it from having a huge vulnerability for years. Are your odds better or worse rolling your own? I'm not so sure now. Consider Apple's "goto fail" bug, for example. Among a lot of other stuff, they caught some criticism for reimplementing TLS instead of just using OpenSSL. Well, if they had used OpenSSL instead, it turns out that they would have been shipping an even more serious bug for even more time. It's also interesting to me how it challenges the idea of encrypting stuff by default. For years, people have been saying that as much traffic as possible should be encrypted, even unimportant stuff that nobody cares about. By doing that, the idea goes, using encryption isn't suspicious and you force attackers to spread out their resources. If only a small amount of traffic is encrypted, attackers can focus just on that traffic. Accordingly, a lot of sites that didn't really need it enabled SSL or even required it, including my own. By doing this, a lot of them inadvertently made things much much worse. A site that's only accessible over HTTP is much better off than a site that's accessible over HTTPS but vulnerable to heartbleed. I don't think the general idea is wrong, but it certainly gives me pause, and I think more consideration has to be given to the increase in attack surface you take on when you enable encryption. In any case, I really hope we see some new crypto projects come out of this, or more resources put into existing OpenSSL alternatives.
- ISL 13y ago
  > This is (I hope) a once-in-a-lifetime incident, so we have to be careful not to extrapolate it too hard. Don't bet on it.
  - mikeash 13y ago
skybrian 13y ago
The good news (sort of) is that it's an ordinary buffer overflow attack. We've known that these are a problem for decades and we've known how to check for them automatically for decades. Even in C's niche there are research prototypes for safe C-like languages. And yet there seems little effort to make them production-ready and deploy them; what kind of market failure is that? I think this is the final nail in the coffin for the ideas that "many eyes make all bugs shallow" or that code review alone by "experts" is enough to eliminate even the simplest of bugs. Use static analysis or go home. There are plenty of other ways to screw up with crypto but they don't pass out the server's private keys just like that.
- steveklabnik 13y ago
  > And yet there seems little effort to make them production-ready and deploy them; what kind of market failure is that? At least we have Rust...
  - ansible 13y ago
    At least we have Rust... Well, it's not really stable yet. But it is about the best candidate that I've heard of recently for this... Since I'm not familiar with it, is it possible to write a library in Rust, and have it callable from C? I've been doing a fair amount of golang programming recently, but calling Go from C is not possible right now (not sure if it will ever be).
    - kibwen 13y ago
      > is it possible to write a library in Rust, and have it > callable from C? Yes, you can generate a Rust library that exposes a C-compatible interface and then call that library from any language that can call C code.
    - steveklabnik 13y ago
      Yes, it's certainly not production ready. I just mean that there is one contender that is coming that addresses this. > is it possible to write a library in Rust, and have it callable from C? Yup. The third production deployment of Rust is actually a Ruby extension, written in C, that is a thin wrapper over Rust. Ruby -> C -> Rust. The reason it was done this way is that Ruby's C interface is incredibly macro heavy, so it was easier to use them in a tiny C layer than to try to port them to Rust itself. For more: https://air.mozilla.org/sprocketnes-practical-systems-programming-in-rust/ https://air.mozilla.org/sprocketnes-practical-systems-progra... (you'll have to scroll through to wycats' part.)
tptacek 13y ago
Surely, Nigel, if you'd just implemented your own encrypted transport, everything would have worked out great. Look how well that worked for Cryptocat. The most consistent complaint about OpenSSL is that it is developed amateurishly (I think it's more complicated than that, but "amateurish" is a fair summary of the critique). Your response seems to be, "double down on amateurish!" PS: The only reason you know about heartbleed is that one of the self-proclaimed "experts" found it for you. Neel Mehta is an insider's insider.
- fidotron 13y ago
  Anyone would say you stand to benefit from security remaining some sort of priesthood activity or something. Diversity of implementations is a good thing, for the simple reason the number of people an individual vulnerability could expose would be that much smaller.
  - tptacek 13y ago
    People have weird ideas of how we stand to benefit from things. Check out http://matasano.com/careers http://matasano.com/careers for a comprehensive rebuttal. Diversity of SSL implementations is a complicated proposition. When the Bleichenbacher e=3 attack happened, the monoculture helped: the most popular TLS clientsides weren't vulnerable, but the oddballs were. When research labs fuzz X.509, they find X.509 parsing bugs in the oddball libraries, not in OpenSSL. Be careful, because you're operating from a pretty serious availability bias. You vividly remember this recent vulnerability, because the researchers did a great job of publicizing it. But this isn't the worst vulnerability that's been found, even in TLS stacks, by far.
    - fidotron 13y ago
      You're missing the point completely, still. Computer security is like a genepool, and you can breed the strongest most brilliant thing you want in it, but when you cut down on diversity and then encounter some new virus that wipes everyone out, what happens? Diversity alone does not solve the situation, you need a diversity of competent products, but having one loudly supported implementation that isn't nearly as good as people are led to believe is epicly stupid. The fact so many people know that OpenSSL is a disaster area is even more damning for the security industry. Yes, Google are paying people to fix it at the edges, but it's clear from the likes of TdR that their whole process is broken, and yet in all the time it's been visibly broken to many of your insiders very little has been done to attempt to fix the structural problems, and a lot of effort has been made to shout loudly about how difficult fixing them would be, putting off anyone that might be trying to help. It's nonsense. This is time for a bit of humility from the security industry, not for strutting around proudly.

dvanduzer 13y ago

There's a few different "just trust us" mentalities, but I've become more comfortable with the "don't roll your own if you missed the first 10 minutes of the lecture" worldview. Separating algorithm from implementation seems like it shouldn't be so difficult, but retrospect is a great teacher. So now we have approaches like NaCl, where the algorithms are designed to be hard to implement badly. And we have projects like LibTom, which aims to implement existing algorithms clearly. Both seem to be enjoying varying degrees of success.

deleted 13y ago
[deleted]
tptacek 13y ago
NaCl is designed to be user-proof. Part of its appeal is that it uses state-of-the-art primitives and constructions, but the reason it's so widely recommended, and the thesis behind its design, is that it's hard to misuse. The same isn't true of LibTomCrypt. Use NaCl. Be very, very careful with LibTomCrypt.
- dvanduzer 13y ago
  Hmm. I was definitely oversimplifying, but if I need AES-256-GCM, how do I choose between OpenSSL and LibTom? (If you have particular insight into the strength of LibTom's GCM table acceleration implementation, I'm quite curious.) What multiplication factor on "very" careful do I need to be with OpenSSL? :) edit: Maybe I should've posted this link[0], because tables vs CLMUL is a little more complicated than that. [0] https://github.com/pyca/cryptography/issues/846 https://github.com/pyca/cryptography/issues/846
  - tptacek 13y ago
    IIRC, LibTom is table-driven, and OpenSSL will use CLMUL, so I'd have to give GCM to OpenSSL.

mikeash 13y ago

This is (I hope) a once-in-a-lifetime incident, so we have to be careful not to extrapolate it too hard. On the other hand, it's seriously big deal. Overall, it seems to strongly challenge a couple of important assumptions. As you say, it's a strong challenge to the mantra of "never implement your own crypto". I think (think) it still holds for the crypto primitives. If you're reimplementing AES you're probably doing it wrong. But the protocols? I'm not so sure now. Common wisdom seemed to be that if you implement the protocols yourself you'd screw them up, and you should stick with tried-and-true existing implementations. Now it's apparent that "tried" doesn't have to imply "true". Something being used by millions of people for years doesn't prevent it from having a huge vulnerability for years. Are your odds better or worse rolling your own? I'm not so sure now. Consider Apple's "goto fail" bug, for example. Among a lot of other stuff, they caught some criticism for reimplementing TLS instead of just using OpenSSL. Well, if they had used OpenSSL instead, it turns out that they would have been shipping an even more serious bug for even more time. It's also interesting to me how it challenges the idea of encrypting stuff by default. For years, people have been saying that as much traffic as possible should be encrypted, even unimportant stuff that nobody cares about. By doing that, the idea goes, using encryption isn't suspicious and you force attackers to spread out their resources. If only a small amount of traffic is encrypted, attackers can focus just on that traffic. Accordingly, a lot of sites that didn't really need it enabled SSL or even required it, including my own. By doing this, a lot of them inadvertently made things much much worse. A site that's only accessible over HTTP is much better off than a site that's accessible over HTTPS but vulnerable to heartbleed. I don't think the general idea is wrong, but it certainly gives me pause, and I think more consideration has to be given to the increase in attack surface you take on when you enable encryption. In any case, I really hope we see some new crypto projects come out of this, or more resources put into existing OpenSSL alternatives.

ISL 13y ago
> This is (I hope) a once-in-a-lifetime incident, so we have to be careful not to extrapolate it too hard. Don't bet on it.
- mikeash 13y ago

skybrian 13y ago

The good news (sort of) is that it's an ordinary buffer overflow attack. We've known that these are a problem for decades and we've known how to check for them automatically for decades. Even in C's niche there are research prototypes for safe C-like languages. And yet there seems little effort to make them production-ready and deploy them; what kind of market failure is that? I think this is the final nail in the coffin for the ideas that "many eyes make all bugs shallow" or that code review alone by "experts" is enough to eliminate even the simplest of bugs. Use static analysis or go home. There are plenty of other ways to screw up with crypto but they don't pass out the server's private keys just like that.

steveklabnik 13y ago
> And yet there seems little effort to make them production-ready and deploy them; what kind of market failure is that? At least we have Rust...
- ansible 13y ago
  At least we have Rust... Well, it's not really stable yet. But it is about the best candidate that I've heard of recently for this... Since I'm not familiar with it, is it possible to write a library in Rust, and have it callable from C? I've been doing a fair amount of golang programming recently, but calling Go from C is not possible right now (not sure if it will ever be).
  - kibwen 13y ago
    > is it possible to write a library in Rust, and have it > callable from C? Yes, you can generate a Rust library that exposes a C-compatible interface and then call that library from any language that can call C code.
  - steveklabnik 13y ago
    Yes, it's certainly not production ready. I just mean that there is one contender that is coming that addresses this. > is it possible to write a library in Rust, and have it callable from C? Yup. The third production deployment of Rust is actually a Ruby extension, written in C, that is a thin wrapper over Rust. Ruby -> C -> Rust. The reason it was done this way is that Ruby's C interface is incredibly macro heavy, so it was easier to use them in a tiny C layer than to try to port them to Rust itself. For more: https://air.mozilla.org/sprocketnes-practical-systems-programming-in-rust/ https://air.mozilla.org/sprocketnes-practical-systems-progra... (you'll have to scroll through to wycats' part.)

tptacek 13y ago

Surely, Nigel, if you'd just implemented your own encrypted transport, everything would have worked out great. Look how well that worked for Cryptocat. The most consistent complaint about OpenSSL is that it is developed amateurishly (I think it's more complicated than that, but "amateurish" is a fair summary of the critique). Your response seems to be, "double down on amateurish!" PS: The only reason you know about heartbleed is that one of the self-proclaimed "experts" found it for you. Neel Mehta is an insider's insider.

fidotron 13y ago
Anyone would say you stand to benefit from security remaining some sort of priesthood activity or something. Diversity of implementations is a good thing, for the simple reason the number of people an individual vulnerability could expose would be that much smaller.
- tptacek 13y ago
  People have weird ideas of how we stand to benefit from things. Check out http://matasano.com/careers http://matasano.com/careers for a comprehensive rebuttal. Diversity of SSL implementations is a complicated proposition. When the Bleichenbacher e=3 attack happened, the monoculture helped: the most popular TLS clientsides weren't vulnerable, but the oddballs were. When research labs fuzz X.509, they find X.509 parsing bugs in the oddball libraries, not in OpenSSL. Be careful, because you're operating from a pretty serious availability bias. You vividly remember this recent vulnerability, because the researchers did a great job of publicizing it. But this isn't the worst vulnerability that's been found, even in TLS stacks, by far.
  - fidotron 13y ago
    You're missing the point completely, still. Computer security is like a genepool, and you can breed the strongest most brilliant thing you want in it, but when you cut down on diversity and then encounter some new virus that wipes everyone out, what happens? Diversity alone does not solve the situation, you need a diversity of competent products, but having one loudly supported implementation that isn't nearly as good as people are led to believe is epicly stupid. The fact so many people know that OpenSSL is a disaster area is even more damning for the security industry. Yes, Google are paying people to fix it at the edges, but it's clear from the likes of TdR that their whole process is broken, and yet in all the time it's been visibly broken to many of your insiders very little has been done to attempt to fix the structural problems, and a lot of effort has been made to shout loudly about how difficult fixing them would be, putting off anyone that might be trying to help. It's nonsense. This is time for a bit of humility from the security industry, not for strutting around proudly.