Qualys Security Advisory – LibreSSL
seclists.org
Qualys Security Advisory – LibreSSL
1–10 of 89 posts
Re: Qualys Security Advisory – LibreSSL
#2> 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.
Re: Qualys Security Advisory – LibreSSL
#3> 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.
is keeping score what we're interested in today?
Re: Qualys Security Advisory – LibreSSL
#4[deleted]
Re: Qualys Security Advisory – LibreSSL
#5So 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.
Re: Qualys Security Advisory – LibreSSL
#6> 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.
is keeping score what we're interested in today? https://www.openssl.org/news/vulnerabilities.html
"Secure connection failed"
Re: Qualys Security Advisory – LibreSSL
#7So 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.
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.
Re: Qualys Security Advisory – LibreSSL
#8Why isn't static analysis or "sanitizers" finding this?
Re: Qualys Security Advisory – LibreSSL
#9> 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_ob...
> Releases: 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).
Re: Qualys Security Advisory – LibreSSL
#10So 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.
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…
> 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.