Aging and Bloated OpenSSL Is Purged of 2 High-Severity Bugs (arstechnica.com)
An anonymous reader cites a story on Ars Technica: Maintainers of the OpenSSL cryptographic library have patched high-severity holes that could make it possible for attackers to decrypt login credentials or execute malicious code on Web servers. The updates were released Tuesday morning for both versions 1.0.1 and 1.0.2 of OpenSSL, which a large portion of the Internet relies on to cryptographically protect sensitive Web and e-mail traffic using the transport layer security protocol. OpenSSL advisories labeled the severity of both vulnerabilities "high," meaning the updates fixing them should be installed as soon as possible. The fixes bring the latest supported versions to 1.0.1t and 1.0.2h. The decryption vulnerability is the result of what cryptographers call a padding oracle weakness, which allows attackers to repeatedly probe an encrypted payload for clues about the plaintext content inside. According to TLS expert Filippo Valsorda, the bug allows for only 16 bytes of encrypted traffic to be recovered, and even then only when an end user sends it repeatedly.
That's a relief.
CVE-2016-2105
CVE-2016-2106
CVE-2016-2107
CVE-2016-2108
CVE-2016-2109
CVE-2016-2176
Why is OpenSSL still being used? LibreSSL is a better alternative that was forked from OpenSSL a couple of years ago. Why is OpenSSL still around?
Tell us how you really feel about OpenSSL.
These bits are old. Better replace them with new bits.
Open sores lead to infections no matter how "many eyes" are looking at it. Stop living in a fantasy world.
Aging and Bloated OpenSSL Is Purged of 2 High-Severity Bugs
The way that headline is phrased makes me want to call the Elder Abuse Hotline.
Well, at least they've chosen the right name. It's truly open...
It doesn't have to be like this. All we need to do is make sure we keep talking.
"We have released LibreSSL 2.3.4, which will be arriving in the
LibreSSL directory of your local OpenBSD mirror soon.
This release is based on the stable OpenBSD 5.9 branch.
* Fix multiple vulnerabilities in libcrypto relating to ASN.1 and encoding.
From OpenSSL."
"OpenSSL Gets Even More Secure As Bugs Continue To Be Found And Fixed"
Take your editorializing and arbitrary opinions and get the fuck on down the road, you little bitch
Where is the beautiful logo and the awe inspiring vulnerability name?
"the bug was introduced in the 2013 patch"
Yep. With Open Source, there's a lot of eyes on code and this kinda stuff doesn't happen like it does with proprietary code.
Can we get rid of this unmtained jumbled dinosaur with something more modern and actual ready for real e-commerce? Do we really need OpenVMS compability and it's own malloc() calls of LibreOSSL.
Unfortunately, we can't just expect all the system administrators and developers, and fortune 1000 companies to leave OpenSSL. Too much red tape and client contracts dictate OpenSSL and some software is coded to break if the string doesn't say "OpenSSL".
http://saveie6.com/
I don't want some backward compatable OpenSSL such as LibreSSL, I want something entirely new, something fresh and tight. The vast majority of the crypto supported by OpenSSL isn't even recommend. All kinds of crypto standards are now dead, MD5 to name just one.
...Because they needed one old bit from each of them.
Thus I want a new easy to use library that only covers the latest and has a clear path for moving forward.
Part of that path could be a method for abandoning various protocols/standards so that they leave the core library but are available for people to use who need backward compatibility. Simple versioning would be pretty good. UberSSL V2.x would not have everything from UberSSL V1.x and V1.x would have a end support date.
Ideally a single project could use both with the overlapping APIs defaulting to the latest version if the functionality existed in both. In a horribly maintained project they might simultaneously incorporate V1, V2, V3, V4,
A properly maintained project would update to the recommended crypto only found in the latest version. Effectively if it wasn't in the latest version it is probably bad security to be using it.
That said, I still recommend a backward ability like the above because some people are forced to open old files with old protocols, and contact old embedded devices with old standards that can't be upgraded.
Google says that OpenSSL currently has 437,962 lines of code, while LibreSSL is down to 316,745 as I see by wc -l $(find . -name '*.[ch]') which likely eliminates some bugs.
LibreSSL also removes the unsafe memory management that has been roundly criticised in OpenSSL.
LibreSSL also introduces many new features, and is generally more capable on the platforms where it runs.
Anyone who is seriously interested in FIPS is on the NSS TLS library anyway (from Netscape/Mozilla), as it has far more certifications. OpenSSL's FIPS was actually revoked for reasons of apparent negligence, which is understandable, since it was down to two staffers at one point.
>> Why are the majority of bug fixes flowing from OpenSSL to LibreSSL and not the other way around?
> Because there have hardly been any fixes in LibreSSL needed in the first place?
Because the original LibreSSL was not to add features. It was to discard unnecessary code from the forked version of OpenSSL. Shrinking a large project by 25%, as LibraSSL seems to have done successfully, can easily solve quite a few problems, especially the complex cross-platform components. But it doesn't automatically fix _any_ of the original problems in the shared codebase.
What kind of secure-coding standards do all of these security projects use? Do they even have any?
I know that it's impossible to write bug-free code, but out of all the open source projects I've seen, almost none of them seem to use any standard security-oriented boilerplate code, for reducing the dangers of e.g. memory management and other related things, in C/C++.
The quality of code for many open source projects - including ones that are widely relied upon for being secure - is often dire. Just look at Firefox.