Forthcoming OpenSSL releases(mta.openssl.org)
mta.openssl.org
Forthcoming OpenSSL releases
https://mta.openssl.org/pipermail/openssl-announce/2016-February/000063.html
6 comments
LibreSSL can't be used everywhere OpenSSL is currently used. Notably (and intentionally) missing is FIPS 140-2 support, which most (almost all?) commercial product that uses OpenSSL will rely upon for selling a FIPS 140-2 compliant or validated product.
Personally, I find Network Security Services (NSS) much better designed than OpenSSL/LibreSSL and wish more things would use it. Notably better is the use of an actual database to store objects. This really helps when you are using certificate revocation lists (CRLs) which may be huge blobs that change frequently.
Personally, I find Network Security Services (NSS) much better designed than OpenSSL/LibreSSL and wish more things would use it. Notably better is the use of an actual database to store objects. This really helps when you are using certificate revocation lists (CRLs) which may be huge blobs that change frequently.
Wasn't there recently an announcement that OpenSSL was planning on removing FIPS 140 support in the near future and possible add it back at a later point in time?
Specifically mentioned here, OpenSSL 1.1.x won't have FIPS support: https://groups.google.com/forum/#!searchin/mailing.openssl.d...
Specifically mentioned here, OpenSSL 1.1.x won't have FIPS support: https://groups.google.com/forum/#!searchin/mailing.openssl.d...
OpenSSL 1.0.x will likely remain supported (by someone, perhaps if not OpenSSL) for a long time due to this decision.
in some case, if you're able to switch libraries, you might also be able to switch languages and therefore skip on future issues inherent to C. Consider for example: https://golang.org/pkg/crypto/tls/
Glad they are fixing these but damn it is scary every time I see OpenSSL in a headline anymore.
btw
btw
HIGH Severity.
This includes issues that are of a lower risk than critical,
perhaps due to affecting less common configurations,
or which are less likely to be exploitable.
These issues will be kept private and will trigger
a new release of all supported versions.And we just finished rebooting everything for glibc…
I wonder what kind of new internet will emerge from the ashes of everything we've been using since the 1970s, when it finally all goes up in flames in the next few years.
I think you underestimate the sheer tenacity of crappy solutions.
I think you underestimate how badly things are failing.
Do tell, how badly are things failing?
Do you have data besides "look at all the vulns!"?
Do you have clear evidence of a negative economic trend that is linked to insecure software?
Do you have data besides "look at all the vulns!"?
Do you have clear evidence of a negative economic trend that is linked to insecure software?
You'll need a really, really, really massive meltdown before people are willing to fork over the money necessary to restart from scratch. Not even nuclear meltdowns have historically convinced people to do that. Not even global warming is convincing people to do that.
Exactly what I was thinking.
It's kind of unsettling to know there is a known vulnerability (at least known to some) out there and is going to stay unpatched for a couple of days. On the other hand, it is kind of nice to be able to brace for it mentally.
Does anybody know why the update is announced a couple of days in advance? Are e.g. maintainers of corresponding packages in Linux distros or *BSD given access to the code ahead of time so they can build new packages?
Does anybody know why the update is announced a couple of days in advance? Are e.g. maintainers of corresponding packages in Linux distros or *BSD given access to the code ahead of time so they can build new packages?
>Does anybody know why the update is announced a couple of days in advance?
For server operators to be prepared. (And I would prefer if they would narrow the timescales more for that.)
>Are e.g. maintainers of corresponding packages in Linux distros or *BSD given access to the code ahead of time so they can build new packages?
Yes, but that doesn't require a public announcement.
For server operators to be prepared. (And I would prefer if they would narrow the timescales more for that.)
>Are e.g. maintainers of corresponding packages in Linux distros or *BSD given access to the code ahead of time so they can build new packages?
Yes, but that doesn't require a public announcement.
Thanks for clearing that up!
The early announcement allows our sysadmins to plan to work during those hours, and for the rest of our org to know that we'll have rolling infrastructure downtime, and that isn't the best time to plan a new feature launch etc.
presumably, the newly released code might teach malicious users what vulnerabilities are there, which in turn makes everyone who didn't patch quickly vulnerable.
By announcing in advance what is going to happen, people can be ready to update as soon as the patch is available.
By announcing in advance what is going to happen, people can be ready to update as soon as the patch is available.
Eager to see how this LibreSSL comparison chart will be updated:
https://wiki.freebsd.org/LibreSSL#LibreSSL_.28and_OpenSSL.29...
The "totals" seems a bit off...
16 + 7 = 19?
5 + 31 + 12 = 36?
16 + 7 = 19?
5 + 31 + 12 = 36?
It is possible that some vulnerabilities affected both LibreSSL and OpenSSL. In those cases, the total would be smaller than the sum of its parts. However, that is just speculation on my part.
The linked numbers on the Wikipedia article make more sense.
Mirror available here, in case the official site stops loading: https://marc.ttias.be/openssl-announce/2016-02/msg00001.php
Support the OpenBSD team:
http://www.openbsdfoundation.org/campaign2016.html
that makes the LibreSSL.