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

131–140 of 142 posts

Re: OpenSSL Security Advisory

#131

Post by sjolsen »

rgj wrote: post #112
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…

And the coding style doesn't exactly avoid errors as well. "Do not unnecessarily use braces around a single statement: if (condition) action(); and if (condition) do_this(); else do_that(); " Didn't people learn from the goto fail bug ? http://embeddedgurus.com/barr-code/2014/03/apples-gotofail-s...

Maybe the coding standard was written by someone who was used to auto-indentation making this sort of mistake immediately obvious.

Re: OpenSSL Security Advisory

#132

Post by nadams »

kstrauser wrote: post #130
nadams wrote: post #116

Earlier quoted context omitted.

I once worked with some Linux admins who told me that SSH public key authentication wasn't secure.

While that's certainly possible, it's an extraordinary claim because it flies in the face of generally accepted beliefs. If your coworker was Bruce Schneier, I would pay close attention to his explanation. If they were your standard issue sysadmin types, then I'd want to know: 1) Why they believe so, 2) Why they haven't filed security advisories to advise the rest of us, and 3) Why you don't hear about banks being wi…

1) Wouldn't tell us

2) I tried to explain millions of people around the world rely on it and use it. I argue it's probably safe (within reason - obviously the weak point is the private key file).

These were also the guys who refused to install packages we asked for from the community RedHat repository claiming security vulnerabilities but then they just admitted they installed some packages from there for their own use for puppet and other things they do.

Re: OpenSSL Security Advisory

#133

Post by technion »

ams6110 wrote: post #113
glass- wrote: post #96

Earlier quoted context omitted.

LibreSSL is a drop-in replacement for OpenSSL.

Well that's the intention... is it really in practice? They have deliberately removed a lot of support for rare architectures and features. Distributions such as CentOS/RHEL which are focused on stability are not going to replace OpenSSL in any existing releases.

I can confirm that it currently just "drops in" when linked against nginx. This initially took a few small patches, but these have been merged into LibreSSL mainline.

I've been testing this against each release for some time and I'm very happy with it.

Re: OpenSSL Security Advisory

#134

Post by caf »

toast0 wrote: post #68
pilif wrote: post #4

> OpenSSL will attempt to find an alternative certificate chain if the first attempt to build such a chain fails I think the latest big thing I've learned in my career is that trying to fix broken input data silently is always bad. Fixing stuff silently isn't helpful for the callers, it's very difficult to do and it produces additional code which also isn't running in the normal case, so it's much more likely to be b…

Alternate chains aren't a broken input issue; it's an issue where not all clients have the same CAs; so if you need to chain to an old 1024-bit root to take care of really old clients, newer clients without 1024-bit roots should be able to validate still. Older versions of openssl need to keep the 1024-bit root around, because the only validate the full chain provided by the server.

To clarify this a bit:

The problem is that you want to retire a 1024-bit CA root, and replace it with a 4096-bit CA root. To do this effectively, new clients need to stop trusting the old 1024-bit CA root, or there's no point doing the transition.

However, you still want certificates that you issue to be verified by old clients that don't know about the 4096-bit CA root.

To solve this, you issue certificates with two alternate chains of trust - one up to the old 1024-bit root, and one up to the new 4096-bit root - and teach the new clients to check all the alternate chains.

It's this last bit that required the code change in OpenSSL, which contained the logic error that resulted in this vulnerability.

Re: OpenSSL Security Advisory

#135

Post by caf »

mvanotti wrote: post #106
mykhal wrote: post #9

from test/verify_extra_test.c: Test for CVE-2015-1793 (Alternate Chains Certificate Forgery) Chain is as follows: rootCA (self-signed) | interCA | subinterCA subinterCA (self-signed) | | leaf ------------------ | bad rootCA, interCA, subinterCA, subinterCA (ss) all have CA=TRUE leaf and bad have CA=FALSE subinterCA and subinterCA (ss) have the same subject name and keys interCA (but not rootCA) and subinterCA (ss) ar…

So, bad certificate HAS to be signed by leaf certificate, and leaf certificate HAS to be trusted. (And you need two CAs with the same keys) openssl would accept certs that have been issued by a non-ca cert (which is trusted). So if you have control over the leaf cert, you can just use it for contacting openssl. If you don't have control over the leaf cert, you can't issue a bad cert. Am I missing something?

The leaf cert is signed for evil-bastard.net, but the "bad" cert can be for mail.google.com.

Re: OpenSSL Security Advisory

#136

Post by kstrauser »

nadams wrote: post #132
kstrauser wrote: post #130

Earlier quoted context omitted.

While that's certainly possible, it's an extraordinary claim because it flies in the face of generally accepted beliefs. If your coworker was Bruce Schneier, I would pay close attention to his explanation. If they were your standard issue sysadmin types, then I'd want to know: 1) Why they believe so, 2) Why they haven't filed security advisories to advise the rest of us, and 3) Why you don't hear about banks being wi…

1) Wouldn't tell us 2) I tried to explain millions of people around the world rely on it and use it. I argue it's probably safe (within reason - obviously the weak point is the private key file). These were also the guys who refused to install packages we asked for from the community RedHat repository claiming security vulnerabilities but then they just admitted they installed some packages from there for their own u…

So... the standard issue sysadmin types. Sigh. :-(

Re: OpenSSL Security Advisory

#137

Post by [deleted] »

thrownaway2424 wrote: post #104
acqq wrote: post #72

Earlier quoted context omitted.

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

You're confused. This thread is about OpenSSL. OpenSSL doesn't have tests.

[deleted]

Re: OpenSSL Security Advisory

#138

Post by frankzinger »

kyberias wrote: post #115
bch wrote: post #102

Earlier quoted context omitted.

This is also an example of open source working, in general. Bug found in one project, applied to other.

I think the same could happen in closed source projects as well.

Theoretically, but it's a lot more likely to happen if the projects have almost identical codebases (BoringSSL is a fork of OpenSSL).

Re: OpenSSL Security Advisory

#139

Post by tracker1 »

rgj wrote: post #112
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…

And the coding style doesn't exactly avoid errors as well. "Do not unnecessarily use braces around a single statement: if (condition) action(); and if (condition) do_this(); else do_that(); " Didn't people learn from the goto fail bug ? http://embeddedgurus.com/barr-code/2014/03/apples-gotofail-s...

Personally, I say if a statement continues on a different line, then you should use braces

    //okay
    if (condition) return foo;

    //not okay
    if (condition)
        return foo;

    //not okay
    if (condition) do_foo();
    else do_bar();
In the second case, the else can be considered a continuation. In the first example, there's little chance of confusion or the introduction of an error, in the second and third, that is not necessarily the case.

If it doesn't look/fit well on one line, break it up with braces.

Re: OpenSSL Security Advisory

#140

Post by breakingcups »

tracker1 wrote: post #139
rgj wrote: post #112

Earlier quoted context omitted.

And the coding style doesn't exactly avoid errors as well. "Do not unnecessarily use braces around a single statement: if (condition) action(); and if (condition) do_this(); else do_that(); " Didn't people learn from the goto fail bug ? http://embeddedgurus.com/barr-code/2014/03/apples-gotofail-s...

Personally, I say if a statement continues on a different line, then you should use braces //okay if (condition) return foo; //not okay if (condition) return foo; //not okay if (condition) do_foo(); else do_bar(); In the second case, the else can be considered a continuation. In the first example, there's little chance of confusion or the introduction of an error, in the second and third, that is not necessarily the…

What about:

if((somevar != checkvar((byte)othervar)) & (i != 3)) somefunc();

someotherfunc();

A bit exaggerating, I agree, but not far off from some real-world examples and quite confusing.

Post reply on HN