New decode_errors due to EOF changes in master and 1.1.1e

[John Baldwin]

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