Thanks. I'll try searching GH issues next time (or opening a new one?) rather than replying to a commit. On 3/25/20 2:37 AM, Matt Caswell wrote: > 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(). >> -- John Baldwin
