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.
Tell us how you really feel about OpenSSL.
I use OpenSSL in an EBCDIC environment, you insensitive clod!
If I have been able to see further than others, it is because I bought a pair of binoculars.
*BZZZZZZT* Wrong. OpenSSL isn't open source enough.
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.
A few reasons.
1. LibreSSL has no FIPS mode. FIPS mode is kind of dumb, but it is required in some environments.
2. LibreSSL was effectively OpenBSD only for some time. The compatibility shims have been written for other oses now I think, but it hasn't been available for as long as you think.
3. Swapping SSL libraries is a major change, beyond what is appropriate for a point release. Conservative distros 9LTS type distros especially) will be using OpenSSL for years to come because it's too big of a change to attempt outside of a major version bump.
I read the internet for the articles.
Add to those reasons the knowledge that the "better alternative" had the same undiscovered bugs and that OpenSSL found them first.
Democracy is a sheep and two wolves deciding what to have for lunch. Freedom is a well armed sheep contesting the issue
Those specific ones were indeed present in LibreSSL, but many others were not. Also some of the bugs, even if present, were mitigated if using OpenBSD.
I gave up with the idea of an useful sig...
They say FIPS and a secure, cleanly coded ssl library can't work, so who cares about some government-mandated 'standard'.
LibreSSL has been multi-platform for a year or so now, what are you smoking?
Switching to LibreSSL is no more than a binary (or source) package change as it has the same ABI/API as OpenSSL except for the retarded bits.
- These characters were randomly selected.
"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."
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?
Why are the majority of bug fixes flowing from OpenSSL to LibreSSL and not the other way around?
While that is true to some extent, decisions taken by the LibreSSL team has
prevented a lot of vulnerabilities.
Notably, none of the vulnerabilities found in OpenSSL and rated "High" were applicable to LibreSSL.
The point is the flamebait title is disingenuous, as it wants to paint a picture that OpenSSL is stupid, and the heir apparent for those with that mindset is LibreSSL. Meanwhile, this specific scenario they want to hold up as evidence.... well it's no better than LibreSSL for these. Maybe the argument can be made in other ways, but here it's just bad form.
XML is like violence. If it doesn't solve the problem, use more.
I don't agree with point 3. In my open source project, I changed from OpenSSL to mbed TLS in a few days.
It doesn't have to be like this. All we need to do is make sure we keep talking.
"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.
nonsense, LibreSSL has avoided many CVE by getting rid of dangerous and bloated code. OpenSSL is indeed the choice of the uninformed and stupid, or those looking to check a government compliance box being not concerned with actual security.
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.
People who do projects for the government. On a lot of projects, it's FIPS or GTFO, which makes life miserable, but it's a fact of life.
An interesting anagram of "BANACH TARSKI" is "BANACH TARSKI BANACH TARSKI"
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.
> LibreSSL has avoided many CVE by getting rid of dangerous and bloated code
And discarded compatibility with many, if not most, of the platforms that OpenSSL supports.
>> 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.
And discarded compatibility with many, if not most, of the platforms that OpenSSL supports.
Fortunately many, if not most, of those platforms have been obsolete and out of production for decades.
SJW n. One who posts facts.
Many != all.
Democracy is a sheep and two wolves deciding what to have for lunch. Freedom is a well armed sheep contesting the issue