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.
> 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.
It sounds like those are workarounds to get the apps to work again by reintroducing the old behavior. Once they are unblocked, they can refocus on addressing the issue.
It's either that, or remain broken and unusable until further notice.
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.
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).
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.
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.
If anyone is getting the same results as me where you could not run emerge world --deep because random already installed packages pulled back the openssl-1.1.1, you can use following command:
emerge -DavuUN @world @system --changed-deps
This should recalculate all the dependencies from scratch, not using (possibly) cached openssl-1.1.1 allowing you to run abovementioned emerge without problems :-)
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.
> 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).
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.
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
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
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".
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”
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
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.
[+] [-] bazzargh|2 years ago|reply
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.
[+] [-] rewmie|2 years ago|reply
It sounds like those are workarounds to get the apps to work again by reintroducing the old behavior. Once they are unblocked, they can refocus on addressing the issue.
It's either that, or remain broken and unusable until further notice.
[+] [-] planede|2 years ago|reply
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.
[+] [-] EustassKid|2 years ago|reply
[+] [-] iotku|2 years ago|reply
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
[+] [-] _V_|2 years ago|reply
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.
[+] [-] _V_|2 years ago|reply
emerge -DavuUN @world @system --changed-deps
This should recalculate all the dependencies from scratch, not using (possibly) cached openssl-1.1.1 allowing you to run abovementioned emerge without problems :-)
[+] [-] ilyt|2 years ago|reply
But being behind Debian Stable on up to date packaging doesn't look great...
[+] [-] jmclnx|2 years ago|reply
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
[+] [-] teh_klev|2 years ago|reply
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).
[+] [-] tempay|2 years ago|reply
[+] [-] sabareesh|2 years ago|reply
[+] [-] Sytten|2 years ago|reply
[+] [-] Brananarchy|2 years ago|reply
[+] [-] TheDong|2 years ago|reply
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".
[+] [-] nikanj|2 years ago|reply
”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”
[+] [-] rurban|2 years ago|reply
The biggest change were outdated RC4, which was a good thing to get rid of this cruft
[+] [-] userbinator|2 years ago|reply
[+] [-] maccard|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] cracauer|2 years ago|reply
[+] [-] 1vuio0pswjnm7|2 years ago|reply
[+] [-] ComputerGuru|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] fh973|2 years ago|reply
It sounds like 1.1.1 is only EOL if you don't pay.
[+] [-] kstrauser|2 years ago|reply
[+] [-] aaomidi|2 years ago|reply
Crypto is hard, and crypto in C is fucking awful. Hence the pricing.