There is an ongoing discussion on this issue here: https://github.com/openssl/openssl/issues/11378 In the specific case of s_client/s_server this actually uncovered a bug in s_server, which is why you see the problem there. Matt On 24/03/2020 23:35, John Baldwin wrote: > I replied to the original commit on GH but haven't seen any responses so > thought I would follow up here as well. > > https://github.com/openssl/openssl/pull/10907 > > After this PR was merged, I am now getting what look like spurious errors > for a "normal" connection end. For example, if I run 'openssl s_client -msg' > against an 'openssl s_server -www' instance, I now get this error at the > end of the connection: > > .... > </pre></BODY></HTML> > >>>> ??? [length 0005] > 15 03 03 00 1a >>>> TLS 1.2, Alert [length 0002], fatal decode_error > 02 32 > 34370928640:error:14095126:SSL routines:ssl3_read_n:unexpected eof while reading:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:303: > > Note that unlike the description of the commit log, this is not a case of > terminating the connection early via Ctrl-C. In this case, the remote > end (server) has closed the connection normally after sending the requested > file. The client then gets EOF when trying to read another SSL record after > reading the last byte of the sent file. > > Is this the expected behavior? It sure gave me a head scratch as I first > noticed this after rebasing a branch adding KTLS RX support for FreeBSD, and I > thought it was a bug in my changes until I finally narrowed it back to this > commit. It seems a bit odd for a normal close to trigger an error instead of > a clean EOF back from SSL_read(). >
