Skip to content

OpenSSL 3: Support of SSL_OP_IGNORE_UNEXPECTED_EOF context option #8369

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nrueckmann opened this issue Apr 14, 2022 · 23 comments
Closed

OpenSSL 3: Support of SSL_OP_IGNORE_UNEXPECTED_EOF context option #8369

nrueckmann opened this issue Apr 14, 2022 · 23 comments

Comments

@nrueckmann
Copy link

Description

OpenSSL became more strict about unexpected EOF (not sending close notify) in 1.1.1e but reverted that change in 1.1.1f due to the huge amount of non-compliant servers. With the new major release 3.0.0 it came back. See openssl/openssl#11378 for more details.

Unfortunately, the situation of non-compliant servers did not change. And with OpenSSL 3 being the default version of Ubuntu 22.04 (and other distributions) the issue will raise more frequently.

I propose to add a new SSL context option ignore_unexpected_eof to set the SSL_OP_IGNORE_UNEXPECTED_EOF bit.

Documentation: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html#SSL_OP_IGNORE_UNEXPECTED_EOF

@nrueckmann
Copy link
Author

Example of an non-compliant server:

www-data@4e07da05c0ce:~/html$ php -r "echo file_get_contents('https://chromedriver.storage.googleapis.com/LATEST_RELEASE', false, stream_context_create());"
PHP Warning:  file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages:
error:0A000126:SSL routines::unexpected eof while reading in Command line code on line 1
PHP Warning:  file_get_contents(): SSL: Success in Command line code on line 1

@cmb69
Copy link
Member

cmb69 commented Apr 14, 2022

Yeah, this issue already came up as https://bugs.php.net/bug.php?id=79589, and needs to be addressed.

@bukka, thoughts?

@nrueckmann
Copy link
Author

Thank you for your response. Sorry for not checking bugs.php.net. I've only searched github for this issue.

@cmb69
Copy link
Member

cmb69 commented Apr 14, 2022

Sorry for not checking bugs.php.net.

That's totally fine. :)

@kocoten1992
Copy link

kocoten1992 commented Apr 27, 2022

upgraded to ubuntu 22.04 today and run into this error 👍

file_put_contents(): SSL operation failed with code 1. OpenSSL Error messages:  
  error:0A000126:SSL routines::unexpected eof while reading

@bukka
Copy link
Member

bukka commented Apr 28, 2022

I have got this quite high on my TODO list so hopefully it won't take me too long to pick this up. I think that flag might be the best option but it will also need a test which will be probably hardest part on this fix.

@bukka
Copy link
Member

bukka commented Apr 28, 2022

Although maybe not the best idea to always add that option as it can potentially lead to the truncation attack so we might just make it optional somehow. Will need to think about it when I get to it.

@nrueckmann
Copy link
Author

Although maybe not the best idea to always add that option as it can potentially lead to the truncation attack so we might just make it optional somehow. Will need to think about it when I get to it.

That's the feature request i've tried to describe. Having an option which can be (optionally) passed to the context. Same like we are doing with all other options (https://www.php.net/manual/en/context.ssl.php).

@pieterza
Copy link

We'd also like this fix please.

@batata004
Copy link

batata004 commented May 12, 2022

Me too, I would like this bug to be fixed. It's pretty annoying. BTW, the temporary fix changing the openssl.cnf file does not work on Centos, only on certain Ubuntu (some people even on Ubuntu are facing this problem using the fix suggested).

@pieterza
Copy link

pieterza commented May 12, 2022

Me too, I would like this bug to be fixed. It's pretty annoying. BTW, the temporary fix changing the openssl.cnf file does not work on Centos, only on Ubuntu

Hehe.

That workaround did not work for me on Ubuntu 22.04 either...

Easy way to test:

php -r "echo file_get_contents('https://chromedriver.storage.googleapis.com/LATEST_RELEASE', false, stream_context_create());"

Returns:

file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages:
error:0A000126:SSL routines::unexpected eof while reading

@batata004
Copy link

Me too, I would like this bug to be fixed. It's pretty annoying. BTW, the temporary fix changing the openssl.cnf file does not work on Centos, only on Ubuntu

Hehe.

That workaround did not work for me on Ubuntu 22.04 either...

Easy way to test:

php -r "echo file_get_contents('https://chromedriver.storage.googleapis.com/LATEST_RELEASE', false, stream_context_create());"

Returns:

file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages:
error:0A000126:SSL routines::unexpected eof while reading

Sorry, I edited my comment. Indeed, the fix suggested does not work for all people on Ubuntu, some people are reporting the fix does not work at all on Ubuntu (on Centos I cant find a single person that made the fix work).

@bukka
Copy link
Member

bukka commented May 12, 2022

I will prioritise this and will start looking into it in the next few days.

@bukka
Copy link
Member

bukka commented May 13, 2022

So I just checked what Python does and they added the flag by default: python/cpython@6f37ebc . Also same for nginx https://hg.nginx.org/nginx/rev/1a03af395f44 .

Considering our users and the amount of non complaint server I tend to think that we should do the same at least for 8.1 and maybe few more other versions so we also have it consistent between supported OpenSSL versions.

@pieterza
Copy link

pieterza commented May 14, 2022

So I just checked what Python does and they added the flag by default: python/cpython@6f37ebc . Also same for nginx https://hg.nginx.org/nginx/rev/1a03af395f44 .

Considering our users and the amount of non complaint server I tend to think that we should do the same at least for 8.1 and maybe few more other versions so we also have it consistent between supported OpenSSL versions.

Great news!
May I request it also at least being something we can toggle for 8.0, or target 8.0 as default ?🙏

bukka added a commit to bukka/php-src that referenced this issue May 15, 2022
The unexpected EOF failure was introduced in OpenSSL 3.0 to prevent
truncation attack. However there are many non complaint servers and
it is causing break for many users including those where truncation
attack is not an issue becuase it would break format parsing (e.g.
JSON). we try to keep behavior consitent with older version which
is also the path chosen by some other languages and web servers.

Closes phpGH-8369
@bukka
Copy link
Member

bukka commented May 15, 2022

May I request it also at least being something we can toggle for 8.0, or target 8.0 as default ?

PHP 8.0 does not support OpenSSL 3.0 so it's not applicable there.

@bukka
Copy link
Member

bukka commented May 15, 2022

The fix is in #8558

bukka added a commit to bukka/php-src that referenced this issue May 15, 2022
The unexpected EOF failure was introduced in OpenSSL 3.0 to prevent
truncation attack. However there are many non complaint servers and
it is causing break for many users including potential majority
of those where the truncation attack is not applicable. For that reason
we try to keep behavior consitent with older OpenSSL versions which is
also the path chosen by some other languages and web servers.

Closes phpGH-8369
@bukka
Copy link
Member

bukka commented May 15, 2022

I have been also thinking about the truncation attack in our context and think it's not likely applicable to majority of the use cases. Even though I think that secure by default is what we should do, this might be an exception to this rule considering the amount of non complaint servers, problems this caused and potentially small attack vector. Therefore I think we could later just introduce an option in master to explicitly enable failure on missing close notify rather than thinking to re-enable this again by default.

@SoftCreatR
Copy link

May I request it also at least being something we can toggle for 8.0, or target 8.0 as default ?

PHP 8.0 does not support OpenSSL 3.0 so it's not applicable there.

But it works fine (except for the problem discussed here).

@bukka
Copy link
Member

bukka commented May 15, 2022

It's probably patched by distro because PHP-8.0 branch doesn't even compile with OpenSSL 3.0.

@codgunt
Copy link

codgunt commented Jun 9, 2022

Just wanting to note for anyone that is like me waiting on the fix, that theoretically this will be showing up in distros shortly as it is included in PHP 8.1.7:

https://www.php.net/ChangeLog-8.php#8.1.7

Older versions though will probably need manual patching.

@batata004
Copy link

Thank you! I already updated twice my PHP version and the bug is still present. Hope on the next relase it gets fixed.

@datenfalke
Copy link

Working again on my Kubuntu 22.04 development system running PHP 7.4 using a reCaptcha widget for login which failed before.

markstory added a commit to cakephp/cakephp that referenced this issue Jul 25, 2022
Ubuntu 22.04 comes with OpenSSL 3, and the specific version that PHP is
built against has a bug which has since been fixed but isn't showing up
in the images that GitHub has available.

See openssl/openssl#18574
and php/php-src#8369
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants