openssl 3.0.2 backport IgnoreUnexpectedEOF ssl config option from 3.2

Thanks for the report. I am reluctant to backport this as I'm not sure it makes a lot of sense system-wide. Curl upstream didn't seem happy with enabling this work-around even in 2021. It seems the reason to integrate this would be to be able to ignore this despite curl not ignoring it nor offering a way to ignore it.

I also don't like that it's the kind of configuration that will linger on systems for years, if not decades. For the distribution, this also means that once the patch is in, it needs to be supported for 15 years. On the other hand, it will get in after 24.04/Noble is released since upstream merged it...

Still, I can't make a compelling case in favor of this patch. This is especially troublesome since a change to released versions needs exactly that.

Which servers are you experiencing this issue with?

The attachment "Add IgnoreUnexpectedEOF as configuration option for 3.0.2-0ubuntu1.15" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Hi Adrien, this is some corporate setup with Zscaler proxy and nginx servers or reverse-proxies inbetween. I cannot say for sure how exactly the servers are setup. The patch just adds the possiblity to set the IgnoreUnexpectedEOF option to the config file by user. The config file itself I would not recommend to change system-wide in the distro package, indeed.

I am not in control to update the nginx servers to 1.22 which fixes that known issue on the servers side.

And, although I have patched openssl package locally with the attached patch and added the option to /etc/ssl/openssl.cnf, I still see the very same error. I wonder what else could be wrong ... Do I have to put the Options entry in another section of the config file?

If I find something I will post again.

Thanks for continued investigation.

A reproducer would be valuable as it would allow me to verify
independently the patch is effective, within the limits of the
understanding of the situation of course and that can be especially
time-consuming when not having access to the remote server. :/
A reproducer here can be along the lines of install ubuntu foo to get
nginx bar, configure nginx with TLS and baz and use a given curl
command.
Right now it's difficult to say if you're missing something since I
can't test by myself and compare.
A reproducer is also going to be a required proof in practice for the
change to be done in any past release.

Timeline-wise, either this change gets into 24.04 which is entering
Feature Freeze today, or it will wait for the development cycle of 24.10
when openssl is updated to >= 3.2 (probably 3.3). Then only will it be
possible to also backport this to 22.04 which I guess is the release you
are interested in.

Actually, it seems that most programs ignore the openssl.cnf anyway for security(?) reasons. Played a bit with MinTlsVersion and it did not change the request which is being sent. Luckily I could ask the DevOps for the nginx versions used and they have versions with the openssl 3 fix; that comes with nginx 1.21.2. Maybe there is a firewall setting causing this. Would not be the first time, hah... I will see.

But anwyay, as the openssl.cnf is ignored anyway this report is quite invalid - does not help. :-D

-- That error message has sent me on a journey, o dear.

There are several reasons a program can skip loading the openssl configuration unfortunately: env vars pointing to another file, apparmor preventing loading, library initilization skipping it, ...

Is the program that ignores the openssl configuration file in the Ubuntu archive? Or public?

Right, that was with curl and wget from Ubuntu archive. I got some documentation finally, to set up the corporate client and the ssl connection works basically.