SSL/TCP Connection termination results in RST

SSL/TCP Connection termination results in RST
NewsGroups | Search | Tools
User Password
Register Now! Lost Password?
 comp.dcom.sys.cisco  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
SSL/TCP Connection termination results in RST Chandler Bing 06-05-2008
Posted by Chandler Bing on June 5, 2008, 3:06 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
My company is working with VeriFone and TSys to isolate issues we've
seen with SSL transactions. We're being told that once one side sends
a FIN, that terminates the entire conversation and indeed the other
side still has data to send and when it performs a PSH, it's ignored
and ultimately the connection is RST. I'm being told by both sides
that this is normal. I don't believe it is.

I have packet captures, but I'm not sure how to post them or share
them out.

NMFall 20%
Posted by News Reader on June 5, 2008, 8:13 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Chandler Bing wrote:
> My company is working with VeriFone and TSys to isolate issues we've
> seen with SSL transactions. We're being told that once one side sends
> a FIN, that terminates the entire conversation and indeed the other
> side still has data to send and when it performs a PSH, it's ignored
> and ultimately the connection is RST. I'm being told by both sides
> that this is normal. I don't believe it is.
>
> I have packet captures, but I'm not sure how to post them or share
> them out.

My belief is as follows:

A TCP connection is duplex; with an independent stream in each
direction. When one side has no more data to send it can close its half
of the duplex connection.

When a Sender finishes sending its data, it waits for an ACK from the
Receiver, and then may send a FIN segment to close its half of the
connection. The Receiver would ACK the FIN segment, and inform the local
application that no more data will be forthcoming. The Receiver would
not respond immediately with a FIN segment, but would instead wait for a
response from the local application. Prior to receiving a response from
the local application, data should be able to flow on the non-closed
side of the duplex connection, if there is data to send.

When the local application responds with the authorization to shutdown
the 2nd half of the duplex connection, a FIN segment is sent to the
other side. That FIN segment will be ACK'd ending the four-way handshake.

I think a RST is used to close/abort transfers in both directions, and
occurs under abnormal conditions.

That's about all I can offer.

Best Regards,
News Reader

Posted by Thrill5 on June 7, 2008, 12:59 am
If you were  Registered and logged in, you could reply and use other advanced thread options
A "FIN" means that the connection is being terminated . TCP is full
duplex, but it's one connection. Once a FIN is sent or received, no more
data can be sent or received over that connection. From a protocol level,
the behavior is normal, but the question should be why is the FIN being sent
in the first place? If the connection is being terminated by one side, and
the other needs to send more data, why isn't that side initiating another
TCP connection?


> Chandler Bing wrote:
>> My company is working with VeriFone and TSys to isolate issues we've
>> seen with SSL transactions. We're being told that once one side sends
>> a FIN, that terminates the entire conversation and indeed the other
>> side still has data to send and when it performs a PSH, it's ignored
>> and ultimately the connection is RST. I'm being told by both sides
>> that this is normal. I don't believe it is.
>>
>> I have packet captures, but I'm not sure how to post them or share
>> them out.
>
> My belief is as follows:
>
> A TCP connection is duplex; with an independent stream in each direction.
> When one side has no more data to send it can close its half of the duplex
> connection.
>
> When a Sender finishes sending its data, it waits for an ACK from the
> Receiver, and then may send a FIN segment to close its half of the
> connection. The Receiver would ACK the FIN segment, and inform the local
> application that no more data will be forthcoming. The Receiver would not
> respond immediately with a FIN segment, but would instead wait for a
> response from the local application. Prior to receiving a response from
> the local application, data should be able to flow on the non-closed side
> of the duplex connection, if there is data to send.
>
> When the local application responds with the authorization to shutdown the
> 2nd half of the duplex connection, a FIN segment is sent to the other
> side. That FIN segment will be ACK'd ending the four-way handshake.
>
> I think a RST is used to close/abort transfers in both directions, and
> occurs under abnormal conditions.
>
> That's about all I can offer.
>
> Best Regards,
> News Reader



Posted by Barry Margolin on June 7, 2008, 10:55 am
If you were  Registered and logged in, you could reply and use other advanced thread options

> A "FIN" means that the connection is being terminated . TCP is full
> duplex, but it's one connection. Once a FIN is sent or received, no more
> data can be sent or received over that connection.

Incorrect. A FIN means "I'm not going to send any more", it doesn't
mean "I don't want to receive any more". TCP doesn't have any way to
indicate the latter (other than after the fact, by responding to new
data with an RST).

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Posted by Chandler Bing on June 9, 2008, 4:37 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
>
> > A "FIN" means that the connection is being terminated . =A0 TCP is full
> > duplex, but it's one connection. =A0Once a FIN is sent or received, no m=
ore
> > data can be sent or received over that connection.
>
> Incorrect. =A0A FIN means "I'm not going to send any more", it doesn't
> mean "I don't want to receive any more". =A0TCP doesn't have any way to
> indicate the latter (other than after the fact, by responding to new
> data with an RST).
>
> --
> Barry Margolin, bar...@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***
> *** PLEASE don't copy me on replies, I'll read them in the group ***

So any good advice that would tell the vendor to STFU?

Chandler Bing

Similar ThreadsPosted
Odd FTP results ??! August 17, 2004, 11:15 am
Why do I get these traceroute results? September 28, 2006, 8:35 am
PIX VPN termination September 2, 2005, 8:32 am
Replacing pix515 with ASA5510 results into MTU problems. May 10, 2006, 9:28 am
VPN termination IP address January 8, 2006, 1:24 pm
VPN termination on routers. January 31, 2006, 4:58 am
1602R w/ both Watchguard and Netgear results in incomplete MAC address July 20, 2006, 9:34 am
Cisco PIX VPN Passthrough and Termination November 21, 2006, 3:11 pm
termination reason 412 with cisco vpn client October 22, 2008, 2:50 am
Obtain Mcse,Ccna And Many More Without Exams(Pay After Check Results)100% Passing Gaurantee July 13, 2006, 10:04 am

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map