5 ms·

what is safer: Running backdoor'ed RSA bsafe (http://www.theverge.com/2013/12/20/5231006/nsa-paid-10-million-for-a-back-door-into-rsa-encryption-according-to ht

what is safer: Running backdoor'ed RSA bsafe (http://www.theverge.com/2013/12/20/5231006/nsa-paid-10-million-for-a-back-door-into-rsa-encryption-according-to http://www.theverge.com/2013/12/20/5231006/nsa-paid-10-milli...) or OpenSSL? Serious question.

tptacek 11y ago
This is a weird question, since there's almost nothing that uses RSA's library as their TLS library. Every mainstream OS BSAFE is available for already provides a TLS library. This is a little like asking whether it's safer to use PHP or DTLS.
- eyeareque 11y ago
  Many banks weren't vulnerable to heartbleed (they use BSAFE I've heard).
  - tptacek 11y ago
    No.
    - eyeareque 11y ago
      Really? What library did they use? Ref: http://www.gospelherald.com/articles/50890/20140414/heart-bleed-bug-update-chase-boa-citigroup-irs-affected-security-flaw.htm http://www.gospelherald.com/articles/50890/20140414/heart-bl...
      - tptacek 11y ago
        Gospel Herald I don't even.
        eyeareque 11y ago
        It was posted on many sites, that was the first hit from a search query. I know. http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/ http://mashable.com/2014/04/09/heartbleed-bug-websites-affec... scroll to the banks section, you can see that many of them weren't affected. I've looked around online to see what they use, but it doesn't seem to be posted anywhere. My first question was serious--If there is a secure and reliable commercial ssl library out there, I know people would pay for it. No one wants to deal with these reoccurring OpenSSL issues while they work to clean up their code.
        nickpsecurity 11y ago
        If they're really any good, I'll at least say that hardly anyone will pay for a secure alternative. It's hard to sell more secure anything to businesses. Much less a protocol library that they have to integrate into everything. Especially at the prices they're sold at by the companies that might be competent enough to make a good library. They want to get back their engineering investment while users want the product for next to nothing. There's also the problem of integrating it into GPL software. Many companies are using such software. Companies specializing in software I.P. don't want their stuff released as GPL because it was used in a GPL app. There's ways to skirt around this but they add complexity. Stuff like this is why I recommend BSD-style licenses so that good, proprietary stuff can be integrated with it.
        eyeareque 11y ago
        I agree most small time companies would not spend an extra price for a library. Even though doing so would make sense based on the financial risk you take by utilizing a free option. With that said, major vendors who sell very expensive gear that use open source libraries like OpenSSL could afford to pay a license fee per device, and then pass that price on to their enterprise customers. An enterprise customer would gladly pay an extra 500-1000 dollars for a stable SSL/TLS library if it meant they wouldn't have to upgrade their devices every ~8 weeks due to OpenSSL bugs. Its cheaper to pay for a more stable/secure library (if one exists) than to upgrade mission critical devices so often (or worse, get hacked). One thing you can say is that a bank has a lot to lose--they'll invest in whatever it takes to secure their networks and devices.
      - nickpsecurity 11y ago
        PolarSSL said it wasn't affected by Heartbleed. There's quite a few non-OpenSSL libraries out there to use which might or might not be affected by any given bug in OpenSSL. I just remember PolarSSL because I stumbled on that claim while reading on users of Frama-C tool for finding bugs. They use it apparently. The LibreSSL people showed one commit at a time that OpenSSL was just poor coding through and through. I'd expect any implementation that paid more attention to code quality to do better. That's just one part of getting a crypto library done right, though. http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.html http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.htm...
        tptacek 11y ago
        The non-OpenSSL-derived non-OS SSL libraries (ie, not BoringSSL and LibreSSL) can be cryptographically dangerous. Avoid them.
        nickpsecurity 11y ago
        You say those OpenSSL alternatives can be dangerous. Yet, you also never recommend against OpenSSL despite it proving itself to be quite dangerous in more ways than just cryptographic. Strange double standard. Anyway, Fox IT [1] recently used PolarSSL in their OpenVPN respin. It's been immune to a number of issues that hit OpenSSL while their mailing list indicates steady work at finding and fixing its own problems. Improved the cryptographic defaults, too. The effort is open source. If you see non-OpenSSL crypto problems, feel free to publish them and suggest improvements so people in or outside those projects can make the systems better. So far, you mainly just blanket recommend against while pushing dangerous stuff (OpenSSL) on readers. Note: At least you endorsed two alternatives to OpenSSL in this one. A first. [1] https://openvpn.fox-it.com/background.html https://openvpn.fox-it.com/background.html
        tptacek 11y ago
        That's correct. I do not recommend against BoringSSL and LibreSSL, and I do recommend against PolarSSL. PolarSSL is, obviously, immune to the specific coding errors in OpenSSL. What you seem to have trouble acknowledging is the converse issue.

tptacek 11y ago

This is a weird question, since there's almost nothing that uses RSA's library as their TLS library. Every mainstream OS BSAFE is available for already provides a TLS library. This is a little like asking whether it's safer to use PHP or DTLS.

eyeareque 11y ago
Many banks weren't vulnerable to heartbleed (they use BSAFE I've heard).
- tptacek 11y ago
  No.
  - eyeareque 11y ago
    Really? What library did they use? Ref: http://www.gospelherald.com/articles/50890/20140414/heart-bleed-bug-update-chase-boa-citigroup-irs-affected-security-flaw.htm http://www.gospelherald.com/articles/50890/20140414/heart-bl...
    - tptacek 11y ago
      Gospel Herald I don't even.
      - eyeareque 11y ago
        It was posted on many sites, that was the first hit from a search query. I know. http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/ http://mashable.com/2014/04/09/heartbleed-bug-websites-affec... scroll to the banks section, you can see that many of them weren't affected. I've looked around online to see what they use, but it doesn't seem to be posted anywhere. My first question was serious--If there is a secure and reliable commercial ssl library out there, I know people would pay for it. No one wants to deal with these reoccurring OpenSSL issues while they work to clean up their code.
        nickpsecurity 11y ago
        If they're really any good, I'll at least say that hardly anyone will pay for a secure alternative. It's hard to sell more secure anything to businesses. Much less a protocol library that they have to integrate into everything. Especially at the prices they're sold at by the companies that might be competent enough to make a good library. They want to get back their engineering investment while users want the product for next to nothing. There's also the problem of integrating it into GPL software. Many companies are using such software. Companies specializing in software I.P. don't want their stuff released as GPL because it was used in a GPL app. There's ways to skirt around this but they add complexity. Stuff like this is why I recommend BSD-style licenses so that good, proprietary stuff can be integrated with it.
        eyeareque 11y ago
        I agree most small time companies would not spend an extra price for a library. Even though doing so would make sense based on the financial risk you take by utilizing a free option. With that said, major vendors who sell very expensive gear that use open source libraries like OpenSSL could afford to pay a license fee per device, and then pass that price on to their enterprise customers. An enterprise customer would gladly pay an extra 500-1000 dollars for a stable SSL/TLS library if it meant they wouldn't have to upgrade their devices every ~8 weeks due to OpenSSL bugs. Its cheaper to pay for a more stable/secure library (if one exists) than to upgrade mission critical devices so often (or worse, get hacked). One thing you can say is that a bank has a lot to lose--they'll invest in whatever it takes to secure their networks and devices.
    - nickpsecurity 11y ago
      PolarSSL said it wasn't affected by Heartbleed. There's quite a few non-OpenSSL libraries out there to use which might or might not be affected by any given bug in OpenSSL. I just remember PolarSSL because I stumbled on that claim while reading on users of Frama-C tool for finding bugs. They use it apparently. The LibreSSL people showed one commit at a time that OpenSSL was just poor coding through and through. I'd expect any implementation that paid more attention to code quality to do better. That's just one part of getting a crypto library done right, though. http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.html http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.htm...
      - tptacek 11y ago
        The non-OpenSSL-derived non-OS SSL libraries (ie, not BoringSSL and LibreSSL) can be cryptographically dangerous. Avoid them.
        nickpsecurity 11y ago
        You say those OpenSSL alternatives can be dangerous. Yet, you also never recommend against OpenSSL despite it proving itself to be quite dangerous in more ways than just cryptographic. Strange double standard. Anyway, Fox IT [1] recently used PolarSSL in their OpenVPN respin. It's been immune to a number of issues that hit OpenSSL while their mailing list indicates steady work at finding and fixing its own problems. Improved the cryptographic defaults, too. The effort is open source. If you see non-OpenSSL crypto problems, feel free to publish them and suggest improvements so people in or outside those projects can make the systems better. So far, you mainly just blanket recommend against while pushing dangerous stuff (OpenSSL) on readers. Note: At least you endorsed two alternatives to OpenSSL in this one. A first. [1] https://openvpn.fox-it.com/background.html https://openvpn.fox-it.com/background.html
        tptacek 11y ago
        That's correct. I do not recommend against BoringSSL and LibreSSL, and I do recommend against PolarSSL. PolarSSL is, obviously, immune to the specific coding errors in OpenSSL. What you seem to have trouble acknowledging is the converse issue.