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

91–100 of 142 posts

Re: OpenSSL Security Advisory

#91

Post by judemelancon »

ajross wrote: post #83
judemelancon wrote: post #79

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 sugge…

You seriously have trouble reading "i", "j", "param" and "num"? Hell, "ok", "depth" and "retry" are already in your English-language dictionary! I'll grant that having variables named with "tmp" is confusing out of context, I guess. But if you're trying to start a Java-style war over this stuff, just recognize that most of the world has moved on and views names like those as perfectly fine when used within standard i…

I have trouble understanding what they're meant to signify, yes. I am a regular human with finite intellect; I admit it.

To actually comprehend this function requires storing those 14 names in short-term memory, reading through the over 300 lines of remaining code, filling in bits of the meaning of those names as they become clear, and only then reading the code again with that mental map. That's the case where none of the 14 have slipped my mind by the time I get back around. That just seems like an awful lot of overhead to net something that could be as easy as reading names if they were better chosen.

Just as a demonstration, why don't you time how long it takes you to figure out what j actually is and then report back?

Re: OpenSSL Security Advisory

#92

Post by glass- »

dozzie wrote: post #49
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.

Because despite bug history of OpenSSL, nothing proved to be more reliable to this moment.

> nothing proved to be more reliable to this moment.

Huh? Of the 22 vulnerabilities OpenSSL has disclosed since March (4 high severity, 14 moderate, 4 low), LibreSSL has been vulnerable to 8 (0 high, 6 moderate, 2 low).

References:

March: https://marc.info/?l=openbsd-cvs&m=142677372515025&w=2

June: https://marc.info/?l=openbsd-announce&m=143406498020131&w=2

Today: https://marc.info/?l=openbsd-tech&m=143645910727507&w=2

Re: OpenSSL Security Advisory

#93

Post by Alupis »

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.

RFC 6120 and 6121 are for XMPP (chat), and define XML is to be used, and even goes into the exact structure of the XML "packets".

Re: OpenSSL Security Advisory

#94

Post by Alupis »

ctz wrote: post #59
valarauca1 wrote: post #55

Earlier quoted context omitted.

If you think you can write a better implementation then put your hands where your keyboard is. Show us the code. If not, submit patches. An OpenSSL team member said, "If you're in a position to offer technical criticism you're in a position to offer technical help." While it sounds like their pleading for help, its because WE ARE. There are 3 full time maintainers, 1 is a dog :P and only ~10-16 regular patch submitte…

The bit you don't cover is where you repeatedly submit patches (in my case, for example, to fix documentation and improve testing) which are ignored.

This is not true anymore. At the time, OpenSSL had really a single maintainer, and was only receiving $2,000 a year in "donations". Not exactly something to keep someone working full time on the project with.

A lot of that has now changed with the Core Infrastructure Initiative.

Re: OpenSSL Security Advisory

#95

Post by d_theorist »

ajross wrote: post #83
judemelancon wrote: post #79

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 sugge…

You seriously have trouble reading "i", "j", "param" and "num"? Hell, "ok", "depth" and "retry" are already in your English-language dictionary! I'll grant that having variables named with "tmp" is confusing out of context, I guess. But if you're trying to start a Java-style war over this stuff, just recognize that most of the world has moved on and views names like those as perfectly fine when used within standard i…

Are you kidding me? There is no possible universe in which 'param' is an acceptable name for an argument.

Re: OpenSSL Security Advisory

#96

Post by glass- »

jerf wrote: post #63
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.

Probably because once you wrap your code around one SSL stack it's hard to migrate it to another. So you stick to the one you use first. OpenSSL, for instance, isn't just an SSL library... since C has no standardized "stream" functionality, it's a whole big generic streaming library with pluggable modules for various streams and the ability to write your own... once you're stuck to that you can get stuck pretty hard…

LibreSSL is a drop-in replacement for OpenSSL.

Re: OpenSSL Security Advisory

#97

Post by benmmurphy »

An interesting coincidence is I noticed what I thought (and maybe is) a similar bug in the elixir hex module on the same day that this bug report was submitted to openssl. If you look at the hex partial chain method (https://github.com/hexpm/hex/blob/master/lib/hex/api.ex#L59-...) you can see it goes through all the certificates the other party supplied starting from the first one and tries to find one that is signed by a certificate in the trust store. it then explicitly returns it as the trusted_ca which effectively means the certificate has the CA bit set on it.

in order to exploit the attack in hex you need find a CA that will directly issue certificates off of a certificate in a trust store. apparently, this is not the recommended policy for CAs. so I made this tweet: (https://twitter.com/benmmurphy/status/613733887211139072)

'does anyone know a CA that signs directly from their root certs or has intermediate certs in trust stores? asking for a friend.'

and apparently there are some CAs that will do this. in the case of hex i think the chain you need to create looks something like this:

    RANDOM CERT SIGNED BY ISSUER NOT IN TRUST STORE
    |
    V
    VALID_CERT_SIGNED_BY_CERT_IN_TRUST_STORE (effectively treated as CA bit set)
    |
    V
    EVIL CERTIFICATE SIGNED BY PREVIOUS CERT

Re: OpenSSL Security Advisory

#98

Post by yuhong »

benmmurphy wrote: post #97

An interesting coincidence is I noticed what I thought (and maybe is) a similar bug in the elixir hex module on the same day that this bug report was submitted to openssl. If you look at the hex partial chain method ( https://github.com/hexpm/hex/blob/master/lib/hex/api.ex#L59-... ) you can see it goes through all the certificates the other party supplied starting from the first one and tries to find one that is sign…

AFAIK the Baseline Requirements don't allow it but old certs that are not expired may still exist. It was one of the reasons why the e-Guven root was removed from Mozilla.

Re: OpenSSL Security Advisory

#99

Post by dozzie »

glass- wrote: post #92
dozzie wrote: post #49

Earlier quoted context omitted.

Because despite bug history of OpenSSL, nothing proved to be more reliable to this moment.

> nothing proved to be more reliable to this moment. Huh? Of the 22 vulnerabilities OpenSSL has disclosed since March (4 high severity, 14 moderate, 4 low), LibreSSL has been vulnerable to 8 (0 high, 6 moderate, 2 low). References: March: https://marc.info/?l=openbsd-cvs&m=142677372515025&w=2 June: https://marc.info/?l=openbsd-announce&m=143406498020131&w=2 Today: https://marc.info/?l=openbsd-tech&m=143645910727507&w…

And how long is LibreSSL on the market? A year? It's hard to call it proof. It's easy to point intervals longer than whole LibreSSL lifetime with no security bugs in OpenSSL.

Re: OpenSSL Security Advisory

#100

Post by sliverstorm »

judemelancon wrote: post #79

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 sugge…

Reading your comment I initially assumed {i, j} were iterators, in which case they would be fine by me. Nope.
Post reply on HN