[openssl-users] Response from server is lost on close

Michael Wojcik Michael.Wojcik at microfocus.com
Wed Dec 9 14:19:31 UTC 2015


(Sorry for the delay in replying - I was tied up with other things.)

Yes, you're correct. I was misremembering, and should have checked references first.

The BSD implementation that Gary Wright and Rich Stevens describe in TCP/IP Illustrated v. 2 drops queued outbound data (on both sides) and queued out-of-order segments waiting for reassembly on the receiving side when an RST is received. But it doesn't appear to drop queued in-order, ACK'd data.

And I think that's the correct behavior. If the side that receives the RST has ACK'd some data, then it should hang onto that data for the application to receive it. It should only report the error (ECONNRESET) when the application has successfully read the queued data.

So I suspect what you're seeing is OpenSSL behavior. It's likely reading ahead, seeing the ECONNRESET, and discarding the received data. But I haven't had a chance to look at the OpenSSL code in question.

In some cases OpenSSL will have to read ahead. It needs to receive the complete SSL/TLS/DTLS record before processing it, for example; and if that record is broken up into multiple TCP segments (because the path MTU is smaller than the record size) then it could have a partial record when it receives the RST. I can't tell if that situation is present in your case (without manually decoding the tcpdump trace, which I don't have time to do at the moment).

Michael Wojcik
Technology Specialist, Micro Focus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151209/c5657f0f/attachment.html>


More information about the openssl-users mailing list