11–20 of 89 posts
> 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
https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...
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.
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…
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.
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…
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.
I'm patient. You gotta pay the piper. Yer in deep shit, retard.
Earlier quoted context omitted.
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…
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.
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.
Stop writing unmanaged code? This is just the same ol' story...
While Rust can export functions the same way C does it you are in unmanaged land again then.
With http://www.ponylang.org/ its much better, it can export functions like C does it, but its fully managed. The only limitation are the Data Types, you are restricted to those C knows.
> 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
Why isn't static analysis or "sanitizers" finding this?
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.
Earlier quoted context omitted.
> 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…
> 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…