8 ms·

OpenSSL 1.1.1 End of Life

168 points by gslin 3y ago

1vuio0pswjnm7 3y ago
3.x openssl has a dedicated mac command. But 1.x only had dgst command with a -mac option.
- ComputerGuru 3y ago
  Was this in reply to something specific?
- deleted 3y ago
  [deleted]
Brananarchy 3y ago
This is going to be a big deal. So many applications and appliances that have received bare-minimum updates won't get a new openssl major version. Expect new attacks on your shitty IOT devices in the coming year
- rurban 3y ago
  Shitty IOT devices are too small to use openssl anyway. The big ones are updated with their stack. We started upgrading our stack about half a year ago, and 3.x should be ready now for the next release. The biggest change were outdated RC4, which was a good thing to get rid of this cruft
  - jeroenhd 3y ago
    Plenty of IoT devices out there that run on full-blown Raspberry Pi's or equivalent boards. Paying someone to write embedded firmware is expensive, throwing together a UI in Python is cheap. Not that this poses such an issue for those devices; I doubt they ever received firmware updates in the first place. Still, you'll find OpenSSL in the weirdest places.
  - crest 3y ago
    The worst IOT devices are based on old EoL Android versions hacked on without any understanding by each party adding a little and resell it as the next higher margin product like nesting matryoshka dolls while planning to dissolve the respective business before anyone sues them for the abomination they cobbled together.
  - supertrope 3y ago
    I once saw a photo of crashed credit card machine. A diagnostic screen showed openssl as one of the libraries in use.
- TheDong 3y ago
  The majority of those applications and devices are already stuck on 0.9.x anyway, so it's not like it makes that much of a difference. It doesn't seem like that big of a deal to me. The majority of "shitty IOT devices" only make outgoing TLS connections to relatively trusted external servers (i.e. the company's server), and it's hard enough to MITM connections at scale that you're probably fine. Just don't let a malicious stranger on your wifi. Adding to that, it's also pretty hard to develop real exploits for the supposed RCE CVEs that you see. Like, most of them are "there's a buffer overrun, this is probably RCE", but most of the time it's actually "no, for all real builds of openssl, this is a crash and that is it".
  - 65a 3y ago
    This could be great news for open source actually, how do you think they are checking firmware signing keys and upstream servers?
  - tinus_hn 3y ago
    You don’t need to do complicated MITM attacks to abuse these issues if you control the DNS servers, like if you’re the ISP or one of the parties that provide fashionable DNS servers like Google or Cloudflare.
- userbinator 3y ago
  What practically exploitable attacks have shown up in OpenSSL over the years, with the exception of Heartbleed?
- deleted 3y ago
  [deleted]
- nikanj 3y ago
  Most openssl-CVEs suffer from massive severity inflation. ”If you can fool a client running on AIX to connect to a server with deprecated hashing algorithm from 1986, you can make the client take an extra 40 milliseconds to process the packets” ”CVE 9.9 resource exhaustion DDoS confirmed”
  - ilyt 3y ago
    That's CVEs in general it seems "if you set input parameters of curl to absolute nonsense, something bad will happen" 9.8/10 https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-everything-that-is-wrong-with-cves/ https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-eve... https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/ https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/
- maccard 3y ago
  Is it really? Those applications are very unlikely to even be getting security updates at this point.
fh973 3y ago
Who is OpenSSL and why do they sell expensive support contracts? It sounds like 1.1.1 is only EOL if you don't pay.
- kstrauser 3y ago
  Isn't that almost always the case with FOSS projects? For instance, throw enough money at Red Hat and I bet they'd support anything you'd like for as long as you'd want.
  - fh973 3y ago
    No, not at all ! It can only be the case of the maintaining entity is the one that sells support. That's actually the definition of commercial software! It may be the case for company-backed FOSS projects (that use FOSS as a marketing channel and have a business model around it). You might be used to that because Redhat, Elastic, Mongo, ... But for very large number of FOSS projects, that's not the case. Either there is no paid support, or it is done by a third-party. But then this third party doesn't call the shots what's deprecated and what's backported where. I was under the impression that OpenSSL is a community project, and now it appears that that's not the case.
- aaomidi 3y ago
  OpenSSL is the dependency for doing TLS and a lot more. It’s effectively one of the only options. Crypto is hard, and crypto in C is fucking awful. Hence the pricing.
  - dharmab 3y ago
    BoringSSL, wolfSSL, LibreSSL, not to mention the various FIPS options.
    - aaronmdjones 3y ago
      ARM mbedTLS is one of my favourites. Excellent documentation.
    - 3y ago
EustassKid 3y ago
I don't know about other Linux distributions (or operating systems) but a while ago NixOS marked Sublime Text as insecure and wouldn't let me install it without me setting the option to allow insecure packages (since it depends on openssl 1.1.1u), I don't know how dangerous it would be to have software with an out of date TLS library for me, a regular user, but I just switched to emacs, so sad because ST is an excellent editor, a great set of features and plugins while still being extremely fast (which is my problem with VSCode).
- iotku 3y ago
  I briefly looked into it (from the same NixOS issues), there's a GitHub issue somewhere about it [1] Effectively as I recall it a large amount of Sublime Text plugins internally rely on an old version of Python (3.3) which in turn relies on OpenSSL 1.1.1, there is concern that forcing the python version to something newer will largely break their plugin ecosystem as a lot of the plugins are expecting Python 3.3 and may not be compatible with 3.8 or later versions with supported OpenSSL. It's probably not a major security risk unless the plugins are making network connections, but it is an unfortunate situation. Edit: [1] https://github.com/sublimehq/sublime_text/issues/5984 https://github.com/sublimehq/sublime_text/issues/5984
  - deleted 3y ago
    [deleted]
  - MatthiasPortzel 3y ago
    The thing that frustrates me about Sublime’s position is this (from that link): > With most packages being no longer maintained there's little chance to get that file into existing repos. So you can’t break backwards compatibility because “most packages” aren’t maintained. But that means those packages are no longer receiving bug fixes. As a new Sublime Text user (within the last year), the package situation is definitely frustrating. There seems to be a lot of pride within the Sublime staff and core volunteer group, some of which is deserved, Sublime is an amazing editor. But at some point they’re going to have to admit that the current set of packages isn’t perfect and deprecate a bunch of them.
_V_ 3y ago
This unfortunately already completely broke Gentoo for the moment :-( Maintainers masked openssl-1.1.1 but there is currently a ton of packages with (sometimes needlessly) hardcoded requirement for old openssl. Including things like Rust etc. This will be painful.
- ilyt 3y ago
  I'm surprised! That gentoo is still alive. But being behind Debian Stable on up to date packaging doesn't look great...
  - terinjokes 3y ago
    I use Gentoo on a few machines, and I'm confused by what GP says: I have no problems using OpenSSL 3, and the 1.1 releases have been masked (not installable by default) for a while now.
    - _V_ 3y ago
      I'm talking about this: The following mask changes are necessary to proceed: (see "package.unmask" in the portage(5) man page for more details) # required by net-libs/nodejs-20.5.1::gentoo # required by www-client/firefox-102.15.0::gentoo # required by @selected # required by @world (argument) =dev-libs/openssl-1.1.1v And many many many more packages. I went through like 20 yesterday and created custom ebuilds without mentions to slot :0= in ebuild, but there is plenty more.
      - terinjokes 3y ago
        Something seems unusual about your system. Are you using an unusual profile or heavily customized make.conf? net-libs/nodejs-20.5.1 is satisfied with dev-libs/openssl-3.0.10 out of the box here. I have a fully updated world with a KDE desktop, and don't have OpenSSL 1.1 installed at all.
        _V_ 3y ago
bazzargh 3y ago
OpenSSL 3 seems to be largely compatible (it's a much easier upgrade than previous big ones) but the part of this that breaks clients is odd. If your peer closes the connection without sending close_notify, you get an unexpected EOF; 1.1.1 ignored this, 3 passes the error to the client, which needs to set SSL_OP_IGNORE_UNEXPECTED_EOF to recover the old behaviour - but this is only safe as long as the client checks for truncation attacks. This peer behaviour seems to be pretty common for google servers, so if you use google logins or APIs it'll trip you up (from doing these upgrades at work, almost all of the errors I saw were talking to google) What's odd to me is most of the patches I saw for this were just setting that flag, and not doing anything about truncation attacks? I'm sure this will bite us all somewhere down the line. Anyway, some notes for admins of old systems who got to this too late: It was noticeable that this patch got backported into ppa's that maintain old/deprecated versions of some software. eg the ondrej php ppa has this backported to EOL'd versions of php. But, this is not the case for the python deadsnakes ppa - I didn't look at python 3.8, but 3.9 was fixed at source, and it hasn't been backported to the (EOL'd) 3.7 anywhere. You should be off 3.7 anyway, but if you're not, it's now urgent. Another notable backport is openresty. If you're using nginx with lua and oauth, it's a popular choice; but lags the latest nginx by a long way. The latest version is 1.21.4.2 which means it's based on nginx 1.21; but nginx is on 1.25 and nginx only released with openssl 3 support in 1.22. If you proxy to https servers, this is a concern. However, digging I found the openssl3 support was backported to openresty a few months ago, so the _current_ version does work without falling over.
- planede 3y ago
  So was the truncation attack already there in 1.1.1? I think it's OK for a patch that changes the dependency to 3 to just retain existing behavior. Addressing the problematic behavior should be a distinct patch.
  - bazzargh 3y ago
    Yes, the fix for the truncation attack was originally rolled into 1.1.1e (March 2020) and then withdrawn in 1.1.1f because the new errors were too disruptive; IIRC the fix was already in the 3.x prereleases by that stage. So effectively if you stuck on 1.1.1, you've been living with this risk for 3 years. The truncation attack is one where the client thinks their ssl session has ended but a malicious actor prevents the session from ending correctly; the threat is something like, after doing this your gmail can be messed with even tho you think you've logged out. From the descriptions it seems like you'd need to layer it with another attack or two to do anything useful with it. It's not something that keeps me awake at night. When I dug into the python code we had hitting this a few months back (python 3.7 on recent ubuntu) it appeared that the error would not only trip up a client expecting to use 1.1.1 but could mean the last buffer read from the socket was not flushed (so, you can't just catch the error in python and assume it's ok because the other end had closed the connection anyway - you're missing some of the response). I wasn't certain but that possibility was a big bucket of NOPE for me, far easier to tell people to get the upgrade done and stop using software that had been built against 1.1.1.
jmclnx 3y ago
Interesting, you can purchase support for 1.1.1x between 15,000 -- 50,000 USD per year. I can see some large Companies in panic mode now, so the option exists for them to continue with older versions. This explains why NetBSD 10.0 people are holding the release until they get the new version working in Base and pkgsrc. https://www.openssl.org/support/contracts.html#premium https://www.openssl.org/support/contracts.html#premium
- tempay 3y ago
  Can you get support for 15k? My reading of that page is that extended support is only for the top 50k a year package. Though in reality RedHat and others will keep OpenSSL 1.1.1 patched for quite a while yet.
- teh_klev 3y ago
  > Interesting, you can purchase support for 1.1.1x between 15,000 -- 50,000 USD per year. Nitpick, from the announcement, only the Premium contract ($50K per year) provides for extended 1.1.1 support: Another option is to purchase a premium support contract which offers extended support (i.e. ongoing access to security fixes) for 1.1.1 beyond its public EOL date. There is no defined end date for this extended support and we intend to continue to provide it for as long as it remains commercially viable for us to do so (i.e. for the foreseeable future).
- sabareesh 3y ago
  why not use libressl
Sytten 3y ago
I imagine there is a clause in the support contract that prevents the disclosure of source code? I am wondering if we will need a community supported fork. I have said it for months that this transition will be a mess, so many distribution LTS and packages are built for 1.1.1
cracauer 3y ago
The FreeBSD experience with the upgrade also shows that this is not a smooth enforced upgrade.

168 points by gslin 3y ago

1vuio0pswjnm7 3y ago

3.x openssl has a dedicated mac command. But 1.x only had dgst command with a -mac option.

ComputerGuru 3y ago
Was this in reply to something specific?
deleted 3y ago
[deleted]

Brananarchy 3y ago

This is going to be a big deal. So many applications and appliances that have received bare-minimum updates won't get a new openssl major version. Expect new attacks on your shitty IOT devices in the coming year

rurban 3y ago
Shitty IOT devices are too small to use openssl anyway. The big ones are updated with their stack. We started upgrading our stack about half a year ago, and 3.x should be ready now for the next release. The biggest change were outdated RC4, which was a good thing to get rid of this cruft
- jeroenhd 3y ago
  Plenty of IoT devices out there that run on full-blown Raspberry Pi's or equivalent boards. Paying someone to write embedded firmware is expensive, throwing together a UI in Python is cheap. Not that this poses such an issue for those devices; I doubt they ever received firmware updates in the first place. Still, you'll find OpenSSL in the weirdest places.
- crest 3y ago
  The worst IOT devices are based on old EoL Android versions hacked on without any understanding by each party adding a little and resell it as the next higher margin product like nesting matryoshka dolls while planning to dissolve the respective business before anyone sues them for the abomination they cobbled together.
- supertrope 3y ago
  I once saw a photo of crashed credit card machine. A diagnostic screen showed openssl as one of the libraries in use.
TheDong 3y ago
The majority of those applications and devices are already stuck on 0.9.x anyway, so it's not like it makes that much of a difference. It doesn't seem like that big of a deal to me. The majority of "shitty IOT devices" only make outgoing TLS connections to relatively trusted external servers (i.e. the company's server), and it's hard enough to MITM connections at scale that you're probably fine. Just don't let a malicious stranger on your wifi. Adding to that, it's also pretty hard to develop real exploits for the supposed RCE CVEs that you see. Like, most of them are "there's a buffer overrun, this is probably RCE", but most of the time it's actually "no, for all real builds of openssl, this is a crash and that is it".
- 65a 3y ago
  This could be great news for open source actually, how do you think they are checking firmware signing keys and upstream servers?
- tinus_hn 3y ago
  You don’t need to do complicated MITM attacks to abuse these issues if you control the DNS servers, like if you’re the ISP or one of the parties that provide fashionable DNS servers like Google or Cloudflare.
userbinator 3y ago
What practically exploitable attacks have shown up in OpenSSL over the years, with the exception of Heartbleed?
deleted 3y ago
[deleted]
nikanj 3y ago
Most openssl-CVEs suffer from massive severity inflation. ”If you can fool a client running on AIX to connect to a server with deprecated hashing algorithm from 1986, you can make the client take an extra 40 milliseconds to process the packets” ”CVE 9.9 resource exhaustion DDoS confirmed”
- ilyt 3y ago
  That's CVEs in general it seems "if you set input parameters of curl to absolute nonsense, something bad will happen" 9.8/10 https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-everything-that-is-wrong-with-cves/ https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-eve... https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/ https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/
maccard 3y ago
Is it really? Those applications are very unlikely to even be getting security updates at this point.

fh973 3y ago

Who is OpenSSL and why do they sell expensive support contracts? It sounds like 1.1.1 is only EOL if you don't pay.

kstrauser 3y ago
Isn't that almost always the case with FOSS projects? For instance, throw enough money at Red Hat and I bet they'd support anything you'd like for as long as you'd want.
- fh973 3y ago
  No, not at all ! It can only be the case of the maintaining entity is the one that sells support. That's actually the definition of commercial software! It may be the case for company-backed FOSS projects (that use FOSS as a marketing channel and have a business model around it). You might be used to that because Redhat, Elastic, Mongo, ... But for very large number of FOSS projects, that's not the case. Either there is no paid support, or it is done by a third-party. But then this third party doesn't call the shots what's deprecated and what's backported where. I was under the impression that OpenSSL is a community project, and now it appears that that's not the case.
aaomidi 3y ago
OpenSSL is the dependency for doing TLS and a lot more. It’s effectively one of the only options. Crypto is hard, and crypto in C is fucking awful. Hence the pricing.
- dharmab 3y ago
  BoringSSL, wolfSSL, LibreSSL, not to mention the various FIPS options.
  - aaronmdjones 3y ago
    ARM mbedTLS is one of my favourites. Excellent documentation.
  - 3y ago

EustassKid 3y ago

I don't know about other Linux distributions (or operating systems) but a while ago NixOS marked Sublime Text as insecure and wouldn't let me install it without me setting the option to allow insecure packages (since it depends on openssl 1.1.1u), I don't know how dangerous it would be to have software with an out of date TLS library for me, a regular user, but I just switched to emacs, so sad because ST is an excellent editor, a great set of features and plugins while still being extremely fast (which is my problem with VSCode).

iotku 3y ago
I briefly looked into it (from the same NixOS issues), there's a GitHub issue somewhere about it [1] Effectively as I recall it a large amount of Sublime Text plugins internally rely on an old version of Python (3.3) which in turn relies on OpenSSL 1.1.1, there is concern that forcing the python version to something newer will largely break their plugin ecosystem as a lot of the plugins are expecting Python 3.3 and may not be compatible with 3.8 or later versions with supported OpenSSL. It's probably not a major security risk unless the plugins are making network connections, but it is an unfortunate situation. Edit: [1] https://github.com/sublimehq/sublime_text/issues/5984 https://github.com/sublimehq/sublime_text/issues/5984
- deleted 3y ago
  [deleted]
- MatthiasPortzel 3y ago
  The thing that frustrates me about Sublime’s position is this (from that link): > With most packages being no longer maintained there's little chance to get that file into existing repos. So you can’t break backwards compatibility because “most packages” aren’t maintained. But that means those packages are no longer receiving bug fixes. As a new Sublime Text user (within the last year), the package situation is definitely frustrating. There seems to be a lot of pride within the Sublime staff and core volunteer group, some of which is deserved, Sublime is an amazing editor. But at some point they’re going to have to admit that the current set of packages isn’t perfect and deprecate a bunch of them.

_V_ 3y ago

This unfortunately already completely broke Gentoo for the moment :-( Maintainers masked openssl-1.1.1 but there is currently a ton of packages with (sometimes needlessly) hardcoded requirement for old openssl. Including things like Rust etc. This will be painful.

ilyt 3y ago
I'm surprised! That gentoo is still alive. But being behind Debian Stable on up to date packaging doesn't look great...
- terinjokes 3y ago
  I use Gentoo on a few machines, and I'm confused by what GP says: I have no problems using OpenSSL 3, and the 1.1 releases have been masked (not installable by default) for a while now.
  - _V_ 3y ago
    I'm talking about this: The following mask changes are necessary to proceed: (see "package.unmask" in the portage(5) man page for more details) # required by net-libs/nodejs-20.5.1::gentoo # required by www-client/firefox-102.15.0::gentoo # required by @selected # required by @world (argument) =dev-libs/openssl-1.1.1v And many many many more packages. I went through like 20 yesterday and created custom ebuilds without mentions to slot :0= in ebuild, but there is plenty more.
    - terinjokes 3y ago
      Something seems unusual about your system. Are you using an unusual profile or heavily customized make.conf? net-libs/nodejs-20.5.1 is satisfied with dev-libs/openssl-3.0.10 out of the box here. I have a fully updated world with a KDE desktop, and don't have OpenSSL 1.1 installed at all.
      - _V_ 3y ago

bazzargh 3y ago

OpenSSL 3 seems to be largely compatible (it's a much easier upgrade than previous big ones) but the part of this that breaks clients is odd. If your peer closes the connection without sending close_notify, you get an unexpected EOF; 1.1.1 ignored this, 3 passes the error to the client, which needs to set SSL_OP_IGNORE_UNEXPECTED_EOF to recover the old behaviour - but this is only safe as long as the client checks for truncation attacks. This peer behaviour seems to be pretty common for google servers, so if you use google logins or APIs it'll trip you up (from doing these upgrades at work, almost all of the errors I saw were talking to google) What's odd to me is most of the patches I saw for this were just setting that flag, and not doing anything about truncation attacks? I'm sure this will bite us all somewhere down the line. Anyway, some notes for admins of old systems who got to this too late: It was noticeable that this patch got backported into ppa's that maintain old/deprecated versions of some software. eg the ondrej php ppa has this backported to EOL'd versions of php. But, this is not the case for the python deadsnakes ppa - I didn't look at python 3.8, but 3.9 was fixed at source, and it hasn't been backported to the (EOL'd) 3.7 anywhere. You should be off 3.7 anyway, but if you're not, it's now urgent. Another notable backport is openresty. If you're using nginx with lua and oauth, it's a popular choice; but lags the latest nginx by a long way. The latest version is 1.21.4.2 which means it's based on nginx 1.21; but nginx is on 1.25 and nginx only released with openssl 3 support in 1.22. If you proxy to https servers, this is a concern. However, digging I found the openssl3 support was backported to openresty a few months ago, so the _current_ version does work without falling over.

planede 3y ago
So was the truncation attack already there in 1.1.1? I think it's OK for a patch that changes the dependency to 3 to just retain existing behavior. Addressing the problematic behavior should be a distinct patch.
- bazzargh 3y ago
  Yes, the fix for the truncation attack was originally rolled into 1.1.1e (March 2020) and then withdrawn in 1.1.1f because the new errors were too disruptive; IIRC the fix was already in the 3.x prereleases by that stage. So effectively if you stuck on 1.1.1, you've been living with this risk for 3 years. The truncation attack is one where the client thinks their ssl session has ended but a malicious actor prevents the session from ending correctly; the threat is something like, after doing this your gmail can be messed with even tho you think you've logged out. From the descriptions it seems like you'd need to layer it with another attack or two to do anything useful with it. It's not something that keeps me awake at night. When I dug into the python code we had hitting this a few months back (python 3.7 on recent ubuntu) it appeared that the error would not only trip up a client expecting to use 1.1.1 but could mean the last buffer read from the socket was not flushed (so, you can't just catch the error in python and assume it's ok because the other end had closed the connection anyway - you're missing some of the response). I wasn't certain but that possibility was a big bucket of NOPE for me, far easier to tell people to get the upgrade done and stop using software that had been built against 1.1.1.

jmclnx 3y ago

Interesting, you can purchase support for 1.1.1x between 15,000 -- 50,000 USD per year. I can see some large Companies in panic mode now, so the option exists for them to continue with older versions. This explains why NetBSD 10.0 people are holding the release until they get the new version working in Base and pkgsrc. https://www.openssl.org/support/contracts.html#premium https://www.openssl.org/support/contracts.html#premium

tempay 3y ago
Can you get support for 15k? My reading of that page is that extended support is only for the top 50k a year package. Though in reality RedHat and others will keep OpenSSL 1.1.1 patched for quite a while yet.
teh_klev 3y ago
> Interesting, you can purchase support for 1.1.1x between 15,000 -- 50,000 USD per year. Nitpick, from the announcement, only the Premium contract ($50K per year) provides for extended 1.1.1 support: Another option is to purchase a premium support contract which offers extended support (i.e. ongoing access to security fixes) for 1.1.1 beyond its public EOL date. There is no defined end date for this extended support and we intend to continue to provide it for as long as it remains commercially viable for us to do so (i.e. for the foreseeable future).
sabareesh 3y ago
why not use libressl

Sytten 3y ago

I imagine there is a clause in the support contract that prevents the disclosure of source code? I am wondering if we will need a community supported fork. I have said it for months that this transition will be a mess, so many distribution LTS and packages are built for 1.1.1

cracauer 3y ago

The FreeBSD experience with the upgrade also shows that this is not a smooth enforced upgrade.