New decode_errors due to EOF changes in master and 1.1.1e

[Matt Caswell]

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().
>