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

OpenSSL Security Advisory [7th February 2023]

openssl.org

Post reply on HN
Print view View original

41–50 of 54 posts

Re: OpenSSL Security Advisory [7th February 2023]

#41

Post by brynet »

traceroute66 wrote: post #26
KennyBlanken wrote: post #23

A reminder that LibreSSL exists and has a fraction of the problems OpenSSL does. https://www.libressl.org/

> A reminder that LibreSSL exists and has a fraction of the problems OpenSSL does. Ahem. Cough. Maybe I should leave this little link here for a patch published today ? https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/018_x...

Commit message: https://marc.info/?l=openbsd-cvs&m=167578479210650&w=2

> "Release date for this was set to be January 31. Unilaterally pushed back to February 7 by OpenSSL by way of announcement of many completely unrelated embargoed issues, some of which they had been sitting on since July 2020"

Re: OpenSSL Security Advisory [7th February 2023]

#43

Post by nekoashide »

tialaramex wrote: post #28
mg_at_fork-pl wrote: post #18

Earlier quoted context omitted.

It was never 2 years as it's not 1 year now. It's specified in days (397 currently, 825 and 1185 days before).

For a long time it was months. The original BRs say 60 months (ie 5 years) and then moving to 39 months in 2015. That 1185 days you listed wasn't ever actually in a written document, it's how Chromium browsers generously estimate 39 months. But yes, none of it matters any more. Apple insisted on 398 days, they decided it is a compliance issue, so all legit leaf certificates in the Web PKI that haven't expired have a…

The CA/B forum lost a lot of credibility with me, the vote failed and it took a single member (Apple) to tell everyone else that they were going to ignore the vote and proceed anyways.

No debate, no re-vote, no giving anyone any extra time or warning.

Re: OpenSSL Security Advisory [7th February 2023]

#44

Post by g0xA52A2A »

brynet wrote: post #41
traceroute66 wrote: post #26

Earlier quoted context omitted.

> A reminder that LibreSSL exists and has a fraction of the problems OpenSSL does. Ahem. Cough. Maybe I should leave this little link here for a patch published today ? https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/018_x...

Commit message: https://marc.info/?l=openbsd-cvs&m=167578479210650&w=2 > "Release date for this was set to be January 31. Unilaterally pushed back to February 7 by OpenSSL by way of announcement of many completely unrelated embargoed issues, some of which they had been sitting on since July 2020"

This exemplifies one of the key reasons OpenBSD forked OpenSSL. For those who haven't seen it I'd recommend this presentation from Bob Beck[1], around the 10 minute mark he recounts fixing issues in the memory allocator which had been reported 4 years prior. Seems there's still a similar backlog sitting behind embargoes?

[1] https://www.youtube.com/watch?v=GnBbhXBDmwU

Re: OpenSSL Security Advisory [7th February 2023]

#45

Post by topspin »

lucb1e wrote: post #37
topspin wrote: post #21

One type error, one timing attack and six memory safety problems. Defect ratio checks out.

Ratio of what to what? Do you mean the number of bugs one would expect to find in a modern implementation (the former two) as a ratio to the number of bugs one finds in old C code (all of the above)?

Basically. Microsoft and Google have both analyzed software defects and claimed that memory safety violations account for ~70%. I don't have time to dig up citations atm, but it's not hard to find. I think the Google results are 'security' related defects whereas the Microsoft results are all defects, but look it up yourself.

Re: OpenSSL Security Advisory [7th February 2023]

#46

Post by Nimi »

Is there a writeup describing the exact timing side channel? The advisory states that the vulnerability affects all RSA padding modes, which seems to imply non-constant-time BigNum operations. However, OpenSSL implemented RSA blinding even before the fix, which is supposed to prevent those class of problems. So this should be interesting :-)

(I did find the commit fixing it, but it's huge, and I can't follow the change: https://github.com/openssl/openssl/commit/b1892d21f8f0435deb...

Re: OpenSSL Security Advisory [7th February 2023]

#47

Post by Flocular »

dochtman wrote: post #36
KennyBlanken wrote: post #23

A reminder that LibreSSL exists and has a fraction of the problems OpenSSL does. https://www.libressl.org/

A reminder that rustls exists, and leverages the Rust compiler to make sure no memory safety issues exist in your TLS implementation: https://github.com/rustls/rustls Some thoughts on lessons learned from other projects/vulnerabilities: https://docs.rs/rustls/latest/rustls/manual/index.html

For cryptography it uses the ring-library which still relies on C-Code in many places. Additionally there is no API-stability (still v0.*) and the last official audit was 3 years ago.

The project has potential but isn't quite ready for prime time yet.

Re: OpenSSL Security Advisory [7th February 2023]

#48

Post by tptacek »

nekoashide wrote: post #43
tialaramex wrote: post #28

Earlier quoted context omitted.

For a long time it was months. The original BRs say 60 months (ie 5 years) and then moving to 39 months in 2015. That 1185 days you listed wasn't ever actually in a written document, it's how Chromium browsers generously estimate 39 months. But yes, none of it matters any more. Apple insisted on 398 days, they decided it is a compliance issue, so all legit leaf certificates in the Web PKI that haven't expired have a…

The CA/B forum lost a lot of credibility with me, the vote failed and it took a single member (Apple) to tell everyone else that they were going to ignore the vote and proceed anyways. No debate, no re-vote, no giving anyone any extra time or warning.

That's how it should work: the major browser vendors and their root programs should be calling the shots. Participation in CA/B is a favor they do the CA industry, nothing more. The rise of activist browser root programs correlates with essentially everything good that has happened in the WebPKI.

Re: OpenSSL Security Advisory [7th February 2023]

#49

Post by akira2501 »

topspin wrote: post #21

One type error, one timing attack and six memory safety problems. Defect ratio checks out.

OpenSSL is not a security product. It's a loss leader for a security company that sells support contracts. There isn't very much incentive for them to turn out a good product.

Re: OpenSSL Security Advisory [7th February 2023]

#50

Post by lucb1e »

topspin wrote: post #45
lucb1e wrote: post #37

Earlier quoted context omitted.

Ratio of what to what? Do you mean the number of bugs one would expect to find in a modern implementation (the former two) as a ratio to the number of bugs one finds in old C code (all of the above)?

Basically. Microsoft and Google have both analyzed software defects and claimed that memory safety violations account for ~70%. I don't have time to dig up citations atm, but it's not hard to find. I think the Google results are 'security' related defects whereas the Microsoft results are all defects, but look it up yourself.

No need, I had the same initial reaction as I scrolled through the list, going from "oh that's a lot of security issues... and virtually all C issues, too... ugh why do we still do this"
Post reply on HN