3 ms·
> an SSL stack written in such a language is infinitely less likely to suffer from some of the worst kinds of bugs in recent memory (Heartbleed comes to mind)
by 2trill2spill 11y ago
> an SSL stack written in such a language is infinitely less likely to suffer from some of the worst kinds of bugs in recent memory (Heartbleed comes to mind)
While you are right about OCaml being safer than C, Heartbleed was a pretty lame bug, it doesn't even give an attacker remote code execution. Something like CVE-2014-0195 is far more dangerous than Heartbleed but it didn't have a marketing name and large amounts of press coverage.
- wolf550e 11y agoA bug in DTLS will not get attention because people don't run DTLS.
- 2trill2spill 11y agoYea probably a poor choice of a OpenSSL vulnerability, I was assuming this was on by default even when using TLS like lot's of other OpenSSL features but then I found this line, "Only applications using OpenSSL as a DTLS client are affected."[1] CVE-2012-2110 is probably a better choice. [1]: https://www.openssl.org/news/secadv/20140605.txt https://www.openssl.org/news/secadv/20140605.txt
- dsp1234 11y agoCVE-2012-2110 is probably a better choice. From the openssl advisory[0], "In particular the SSL/TLS code of OpenSSL is not affected.". [0] - https://www.openssl.org/news/secadv/20120419.txt https://www.openssl.org/news/secadv/20120419.txt
- cyphar 11y ago> While you are right about OCaml being safer than C, Heartbleed was a pretty lame bug, it doesn't even give an attacker remote code execution. But it did give the attacker your server's private keys. And client private data.