This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Dima.Tisnek
Recipients Dima.Tisnek
Date 2020-03-13.03:40:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1584070801.03.0.867475481059.issue39951@roundup.psfhosted.org>
In-reply-to
Content
When a connection wrapped in ssl is closed, sometimes the ssl library reports an error, which I believe should be ignored.

The error code is `291` and the name of the error is either SSL_R_KRB5_S_INIT (KRB5_S_INIT) or SSL_R_APPLICATION_DATA_AFTER_CLOSE_NOTIFY depending on openssl header file.
It's only one code, somehow `ssl.h` (depending on version?) has different symbolic name for the error.
TBH, I consider `KRB5_S_INIT` a misnomer, there's no Kerberos here.

The explanation for openssl reporting this error is here:

https://github.com/openssl/openssl/blob/6d53ad6b5cf726d92860e973d7bc8c1930762086/ssl/record/rec_layer_s3.c#L1657-L1668

> The peer is continuing to send application data, but we have
> already sent close_notify. If this was expected we should have
> been called via SSL_read() and this would have been handled
> above.

This situation is easily achieved, because of network delays. Just because we sent "close notify", doesn't mean the other end has received it, and even if it did, there could still be return data in flight.

Reproducer is here: https://gist.github.com/dimaqq/087c66dd7b4a85a669a00221dc3792ea
History
Date User Action Args
2020-03-13 03:40:01Dima.Tisneksetrecipients: + Dima.Tisnek
2020-03-13 03:40:01Dima.Tisneksetmessageid: <1584070801.03.0.867475481059.issue39951@roundup.psfhosted.org>
2020-03-13 03:40:00Dima.Tisneklinkissue39951 messages
2020-03-13 03:40:00Dima.Tisnekcreate