The IBM response is still significantly oversimplified, where it isn't simply wrong.
I've made some comments in-line below, but to get the full picture you'd really need to study a text like Stevens' /TCP/IP Illustrated/, paying particular attention to the TCP state diagram and the empirical results Stevens sees in his experiments (and maybe do some experiments of your own to ferret out the quirks of the implementations you're using). You have to consider all the permutations of: - What the applications do (in terms of calling the API and responding to the returned values) - What the stacks do in response to the applications' actions, and what the state of the conversation is at the moment each action is processed - When various packets are sent and received That's a lot of combinatorial explosion. Vague, handwaving descriptions of what "TCP will normally" do aren't going to explain all the possible cases. And OpenSSL (like pretty much any middle layer) complicates the situation by hiding some information from you in its abstraction of the conversation, and doing things (like sending close_notify) that aren't apparent from the application level. If you control both sides of the conversation, you can ensure that close_notify exchanges never cause an RST flow, by sending the close_notify manually, performing a half-close, and then draining data until you receive the peer's half-close. But if you don't control both sides, then as Rescorla says, you have to be prepared to deal with a conversation abort. It's a bad iteraction between the SSL/TLS application-level handshaking and TCP's conversation-level handshaking, caused by people writing to the socket API without learning how to avoid abortive close. You have no choice in the matter but to follow Postel's interoperability principle and be liberal in what you accept. > -----Original Message----- > From: [email protected] [mailto:owner-openssl- > [email protected]] On Behalf Of Donald J. > Sent: Monday, 11 August, 2014 13:14 > To: [email protected] > Subject: Re: RST after close_notify > > The server end appears to be GlobalScape EFT running on a windows > server. > I will summarize the IBM response: > > When SSL is not involved, TCP will normally go through a graceful > connection teardown sequence where one side initiates the connection > closure by sending out a FIN. The other side acks that FIN and > sends out their own FIN... This is what happens regardless of whether SSL is involved, in the "normal" case (that is, the common case where one side does an active close, and the other side responds with a passive close, and all application data has been received by the applications, and the conversation is otherwise idle, and no intermediate nodes interfere, etc). The TLS close_notify flow is application data that is sent normally, as far as the TCP layer is concerned. It does not alter TCP close negotiation in the slightest. > When SSL is involved or when an application is implemented to end the > connection with a Reset (using SOLINGER), one side can send out a FIN > then the application immediately closes down its socket. Then > anything with data comes in after that results in a Reset coming out. > When the other side receives the Reset, their TCP immediately cleans > up that connection. Sigh. SSL has nothing to do with this; "when SSL is involved" is simply wrong. Using the SO_LINGER option to tell the stack to do an abortive close is only one way of generating an RST. Regardless of whether SSL is in use, or whether the peer has used SO_LINGER to tell the stack that it wants an abortive close when it closes its end, a FIN may (but doesn't necessarily) indicate that the application has closed its socket. And that's the order it usually happens in: the application closes its socket (which is a call to the sockets API, not an operation on the TCP conversation), and the stack responds by sending a FIN (and changing the state of the local conversation endpoint internally). > Using this SSL session as an example, the remote side sends out the > FIN. At this point, the application on the remote side seems to > have already closed down its socket. Yes, that's usually the case. > When we receive the FIN, SSL > layer still needs to send out the SSL alert. Therefore, we are not > sending out our FIN just yet because we're still waiting for the ack > for the FIN. That's wrong. There are various possibilities for the local side in this situation, but none of them are "waiting for the ack for the FIN", because the local side *received* the FIN. It will send an ACK for it, but nothing on the local side waits for that to happen. > The remote side then sends back the ack along with the > Reset. When we receive the Reset, we clean up the connection > without any further communication. > > -- > Donald J. > [email protected] > > On Sat, Aug 9, 2014, at 09:44 AM, Michael Wojcik wrote: > > Well, it sounds like someone needs to modify the client, then, if you > > want to use SSL/TLS. > > > > "should return a FIN before RST" is an oversimplification, and possibly > > incorrect, depending on what "should" means in this context. There is no > > simple explanation of this. > > ... > > > -- > http://www.fastmail.fm - Faster than the air-speed velocity of an > unladen european swallow > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [email protected] > Automated List Manager [email protected] This message has been scanned for malware by Websense. www.websense.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
