12 ms·

Qualys Security Advisory – LibreSSL

115 points by dfc 11y ago

kevan 11y ago
> These vulnerabilities affect all LibreSSL versions, including LibreSSL 2.0.0 (the first public release) and LibreSSL 2.3.0 (the latest release at the time of writing). OpenSSL is not affected.
- orik 11y ago
  is keeping score what we're interested in today? https://www.openssl.org/news/vulnerabilities.html https://www.openssl.org/news/vulnerabilities.html
  - jldugger 11y ago
    "Secure connection failed"
  - conradev 11y ago
    If you're looking for a chart, Wikipedia is keeping score: https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...
  - xenophonf 11y ago
    Whether this bug affects the upstream project is a legitimate concern, I think. It would be like worrying that a vulnerability in OpenBSD affected NetBSD, too, especially if it was found relatively close to when OpenBSD forked.
- Johnny_Brahms 11y ago
  I blame C. People that are much smarter than me fail at writing C. I am not even trolling. It is a thought that has been gnawing away at me for some time. I no longer think it's a question of being "good enough" to write good C code. The only one I know of that has written almost bug-free C code is djb, and that code is a fucking pain to look at regardless of what Aaron Schwartz said. It is good, but it is not how anyone in their right mind writes C. If that is what is required to write safe C then I'm all for using another language. Edit: I do like how Zed Shaw writes C, but I have no idea if the software he wrote is safe...
  - smt88 11y ago
    I've always assumed LibreSSL was just a first step toward a secure implementation. I always thought that it made sense to try to fork/fix OpenSSL at first, but eventually move to a non-C implementation. I still think that will happen.
    - masklinn 11y ago
      > I've always assumed LibreSSL was just a first step toward a secure implementation. I always thought that it made sense to try to fork/fix OpenSSL at first, but eventually move to a non-C implementation. Yes and no. No in that LibreSSL aims to be mostly drop-in compatible with OpenSSL (modulo deprecations/removals) and OpenSSL has a very complex API exposing lots of internal gunk to the user, so moving to a non-C implementation may not be possible at all. Yes because there's a related `libtls`[0] project which aims to define more abstracted API (with the reference implementation being done on top of libressl). As POC, tedu has/had an implementation of the API using golang's TLS stack[1], and noted that you could build the same on e.g. the OCaml/Mirage TLS stack[2]. If `libtls` fulfils its promises, it would become much easier to swap TLS stack and indeed move to non-C implementations. [0] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/tls_accept_fds.3?query=tls%5finit&sec=3 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/... HN discussion: https://news.ycombinator.com/item?id=8572029 https://news.ycombinator.com/item?id=8572029 (some comments may not apply anymore IIRC the discussion was the initial API which has been extended since) [1] http://www.tedunangst.com/flak/post/goreSSL http://www.tedunangst.com/flak/post/goreSSL [2] https://mirage.io/blog/introducing-ocaml-tls https://mirage.io/blog/introducing-ocaml-tls
  - 0x01 11y ago
    If we accept that C is here to stay for the time being, but is difficult to manage memory, then why don't we use a mid-way solution? Lua is built on c, and is much more (than C) memory safe. It retains all the advantages of C (ie, can go anywhere), and we limit the C to 17.3k (as of 5.2.3) lines of c, which is relatively static (won't change, won't bloat in the same way maintaining/building on current C SSL implementations), and could allow us to handle memory safely. I'm curious why this approach is not used. Portability? Proficiency? Lua is quite possibly the most beautiful language to read. I can't see any downsides, but I'll gladly be enlightened!
- peterwwillis 11y ago
  laughs maniacally
deleted 11y ago
[deleted]
Confusion 11y ago
So you'd think that if anything, these kinds of 'trivial' bugs, memory leaks and buffer overflows, would not be present in LibreSSL. Especially not in the same function. I wonder what went wrong and how it can be prevented.
- byuu 11y ago
  I know this opinion won't be popular, and I know encryption is a very complex topic, but ... TLS is simply vastly too complicated. How many of us here could write a TLS library even if we wanted to? So you end up with code so complex that even the smartest people can barely understand it, let alone debug it, and you get terrifyingly long CVE lists like for OpenSSL as a result. Compare that to a basic unencrypted HTTP server, which you can write in ~10KiB of code. Complexity breeds these kinds of problems as a natural consequence. I do know that verifiability is significantly easier than all of this (signatures; hashing), but it's quite possible there is no simpler solution for the secrecy aspect of TLS. I certainly wish there was more support for HTTP+integrity, for those who didn't need the secrecy component. These constant CVEs in every TLS library put our servers at risk in cases where secrecy simply isn't necessary.
  - quonn 11y ago
    > Complexity breeds these kinds of problems as a natural consequence. But the bugs described are not complex - they are local problems that can be understood by just reading one function. The problem here is not complexity, but size (not enough people spend enough time to review all of the code) and the fact that the library is written in a language with manual memory management and unsafe memory access. > I do know that verifiability is significantly easier than all of this (signatures; hashing), but it's quite possible there is no simpler solution for the secrecy aspect of TLS. In this case, the affected component was related to the identity part (certificates), which are needed for verifiability. It was not directly related to secrecy.
    - byuu 11y ago
      > the library is written in a language with manual memory management and unsafe memory access. C's simplicity is certainly a blessing and a curse. Right now, I'm of the opinion that C++ is the best we've got, even if not perfectly ideal. RAII, shared pointers and smart containers with bounds checking allows you to keep nearly all of the performance without the drastic downsides of tracing garbage collectors (obscene amounts of memory usage, nasty stalls, etc.) And when you get into the really high-level languages (Python, Ruby), they simply don't scale. Everyone's darling right now is Rust. I still think it's too early in its life to know how it'll play out (hot new languages follow a predictable path of gaining negative baggage and shortcomings as they increase in real-world usage), but I guess we'll see. Maybe it will indeed be a great panacea to these issues. > In this case, the affected component was related to the identity part (certificates), which are needed for verifiability. It was not directly related to secrecy. Sure, but I'm generalizing here. I can (and did) write a SHA256 hashing algorithm in 3KiB of code. Combined with a package gist updater (these use signing with local keys for updates), that's enough to secure binary package downloads on the BSDs over plain-text HTTP. Surely we can come up with a less complex system for verification alone. Something akin to signify, perhaps. I know that doesn't solve how to universally handle anonymously verifying public key authenticity, but surely we can make something less complex than the clusterfuck that is TLS and the CAs. Yet it doesn't seem there's much, if any, interest in even trying. Everyone has hitched their wagons to HTTP/2 and mandatory TLS; which to me feels like a huge step backward by means of making tech vastly more complex.
TwoBit 11y ago
Why isn't static analysis or "sanitizers" finding this?
- viraptor 11y ago
  Good question. I'd expect static analysis to find the leak automatically - it's pretty obvious. The off by one however is behind many branches and only detectable if you know the buffer size at the call site... I'd be surprised if it triggered any scanning tool. As a general answer though: static analysis will give you better answers if you write your code in a clean and well structured way. If you goto from a branch from a branch from a (potentially infinite) for-loop from a (not counting) while-loop - good luck :) OpenSSL's OBJ_/BN_/... functions seem to strive for complexity.
- fulafel 11y ago
  They have major limitations. C is unsafe even with all the mitigation tools in the world and in the end they're only going to catch the low-hanging fruit.
snksnk 11y ago
> We would like to thank the LibreSSL team for their great work and their incredibly quick response, and Red Hat Product Security for promptly assigning CVE-IDs to these issues. > Patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.8/common/007_obj2txt.patch.sig http://ftp.openbsd.org/pub/OpenBSD/patches/5.8/common/007_ob... > Releases: http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/ http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/ I am glad that bugs are found. It shows that the audit is thorough, since bugs can still be expected in LibreSSL (still quite new) and OpenSMTPD (audit was explicitly requested).
TerryADavis 11y ago
Delude yourself all day, CIA. You must face God. If I wait 12 years, I am CEO of intel for 12 years. If I wait 15 years, I am CEO of INtel for 15 years. I'm patient. You gotta pay the piper. Yer in deep shit, retard.
jmnicolas 11y ago
I have no knowledge of C, but reading their code I was surprised to see some gotos ... is this OK in C to use goto ?
- mborch 11y ago
  Yes.
- masklinn 11y ago
  It's a very common C error-handling pattern, essentially emulating RAII with forwards-only function-local goto statements. It's possible to do without, but that tends to yield much more deeply nested code (especially if it's complex) and possibly some amount of duplication. See http://eli.thegreenplace.net/2009/04/27/using-goto-for-error-handling-in-c http://eli.thegreenplace.net/2009/04/27/using-goto-for-error... for a short rundown, or http://blog.regehr.org/archives/894 http://blog.regehr.org/archives/894 where regehr — who works specifically in correctness and verifiability — states: > many people, including me, prefer the goto version
- deleted 11y ago
  [deleted]
- xorcist 11y ago
  Most languages use unconditional jumps to break flow when necessary, it might be called "exception" instead of "goto" but it's conceptually the same thing.
  - AUmrysh 11y ago
    In many high level languages a break, continue, pass, that sort of thing (where you want to skip or escape a loop iteration) is usually implemented with a goto as well. Also, a common use of goto in C is when you're doing something in nested for loops and want to break out of all of them. A goto is actually much cleaner here than using sentinel values or boolean flags, or naughty things like setting your loop variables to be outside of the conditional bounds.
    - 11y ago
therealmarv 11y ago
OS X 10.11 El Capitan is using LibreSSL: `ssh -V` How I patch this? ;) If anybody has infos when Apple is releasing a fix please tell me.
- netheril96 11y ago
  Install your own LibreSSL with Homebrew or wait for a fix from Apple. I think Apple never discloses information about security vulnerabilities until a fix is out.
- Asmod4n 11y ago
  afaik this only applies to x509, which openSSH doesn't use.
- therealmarv 11y ago
  seems OS X 10.11.1 did not fixed this. The version is 2.1.7 there but newest one is 2.1.8 :(
richardwhiuk 11y ago
So much for LibreSSL being a better choice than OpenSSL.
- glass- 11y ago
  LibreSSL has had roughly half (22 to 43) as many vulnerabilities as OpenSSL since the fork and, before this, 0 sev:high, compared to OpenSSL's 5 sev:high. Would you really disregard all that because of a 1-byte buffer overflow and a memory leak?
  - richardwhiuk 11y ago
    False: CVE-2015-0204 affected LibreSSL, but they thought it was a low priority vulnerability, when it actually is a high priority. They fixed it, didn't notify upstream afaict and just issued a new release. LibreSSL isn't a panacea, and based on that, they can't even classify vulnerabilities correctly. Most of the vulnerabilities in OpenSSL are in parts (e.g. DTLS) which are disabled in lots of builds.
IgorPartola 11y ago
Here we go. Another round of "damn it, it's written in C. that's the root of all evil". I think by this point a Markov chain can easily generate responses to the OpenSSL/LibreSSL vulnerability announcements so we don't have to. Yes, C sucks because buffer overflows are still possible. That's by design. At the same time, it goes something like this: 1. OpenSSL (or this time LibreSSL) has a vulnerability discovered. 2. Everyone gets in an uproar about how we need a clean implementation in a language that prevents stupid errors. 3. Someone suggests unit testing. tptacek tells them to go away. 4. Someone actually points out a Haskell project (https://news.ycombinator.com/item?id=7557089 https://news.ycombinator.com/item?id=7557089). 5. People poo poo any alternative to OpenSSL because it's not 100% feature complete and besides the best crypto people are already working on OpenSSL so what do these schmucks know? 6. Someone points out that in higher level languages it's hard to write code that is resistant against timing attacks. The discussion dies. I see only two alternatives. Either as a community we actually stop bike shedding and throw our weight behind a project that might actually become a good alternative to OpenSSL, or we accept that the canonical TLS library will be written in C and have bugs that are periodically discovered and quickly patched.
- dguido 11y ago
  Don't forget these functional alternatives to OpenSSL: 1. OCaml-TLS (https://github.com/mirleft/ocaml-tls https://github.com/mirleft/ocaml-tls) [1] 2. miTLS (http://www.mitls.org/wsgi/home http://www.mitls.org/wsgi/home) 3. s2n (https://github.com/awslabs/s2n https://github.com/awslabs/s2n) [1] Home of the epic Bitcoin Pinata! http://ownme.ipredator.se/ http://ownme.ipredator.se/
  - codygman 11y ago
    Don't forget: https://hackage.haskell.org/package/tls https://hackage.haskell.org/package/tls
- briansmith 11y ago
  > 5. People poo poo any alternative to OpenSSL because it's not 100% feature complete and besides the best crypto people are already working on OpenSSL so what do these schmucks know? Here's a strategy: Take OpenSSL, remove a bunch of stuff that almost nobody needs, rearrange the code to make it clearer. You will get BoringSSL. Take the BoringSSL code, remove more stuff that people outside of Google generally don't need. Temporarily remove the X.509 code and the TLS code so that you can remove even more stuff. Next, write bindings for the remaining code for a safe language like Rust, so that the replacement X.509 and TLS code can be written in the safer language, while still using the OpenSSL crypto code. Then, write the new X.509 code, focusing on what really is needed and ignoring all the extra cruft that was added to X.509 but which doesn't actually improve security. Then, over time, refactor the the language bindings so more code is written in the safe language and less code is written in C, with the goal of almost all the code that isn't implementing directly crypto algorithms being in the safe language. Then, add a good, clean TLS implementation in the safe language, that focuses on the good parts of TLS, and that avoids all the legacy cruft that makes TLS seem complicated. I've been doing an experiment along these lines. I've open sourced two parts so far: 1. https://github.com/briansmith/ring https://github.com/briansmith/ring 2. https://github.com/briansmith/webpki https://github.com/briansmith/webpki It is a big project, but I am pretty sure it is going to succeed.

115 points by dfc 11y ago

kevan 11y ago

> These vulnerabilities affect all LibreSSL versions, including LibreSSL 2.0.0 (the first public release) and LibreSSL 2.3.0 (the latest release at the time of writing). OpenSSL is not affected.

orik 11y ago
is keeping score what we're interested in today? https://www.openssl.org/news/vulnerabilities.html https://www.openssl.org/news/vulnerabilities.html
- jldugger 11y ago
  "Secure connection failed"
- conradev 11y ago
  If you're looking for a chart, Wikipedia is keeping score: https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...
- xenophonf 11y ago
  Whether this bug affects the upstream project is a legitimate concern, I think. It would be like worrying that a vulnerability in OpenBSD affected NetBSD, too, especially if it was found relatively close to when OpenBSD forked.
Johnny_Brahms 11y ago
I blame C. People that are much smarter than me fail at writing C. I am not even trolling. It is a thought that has been gnawing away at me for some time. I no longer think it's a question of being "good enough" to write good C code. The only one I know of that has written almost bug-free C code is djb, and that code is a fucking pain to look at regardless of what Aaron Schwartz said. It is good, but it is not how anyone in their right mind writes C. If that is what is required to write safe C then I'm all for using another language. Edit: I do like how Zed Shaw writes C, but I have no idea if the software he wrote is safe...
- smt88 11y ago
  I've always assumed LibreSSL was just a first step toward a secure implementation. I always thought that it made sense to try to fork/fix OpenSSL at first, but eventually move to a non-C implementation. I still think that will happen.
  - masklinn 11y ago
    > I've always assumed LibreSSL was just a first step toward a secure implementation. I always thought that it made sense to try to fork/fix OpenSSL at first, but eventually move to a non-C implementation. Yes and no. No in that LibreSSL aims to be mostly drop-in compatible with OpenSSL (modulo deprecations/removals) and OpenSSL has a very complex API exposing lots of internal gunk to the user, so moving to a non-C implementation may not be possible at all. Yes because there's a related `libtls`[0] project which aims to define more abstracted API (with the reference implementation being done on top of libressl). As POC, tedu has/had an implementation of the API using golang's TLS stack[1], and noted that you could build the same on e.g. the OCaml/Mirage TLS stack[2]. If `libtls` fulfils its promises, it would become much easier to swap TLS stack and indeed move to non-C implementations. [0] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/tls_accept_fds.3?query=tls%5finit&sec=3 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/... HN discussion: https://news.ycombinator.com/item?id=8572029 https://news.ycombinator.com/item?id=8572029 (some comments may not apply anymore IIRC the discussion was the initial API which has been extended since) [1] http://www.tedunangst.com/flak/post/goreSSL http://www.tedunangst.com/flak/post/goreSSL [2] https://mirage.io/blog/introducing-ocaml-tls https://mirage.io/blog/introducing-ocaml-tls
- 0x01 11y ago
  If we accept that C is here to stay for the time being, but is difficult to manage memory, then why don't we use a mid-way solution? Lua is built on c, and is much more (than C) memory safe. It retains all the advantages of C (ie, can go anywhere), and we limit the C to 17.3k (as of 5.2.3) lines of c, which is relatively static (won't change, won't bloat in the same way maintaining/building on current C SSL implementations), and could allow us to handle memory safely. I'm curious why this approach is not used. Portability? Proficiency? Lua is quite possibly the most beautiful language to read. I can't see any downsides, but I'll gladly be enlightened!
peterwwillis 11y ago
laughs maniacally

deleted 11y ago

[deleted]

Confusion 11y ago

So you'd think that if anything, these kinds of 'trivial' bugs, memory leaks and buffer overflows, would not be present in LibreSSL. Especially not in the same function. I wonder what went wrong and how it can be prevented.

byuu 11y ago
I know this opinion won't be popular, and I know encryption is a very complex topic, but ... TLS is simply vastly too complicated. How many of us here could write a TLS library even if we wanted to? So you end up with code so complex that even the smartest people can barely understand it, let alone debug it, and you get terrifyingly long CVE lists like for OpenSSL as a result. Compare that to a basic unencrypted HTTP server, which you can write in ~10KiB of code. Complexity breeds these kinds of problems as a natural consequence. I do know that verifiability is significantly easier than all of this (signatures; hashing), but it's quite possible there is no simpler solution for the secrecy aspect of TLS. I certainly wish there was more support for HTTP+integrity, for those who didn't need the secrecy component. These constant CVEs in every TLS library put our servers at risk in cases where secrecy simply isn't necessary.
- quonn 11y ago
  > Complexity breeds these kinds of problems as a natural consequence. But the bugs described are not complex - they are local problems that can be understood by just reading one function. The problem here is not complexity, but size (not enough people spend enough time to review all of the code) and the fact that the library is written in a language with manual memory management and unsafe memory access. > I do know that verifiability is significantly easier than all of this (signatures; hashing), but it's quite possible there is no simpler solution for the secrecy aspect of TLS. In this case, the affected component was related to the identity part (certificates), which are needed for verifiability. It was not directly related to secrecy.
  - byuu 11y ago
    > the library is written in a language with manual memory management and unsafe memory access. C's simplicity is certainly a blessing and a curse. Right now, I'm of the opinion that C++ is the best we've got, even if not perfectly ideal. RAII, shared pointers and smart containers with bounds checking allows you to keep nearly all of the performance without the drastic downsides of tracing garbage collectors (obscene amounts of memory usage, nasty stalls, etc.) And when you get into the really high-level languages (Python, Ruby), they simply don't scale. Everyone's darling right now is Rust. I still think it's too early in its life to know how it'll play out (hot new languages follow a predictable path of gaining negative baggage and shortcomings as they increase in real-world usage), but I guess we'll see. Maybe it will indeed be a great panacea to these issues. > In this case, the affected component was related to the identity part (certificates), which are needed for verifiability. It was not directly related to secrecy. Sure, but I'm generalizing here. I can (and did) write a SHA256 hashing algorithm in 3KiB of code. Combined with a package gist updater (these use signing with local keys for updates), that's enough to secure binary package downloads on the BSDs over plain-text HTTP. Surely we can come up with a less complex system for verification alone. Something akin to signify, perhaps. I know that doesn't solve how to universally handle anonymously verifying public key authenticity, but surely we can make something less complex than the clusterfuck that is TLS and the CAs. Yet it doesn't seem there's much, if any, interest in even trying. Everyone has hitched their wagons to HTTP/2 and mandatory TLS; which to me feels like a huge step backward by means of making tech vastly more complex.

TwoBit 11y ago

Why isn't static analysis or "sanitizers" finding this?

viraptor 11y ago
Good question. I'd expect static analysis to find the leak automatically - it's pretty obvious. The off by one however is behind many branches and only detectable if you know the buffer size at the call site... I'd be surprised if it triggered any scanning tool. As a general answer though: static analysis will give you better answers if you write your code in a clean and well structured way. If you goto from a branch from a branch from a (potentially infinite) for-loop from a (not counting) while-loop - good luck :) OpenSSL's OBJ_/BN_/... functions seem to strive for complexity.
fulafel 11y ago
They have major limitations. C is unsafe even with all the mitigation tools in the world and in the end they're only going to catch the low-hanging fruit.

snksnk 11y ago

> We would like to thank the LibreSSL team for their great work and their incredibly quick response, and Red Hat Product Security for promptly assigning CVE-IDs to these issues. > Patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.8/common/007_obj2txt.patch.sig http://ftp.openbsd.org/pub/OpenBSD/patches/5.8/common/007_ob... > Releases: http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/ http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/ I am glad that bugs are found. It shows that the audit is thorough, since bugs can still be expected in LibreSSL (still quite new) and OpenSMTPD (audit was explicitly requested).

TerryADavis 11y ago

Delude yourself all day, CIA. You must face God. If I wait 12 years, I am CEO of intel for 12 years. If I wait 15 years, I am CEO of INtel for 15 years. I'm patient. You gotta pay the piper. Yer in deep shit, retard.

jmnicolas 11y ago

I have no knowledge of C, but reading their code I was surprised to see some gotos ... is this OK in C to use goto ?

mborch 11y ago
Yes.
masklinn 11y ago
It's a very common C error-handling pattern, essentially emulating RAII with forwards-only function-local goto statements. It's possible to do without, but that tends to yield much more deeply nested code (especially if it's complex) and possibly some amount of duplication. See http://eli.thegreenplace.net/2009/04/27/using-goto-for-error-handling-in-c http://eli.thegreenplace.net/2009/04/27/using-goto-for-error... for a short rundown, or http://blog.regehr.org/archives/894 http://blog.regehr.org/archives/894 where regehr — who works specifically in correctness and verifiability — states: > many people, including me, prefer the goto version
deleted 11y ago
[deleted]
xorcist 11y ago
Most languages use unconditional jumps to break flow when necessary, it might be called "exception" instead of "goto" but it's conceptually the same thing.
- AUmrysh 11y ago
  In many high level languages a break, continue, pass, that sort of thing (where you want to skip or escape a loop iteration) is usually implemented with a goto as well. Also, a common use of goto in C is when you're doing something in nested for loops and want to break out of all of them. A goto is actually much cleaner here than using sentinel values or boolean flags, or naughty things like setting your loop variables to be outside of the conditional bounds.
  - 11y ago

therealmarv 11y ago

OS X 10.11 El Capitan is using LibreSSL: `ssh -V` How I patch this? ;) If anybody has infos when Apple is releasing a fix please tell me.

netheril96 11y ago
Install your own LibreSSL with Homebrew or wait for a fix from Apple. I think Apple never discloses information about security vulnerabilities until a fix is out.
Asmod4n 11y ago
afaik this only applies to x509, which openSSH doesn't use.
therealmarv 11y ago
seems OS X 10.11.1 did not fixed this. The version is 2.1.7 there but newest one is 2.1.8 :(

richardwhiuk 11y ago

So much for LibreSSL being a better choice than OpenSSL.

glass- 11y ago
LibreSSL has had roughly half (22 to 43) as many vulnerabilities as OpenSSL since the fork and, before this, 0 sev:high, compared to OpenSSL's 5 sev:high. Would you really disregard all that because of a 1-byte buffer overflow and a memory leak?
- richardwhiuk 11y ago
  False: CVE-2015-0204 affected LibreSSL, but they thought it was a low priority vulnerability, when it actually is a high priority. They fixed it, didn't notify upstream afaict and just issued a new release. LibreSSL isn't a panacea, and based on that, they can't even classify vulnerabilities correctly. Most of the vulnerabilities in OpenSSL are in parts (e.g. DTLS) which are disabled in lots of builds.

IgorPartola 11y ago

Here we go. Another round of "damn it, it's written in C. that's the root of all evil". I think by this point a Markov chain can easily generate responses to the OpenSSL/LibreSSL vulnerability announcements so we don't have to. Yes, C sucks because buffer overflows are still possible. That's by design. At the same time, it goes something like this: 1. OpenSSL (or this time LibreSSL) has a vulnerability discovered. 2. Everyone gets in an uproar about how we need a clean implementation in a language that prevents stupid errors. 3. Someone suggests unit testing. tptacek tells them to go away. 4. Someone actually points out a Haskell project (https://news.ycombinator.com/item?id=7557089 https://news.ycombinator.com/item?id=7557089). 5. People poo poo any alternative to OpenSSL because it's not 100% feature complete and besides the best crypto people are already working on OpenSSL so what do these schmucks know? 6. Someone points out that in higher level languages it's hard to write code that is resistant against timing attacks. The discussion dies. I see only two alternatives. Either as a community we actually stop bike shedding and throw our weight behind a project that might actually become a good alternative to OpenSSL, or we accept that the canonical TLS library will be written in C and have bugs that are periodically discovered and quickly patched.

dguido 11y ago
Don't forget these functional alternatives to OpenSSL: 1. OCaml-TLS (https://github.com/mirleft/ocaml-tls https://github.com/mirleft/ocaml-tls) [1] 2. miTLS (http://www.mitls.org/wsgi/home http://www.mitls.org/wsgi/home) 3. s2n (https://github.com/awslabs/s2n https://github.com/awslabs/s2n) [1] Home of the epic Bitcoin Pinata! http://ownme.ipredator.se/ http://ownme.ipredator.se/
- codygman 11y ago
  Don't forget: https://hackage.haskell.org/package/tls https://hackage.haskell.org/package/tls
briansmith 11y ago
> 5. People poo poo any alternative to OpenSSL because it's not 100% feature complete and besides the best crypto people are already working on OpenSSL so what do these schmucks know? Here's a strategy: Take OpenSSL, remove a bunch of stuff that almost nobody needs, rearrange the code to make it clearer. You will get BoringSSL. Take the BoringSSL code, remove more stuff that people outside of Google generally don't need. Temporarily remove the X.509 code and the TLS code so that you can remove even more stuff. Next, write bindings for the remaining code for a safe language like Rust, so that the replacement X.509 and TLS code can be written in the safer language, while still using the OpenSSL crypto code. Then, write the new X.509 code, focusing on what really is needed and ignoring all the extra cruft that was added to X.509 but which doesn't actually improve security. Then, over time, refactor the the language bindings so more code is written in the safe language and less code is written in C, with the goal of almost all the code that isn't implementing directly crypto algorithms being in the safe language. Then, add a good, clean TLS implementation in the safe language, that focuses on the good parts of TLS, and that avoids all the legacy cruft that makes TLS seem complicated. I've been doing an experiment along these lines. I've open sourced two parts so far: 1. https://github.com/briansmith/ring https://github.com/briansmith/ring 2. https://github.com/briansmith/webpki https://github.com/briansmith/webpki It is a big project, but I am pretty sure it is going to succeed.