New decode_errors due to EOF changes in master and 1.1.1e
jhb at FreeBSD.org
Wed Mar 25 16:03:51 UTC 2020
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:
> 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.
> 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.
>> 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:
>>>>> ??? [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().
More information about the openssl-users