RE: RST after close_notify
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: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Donald J. > Sent: Monday, 11 August, 2014 13:14 > To: openssl-users@openssl.org > 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. &g
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... 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. 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. 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. 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. dona...@4email.net 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: RST after close_notify
API calls. (I also don't know where this trace came from - if it's coming from the stack, or a wire trace, or what. I don't recognize the format.) And in any case, waiting for a FIN wouldn't help with the failing case. The FIN just means the other side is saying it won't send any more data. In the second trace, on the other hand, the server *might* have explicitly aborted the conversation, which would explain why we see an RST and no FIN. That would be poor behavior, but certainly not unheard of; many people who can't be bothered to learn how to use TCP write programs with it anyway. Or it might have done something strange, like half-close the receiving side of the conversation, but not the sending side. Or it might have done a normal close, but the FIN doesn't show up in the trace for timing reasons. But I suspect the RST was generated because the server closed the conversation normally without reading all the data the stack had already received from the client. That will cause an RST immediately, to let the client side know that not all the data it sent was processed by the application. The data in question might have been from the packet immediately preceding the close_notify from the server, or from the one after it, which could have arrived between the time the server sent its close-notify and when it called the API to close its end of the conversation. (The Winsock API actually recommends using a half-close followed by receiving and discarding data until the peer's half-close is received, to prevent this very condition. But again, few people bother to learn TCP or the sockets API before trying to use them.) And *this* is why Rescorla's book says "sometimes you'll get an RST, so deal with it". There are a lot of conditions where an RST can occur. TLS adds an application-level conversation protocol (the close_notify fault) on top of TCP's conversation protocol so that you'll know whether the peer was done sending data. What you won't know is whether it processed all of your data, so if you care, you have to add another application-level protocol on top of TLS if you need that guarantee. (In this case, FTP will supply that, in the form of its response messages.) So I don't see a simple solution to your problem. I'd be tempted to wrap the FTP client in another program and filter out the failing return code if I've received the server's response message to my last command. I don't remember off the top of my head whether there's a straightforward FTP API on zOS. -- Michael Wojcik Technology Specialist, Micro Focus > -Original Message- > From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Donald J. > Sent: Friday, 08 August, 2014 22:11 > To: openssl-users@openssl.org > Subject: Re: RST after close_notify > > The FTP client is a batch mainframe process which > must get return code zero, or someone gets called > in the middle of the night. I have been working > with IBM support which claims that the server should > return a Fin before Rst. So I will probably turn this > problem over to our PC server group. > > I don't really understand why in the successful sequence, > the client sends "Ack PSh" and waits to receive the > "Ack Fin" before sending the close_notify. But in the > failing sequence the client sends "Ack Psh", then > immediately sends lose_notify without any waiting. > > If the server is closing its connection after sending the > close_notify, it probably wouldn't send the "Ack Fin" in > the successful sequence? > > I guess IBM is saying the server should send "Ack Fin", > wait for Ack from client, and server then would send > the "AckRst"? > > -- > Donald J. > dona...@4email.net > > On Fri, Aug 8, 2014, at 02:03 PM, Michael Wojcik wrote: > > > -Original Message- > > > From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > > > us...@openssl.org] On Behalf Of Donald J. > > > Sent: Friday, 08 August, 2014 15:34 > > > To: openssl-users@openssl.org > > > Subject: RST after close_notify > > > > > > I have an issue with an FTP client issuing a DIR command to a Windows > > > FTP server. > > > A normal packet trace is shown in sequence 1 below. An "Ack Fin" is > > > received > > > from the Windows FTP server and the DIR command completes successfully. > > > > Both of your traces below show an RST in the final packet, not a FIN. > > > > > > > In the 2nd sequence, each side exchanges close_notify, but no "Fin" > > > flags are set. > > > Windows F
Re: RST after close_notify
The FTP client is a batch mainframe process which must get return code zero, or someone gets called in the middle of the night. I have been working with IBM support which claims that the server should return a Fin before Rst. So I will probably turn this problem over to our PC server group. I don't really understand why in the successful sequence, the client sends "Ack PSh" and waits to receive the "Ack Fin" before sending the close_notify. But in the failing sequence the client sends "Ack Psh", then immediately sends lose_notify without any waiting. If the server is closing its connection after sending the close_notify, it probably wouldn't send the "Ack Fin" in the successful sequence? I guess IBM is saying the server should send "Ack Fin", wait for Ack from client, and server then would send the "AckRst"? -- Donald J. dona...@4email.net On Fri, Aug 8, 2014, at 02:03 PM, Michael Wojcik wrote: > > -Original Message- > > From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > > us...@openssl.org] On Behalf Of Donald J. > > Sent: Friday, 08 August, 2014 15:34 > > To: openssl-users@openssl.org > > Subject: RST after close_notify > > > > I have an issue with an FTP client issuing a DIR command to a Windows > > FTP server. > > A normal packet trace is shown in sequence 1 below. An "Ack Fin" is > > received > > from the Windows FTP server and the DIR command completes successfully. > > Both of your traces below show an RST in the final packet, not a FIN. > > > > In the 2nd sequence, each side exchanges close_notify, but no "Fin" > > flags are set. > > Windows FTP server ends with an "Ack Rst". After receiving the Reset > > packet, > > the FTP client issues a "connection reset' message" and sets an error > > code. > > Is that the correct thing to do? > > Are you questioning the server's behavior, or the client's? > > Probably what happened is the server sent its close_notify and then > closed its end of the connection without waiting for the client's > close_notify response. See Eric Rescorla's /SSL and TLS/ book, 8.10, for > further discussion. This is unfriendly behavior by the server, in my > opinion, but common enough for Rescorla to discuss it. > > It's also possible the server did an abortive close, which would be the > Wrong Thing to do, but the former case is more likely. And in any event, > your client couldn't distinguish between the two. (And what would you do > about it anyway? If someone else's server behaves badly, you have to deal > with it in some fashion.) > > How the client handles receiving a RST (generally manifests as a return > code of -1 from send or recv, with errno set to ECONNRESET [1]; with > OpenSSL you should get SSL_ERROR_SYSCALL and check errno) is a matter of > taste. Often you do want to report that the connection was reset. In this > case, though, since a reset is not unexpected AND you know you've > received all the data from the server - you got its close_notify - it's > better to silently ignore it. > > In short, the logic should be something like this: > > if RST-received > if we were trying to send data > check for a close_notify from the peer > end-if > if close_notify not already recevied from peer > treat as failure > end-if > close socket and clean up > end-if > > > [1] This assumes the application, if it's running in a POSIX environment, > has set the disposition of the SIGPIPE signal to "ignore". SIGPIPE is a > kluge for applications that don't check the result of the write/send > family of system calls. Any well-written application should ignore it. > > > -- > Michael Wojcik > Technology Specialist, Micro Focus > > > > This message has been scanned for malware by Websense. www.websense.com > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org -- http://www.fastmail.fm - Same, same, but different... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: RST after close_notify
> -Original Message- > From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Donald J. > Sent: Friday, 08 August, 2014 15:34 > To: openssl-users@openssl.org > Subject: RST after close_notify > > I have an issue with an FTP client issuing a DIR command to a Windows > FTP server. > A normal packet trace is shown in sequence 1 below. An "Ack Fin" is > received > from the Windows FTP server and the DIR command completes successfully. Both of your traces below show an RST in the final packet, not a FIN. > In the 2nd sequence, each side exchanges close_notify, but no "Fin" > flags are set. > Windows FTP server ends with an "Ack Rst". After receiving the Reset > packet, > the FTP client issues a "connection reset' message" and sets an error > code. > Is that the correct thing to do? Are you questioning the server's behavior, or the client's? Probably what happened is the server sent its close_notify and then closed its end of the connection without waiting for the client's close_notify response. See Eric Rescorla's /SSL and TLS/ book, 8.10, for further discussion. This is unfriendly behavior by the server, in my opinion, but common enough for Rescorla to discuss it. It's also possible the server did an abortive close, which would be the Wrong Thing to do, but the former case is more likely. And in any event, your client couldn't distinguish between the two. (And what would you do about it anyway? If someone else's server behaves badly, you have to deal with it in some fashion.) How the client handles receiving a RST (generally manifests as a return code of -1 from send or recv, with errno set to ECONNRESET [1]; with OpenSSL you should get SSL_ERROR_SYSCALL and check errno) is a matter of taste. Often you do want to report that the connection was reset. In this case, though, since a reset is not unexpected AND you know you've received all the data from the server - you got its close_notify - it's better to silently ignore it. In short, the logic should be something like this: if RST-received if we were trying to send data check for a close_notify from the peer end-if if close_notify not already recevied from peer treat as failure end-if close socket and clean up end-if [1] This assumes the application, if it's running in a POSIX environment, has set the disposition of the SIGPIPE signal to "ignore". SIGPIPE is a kluge for applications that don't check the result of the write/send family of system calls. Any well-written application should ignore it. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
