Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSL Security Advisory

openssl.org

Post reply on HN
Print view View original

71–80 of 142 posts

Re: OpenSSL Security Advisory

#71

Post by Alupis »

drzaiusapelord wrote: post #38
acqq wrote: post #32

We probably don't need to worry this time: https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/ "The vulnerability appears to exist only in OpenSSL releases that happened in June 2015 and later. That leaves a lot of Linux distributions relatively safe, since they haven't gotten an OpenSSL update in a while. Red Hat, CentOS and Ubuntu appear to be entirely unaffected by this vulnerability, since they had no Op…

Christ, what a mess of a project. They inserted this after their big promise to do better after heartbleed? No wonder distros take their time moving to a new version. I really hope one of the alternative SSL libraries get picked up by the major distros. This is embarrassing, especially for those of us who have to justify FOSS in our environment. LibreSSL looks promising. Hopefully competition will mean better outcome…

You can't be serious here? Bugs are introduced into software all the time. It's a sign of active development.

It's not the number of bugs that matters, or even the fact that new bugs get introduced over time - rather it's the severity of the bugs, how rapidly the bugs are realized, and ultimately how fast they are dealt with.

In this case, it appears to have been a pretty rapid resolution - ie. about 1 month from it being introduced, realized, and fixed.

A lot of folks like to lean on LibreSSL and cite "supposed problems" with OpenSSL, just as you have done now. This is a naive approach -- LibreSSL took OpenSSL, cannibalized and gutted it, and all sorts of new, untested, un-vetted code injected. OpenSSL was written largely by crypto specialists, where LibreSSL is mostly a bunch of grumbling developers, with little to no prior crypto experience.

There's a reason the world is not jumping on LibreSSL just yet. There's a reason foundations outside of the LibreSSL home (OpenBSD) such as the Core Infrastructure Foundation have not backed it -- it's simply not ready, is very unproven, and won't be for a long, long time, if ever.

Give OpenSSL a break. It works far better than nay-sayers want to let on, and has done so for almost 2 decades.

Re: OpenSSL Security Advisory

#72

Post by acqq »

jgrahamc wrote: post #15

Interesting part is that the bug was introduced in the latest versions and has been fixed by the person who inserted it :-) Bug added: https://github.com/openssl/openssl/commit/da084a5ec6cebd67ae... Bug removed: https://github.com/openssl/openssl/commit/2aacec8f4a5ba1b365... Although that's just the committer: https://twitter.com/agl__/status/619129579580469248

Looking at the changes that introduced the bug, it's obvious that the nature of the problems being solved is too complex for the changes to be only "visually" reviewed. There must be enough external tests to "uncover" the potential issues. And the tests of course can have the bugs too, not covering what needed to be covered. That's why for so sensitive code the testers should be the best programmers with additional preference to search for the combinations that don't work as intended.

Re: OpenSSL Security Advisory

#73

Post by nly »

Arnt wrote: post #67
kaeso wrote: post #35

Earlier quoted context omitted.

This seems to be a common opinion recently, see https://tools.ietf.org/html/draft-thomson-postel-was-wrong-0...

But Jon Postel didn't mean what people now think he did. His famous principle is about border cases, when the spec is vague, handwavy or thought by some to be vague. It's not about the other cases. Remember that Jon Postel was the RFC editor. He didn't want anyone to ignore the RFCs, he wanted the RFCs to be readable and pleasant, and he wanted implementers to do the right thing when when an RFC erred on the side of…

Here's an example of the problem with that though: a mailing[0] by someone in February of this year asking if there's a formal grammar for the DNS zone (master) file format. This is a format that was first loosely specified in a RFC almost 32 years ago and there still isn't a rigorous definition. BIND now specifies a defacto interpretation with lots of liberal "treat this as a warning" options[1] and new gTLDs registries now insist on a subset of the original specification.

HTTP also has corner cases that widely-used implementations simply aren't handling consistently because the original RFCs are vague or the ideas being conveyed are buried in even older RFCs that nobody has the incentive to drill in to, or simply aren't known to them.

IMHO the IETF really should move to a wiki format, where information and wording changes on a particular protocol can be seen in one place. Plaintext snapshots of particular versions could still be published.

[0] https://www.ietf.org/mail-archive/web/dnsop/current/msg13349...

[1] https://kea.isc.org/wiki/ZoneLoadingRequirements#a3.3RFCimpl...

Re: OpenSSL Security Advisory

#74

Post by Arnt »

nly wrote: post #73
Arnt wrote: post #67

Earlier quoted context omitted.

But Jon Postel didn't mean what people now think he did. His famous principle is about border cases, when the spec is vague, handwavy or thought by some to be vague. It's not about the other cases. Remember that Jon Postel was the RFC editor. He didn't want anyone to ignore the RFCs, he wanted the RFCs to be readable and pleasant, and he wanted implementers to do the right thing when when an RFC erred on the side of…

Here's an example of the problem with that though: a mailing[0] by someone in February of this year asking if there's a formal grammar for the DNS zone (master) file format. This is a format that was first loosely specified in a RFC almost 32 years ago and there still isn't a rigorous definition. BIND now specifies a defacto interpretation with lots of liberal "treat this as a warning" options[1] and new gTLDs regist…

BTW there's a reason for that. The IETF decided (it must be a couple of decades ago) to restrict itself to matters of the internet. Things like file formats are thus out of scope for RFCs. There have been exceptions, RFC5952 is a good example and I know at least two others, but by and large RFCs are about the internet now, not about file formats or other worthy subjects.

Re: OpenSSL Security Advisory

#75

Post by nly »

Arnt wrote: post #74
nly wrote: post #73

Earlier quoted context omitted.

Here's an example of the problem with that though: a mailing[0] by someone in February of this year asking if there's a formal grammar for the DNS zone (master) file format. This is a format that was first loosely specified in a RFC almost 32 years ago and there still isn't a rigorous definition. BIND now specifies a defacto interpretation with lots of liberal "treat this as a warning" options[1] and new gTLDs regist…

BTW there's a reason for that. The IETF decided (it must be a couple of decades ago) to restrict itself to matters of the internet. Things like file formats are thus out of scope for RFCs. There have been exceptions, RFC5952 is a good example and I know at least two others, but by and large RFCs are about the internet now, not about file formats or other worthy subjects.

RFC7159? It even recommends a file extension.

Re: OpenSSL Security Advisory

#76

Post by mzs »

drzaiusapelord wrote: post #38
acqq wrote: post #32

We probably don't need to worry this time: https://ma.ttias.be/openssl-cve-2015-1793-man-middle-attack/ "The vulnerability appears to exist only in OpenSSL releases that happened in June 2015 and later. That leaves a lot of Linux distributions relatively safe, since they haven't gotten an OpenSSL update in a while. Red Hat, CentOS and Ubuntu appear to be entirely unaffected by this vulnerability, since they had no Op…

Christ, what a mess of a project. They inserted this after their big promise to do better after heartbleed? No wonder distros take their time moving to a new version. I really hope one of the alternative SSL libraries get picked up by the major distros. This is embarrassing, especially for those of us who have to justify FOSS in our environment. LibreSSL looks promising. Hopefully competition will mean better outcome…

"Patch provided by the BoringSSL project."

This is an example of them doing better. A bug was found, reported to them, and they responded quickly giving advanced notice too.

Re: OpenSSL Security Advisory

#77

Post by tedunangst »

Alupis wrote: post #71
drzaiusapelord wrote: post #38

Earlier quoted context omitted.

Christ, what a mess of a project. They inserted this after their big promise to do better after heartbleed? No wonder distros take their time moving to a new version. I really hope one of the alternative SSL libraries get picked up by the major distros. This is embarrassing, especially for those of us who have to justify FOSS in our environment. LibreSSL looks promising. Hopefully competition will mean better outcome…

You can't be serious here? Bugs are introduced into software all the time. It's a sign of active development. It's not the number of bugs that matters, or even the fact that new bugs get introduced over time - rather it's the severity of the bugs, how rapidly the bugs are realized, and ultimately how fast they are dealt with. In this case, it appears to have been a pretty rapid resolution - ie. about 1 month from it…

> and all sorts of new, untested, un-vetted code injected.

What?

Re: OpenSSL Security Advisory

#78

Post by tanderson92 »

aninteger wrote: post #43

Why has the adoption of alternative SSL software been so low. We have libressl, boringssl, something from Amazon? Very few Linux distributions seem interested in shipping alternative SSL software.

Some linux distributions allow you to choose your implementation of SSL upfront, be it libressl or openssl.

See: Exherbo Linux (http://www.exherbo.org/docs/eapi/providers-and-virtuals.html). This isn't one of the big distros, but you do have a choice.

Re: OpenSSL Security Advisory

#79

Post by judemelancon »

I am hardly astonished that a 319-line function that opens by declaring x, xtmp, xtmp2, chain_ss, bad_chain, param, depth, i, ok, num, j, retry, cb, and sktmp variables had a bug.

Before someone provides the standard "submit a patch" retort, I'll note that the variable naming is in full compliance with https://www.openssl.org/about/codingstyle.txt even if the function length isn't. A quick sample of other files suggests the function length matches actual practice elsewhere, too.

Re: OpenSSL Security Advisory

#80

Post by chrisfosterelli »

Alupis wrote: post #71
drzaiusapelord wrote: post #38

Earlier quoted context omitted.

Christ, what a mess of a project. They inserted this after their big promise to do better after heartbleed? No wonder distros take their time moving to a new version. I really hope one of the alternative SSL libraries get picked up by the major distros. This is embarrassing, especially for those of us who have to justify FOSS in our environment. LibreSSL looks promising. Hopefully competition will mean better outcome…

You can't be serious here? Bugs are introduced into software all the time. It's a sign of active development. It's not the number of bugs that matters, or even the fact that new bugs get introduced over time - rather it's the severity of the bugs, how rapidly the bugs are realized, and ultimately how fast they are dealt with. In this case, it appears to have been a pretty rapid resolution - ie. about 1 month from it…

I agree he is being excessively hard on OpenSSL, but they have had alot of problems as of late. Software bugs are introduced all the time, you're correct, but projects like OpenSSL should be keeping a much closer eye because state agencies and other malicious parties are definitely watching development closely.
Post reply on HN