openssl: ssl3_read_n:unexpected eof while reading while keepalive
Hey openssl team,
I’m using archlinux with nginx-mainline and php-fpm with all packages up-to-date.
After upgrading to openssl 1.1.1.e we see the following error happening over and over again.
nginx[11287]: 2020/03/20 23:35:38 [crit] 11287#11287: *64 SSL_read() failed (SSL: error:14095126:SSL routines:ssl3_read_n:unexpected eof while reading) while keepalive, client: x.x.x.x, server: 0.0.0.0:443
I don’t know if this is something that needs to be fixed in openssl, in nginx (or perhaps only a setting) or in the webapps used.
Unfortunately there are no other entries in the logs. I don’t know if that helps in any way but I don’t even use ssl3 in nginx, only tlsv1.2.
Downgrading to openssl 1.1.1.d solves the issue. I guess it is related to this.
Thanks for any help in advance.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 16 (6 by maintainers)
Commits related to this issue
- openssl: update to 1.1.1e This version includes bug and security fixes, including medium-severity CVE-2019-1551, affecting RSA1024, RSA1536, DSA1024 & DH512 on x86_64. Signed-off-by: Eneas U de Quei... — committed to openwrt/openwrt by cotequeiroz 4 years ago
- SSL: use of the SSL_OP_IGNORE_UNEXPECTED_EOF option. A new behaviour was introduced in OpenSSL 1.1.1e, when a peer does not send close_notify before closing the connection. Previously, it was to ret... — committed to nginx/nginx by pluknet 3 years ago
- SSL: use of the SSL_OP_IGNORE_UNEXPECTED_EOF option. A new behaviour was introduced in OpenSSL 1.1.1e, when a peer does not send close_notify before closing the connection. Previously, it was to ret... — committed to diogoaos/nginx by pluknet 3 years ago
- SSL: use of the SSL_OP_IGNORE_UNEXPECTED_EOF option. A new behaviour was introduced in OpenSSL 1.1.1e, when a peer does not send close_notify before closing the connection. Previously, it was to ret... — committed to nginx/nginx by pluknet 3 years ago
- Using SSL_OP_IGNORE_UNEXPECTED_EOF. A new behaviour was introduced in OpenSSL 1.1.1e, when a peer does not send close_notify before closing the connection. Previously, it was to return SSL_ERROR_SYS... — committed to nginx/unit by pluknet 2 years ago
- SSL: use of the SSL_OP_IGNORE_UNEXPECTED_EOF option. A new behaviour was introduced in OpenSSL 1.1.1e, when a peer does not send close_notify before closing the connection. Previously, it was to ret... — committed to sebres/nginx by pluknet 3 years ago
- SSL: use of the SSL_OP_IGNORE_UNEXPECTED_EOF option. A new behaviour was introduced in OpenSSL 1.1.1e, when a peer does not send close_notify before closing the connection. Previously, it was to ret... — committed to grumpylabs/freenginx by pluknet 3 years ago
One of the properties SSL/TLS provides is that you can be sure everything has been received, and that an attacker didn’t terminate the connection. This is done by sending the close notify, to confirm that you have sent everything. Not all protocols need this, the protocol itself might also know when all the communication is done, or the data that was sent over the protocol might indicate that everything was received. As far as I know, there are cases in HTTP 1.1 where it’s not clear at the HTTP level that everything was sent or not, but with HTTP 2 it should always be clear.
So you get that error when at the TLS layer we detect an EOF, but the close notify was not received. This means that for TLS something went wrong. The application called SSL_read(), but there was neither data nor a close notify. This means the application was still expecting data, but we can’t return it, so we need to return an error.
So in case of a peer that does not properly send you the close notify, you can only work around this by not calling SSL_read() when you’re sure all data was received. And I strongly suggest you fix the peer that does not send the close notify.
It probably means the client is not sending a close notify like it should. See also my comment in #11378.
I’ve ran through the nginx code to determine what happens after each such event and found they are all ‘terminated’ on such EOF detection in 1.1.1e (default nginx behavior). This settles my concerns about a possible vulnerability (there isn’t any).
Fixing peers is out of server control so in this case we need to patch servers or accept much larger logfiles than normal. A second patch concept can be found on the nginx forum.
https://forum.nginx.org/read.php?2,287377 Which includes a (dirty) workaround. There are other entries logged as well related to this issue.
Concern: https://github.com/openssl/openssl/issues/11378 “If we do not return an error, you might be vulnerable to a truncation attack.” ??