Printable View
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.
In article <de71c1b8-2a35-44e2-b41a-763f6889ce63@a32g2000prf.googlegroups.com>,
Chandler Bing <mel.chandler@gmail.com> wrote:[color=blue]
>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[/color]
A good tool for troubleshooting SSL is curl
[url]http://curl.haxx.se/[/url]
alan
On Jun 5, 12:00*pm, pale...@sonic.net (Alan Strassberg) wrote:[color=blue]
> In article <de71c1b8-2a35-44e2-b41a-763f6889c...@a32g2000prf.googlegroups.com>,
> Chandler Bing *<mel.chand...@gmail.com> wrote:
>[color=green]
> >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[/color]
>
> * * * * A good tool for troubleshooting SSL is curl
>
> * * * *[url]http://curl.haxx.se/[/url]
>
> * * * * * * * * * * * * alan[/color]
Any suggestions as to how?
Keep in mind the transaction we're monitoring is from a VeriFone
credit card terminal to TSys' server on the internet. To perform a
transaction there's a lot of information I'd need from the terminal
that I just don't have.
Chandler Bing
Chandler Bing wrote:[color=blue]
> 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.[/color]
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
Chandler Bing wrote:[color=blue]
> 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.[/color]
It's correct for SSL. RFC 2246 ([url]http://www.ietf.org/rfc/rfc2246.txt[/url]) #7.2.1:
'Either party may initiate a close by sending a close_notify alert.
Any data received after a closure alert is ignored.
'Each party is required to send a close_notify alert before closing
the write side of the connection. It is required that the other party
respond with a close_notify alert of its own and close down the
connection immediately, discarding any pending writes.'
Now the RFC doesn't mandate a strong connection between SSL connections
and connections of the underlying transport, so in theory close_notify
!= FIN, but, in practice, SSL APIs close both at the same time. (A FIN
*without* a prior close_notify constitutes a truncation attack, which
the API should report to the application.)
So, in practice, once a peer has received a close_notify+FIN, any data
it has left to send cannot be sent, and indeed must constitute an error
in the application protocol.
In other words there can be no shutdown-for-write in SSL.
EJP
On Thu, 05 Jun 2008 11:58:17 -0700, Chandler Bing wrote:
[color=blue]
> 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.[/color]
This behavior occurs when one side wants to close the connection and the
other doesn't.
There is something like half-close, where one application closes it's
side of the stream, but still can receive data from the other side. What
you see on the wire is what looks like a half-close.
But half-closes are rare and the behavior you see is consistent with one
side doing a full close and the other side that does not close but keeps
sending.
IIRC, but I may be wrong on this, SSL shuts down the connection in the
SSL layer before shutting down on the TCP layer. So this sounds like a
bug in one -- or both -- of the SSL stacks.
M4
Martijn Lievaart wrote:[color=blue]
> IIRC, but I may be wrong on this, SSL shuts down the connection in the
> SSL layer before shutting down on the TCP layer. So this sounds like a
> bug in one -- or both -- of the SSL stacks.[/color]
That's correct. And SSL is obliged to respond to an incoming
close_notify by closing its own end. But if it is writing, not reading,
it doesn't have the opportunity to see the close_notify. So it writes.
So the peer responds with RST. So it's a bug in the application
protocol. The same thing would happen if it was a plaintext connection.
On Jun 5, 11:58*am, Chandler Bing <mel.chand...@gmail.com> wrote:[color=blue]
> 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.[/color]
This is normal if you try to make SSL support TCP's half-closed
semantics. SSL doesn't fully support TCP's half-closed semantics, in
the sense that SSL's half-closure doesn't map to TCP's half-closure
exactly. One consequence can be the abnormal termination of a
connection as seen at the TCP layer.
The only thing that matters is that the SSL connection terminated
normally. What do the SSL layers on both ends say?
DS
David Schwartz wrote:[color=blue]
> This is normal if you try to make SSL support TCP's half-closed
> semantics. SSL doesn't fully support TCP's half-closed semantics, in
> the sense that SSL's half-closure doesn't map to TCP's half-closure[/color]
'SSL's half closure' doesn't even exist. You can't half-close an SSL
connection for write and expect to read anything from it.
It seem to me that the OP's problem would happen even if there was no
SSL involved.
On Jun 12, 9:09*pm, EJP <esmond.not.p...@not.bigpond.com> wrote:
[color=blue]
> 'SSL's half closure' doesn't even exist. You can't half-close an SSL
> connection for write and expect to read anything from it.[/color]
You can send a 'close notify' to the other side. At this point, the
SSL connection is half-closed. (This is not quite the same as TCP's
half-closure.) The other side may continue to send data at this point,
as it has not even received your 'close notify' yet.
[color=blue]
> It seem to me that the OP's problem would happen even if there was no
> SSL involved.[/color]
Possible, but there are unique aspects to SSL. For example, SSL
explicitly permits you to send a 'close notify' and then close the
underlying TCP connection. If you do this just after the other side's
'close notify' has been received, a TCP RST will result. There is no
directly analogous TCP-only scenario.
DS
On Jun 5, 7:07*pm, EJP <esmond.not.p...@not.bigpond.com> wrote:[color=blue]
> Chandler Bing wrote:[color=green]
> > 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.[/color]
>
> It's correct for SSL. RFC 2246 ([url]http://www.ietf.org/rfc/rfc2246.txt[/url]) #7.2..1:
>
> * * 'Either party may initiate a close by sending a close_notify alert.
> * * Any data received after a closure alert is ignored.
>
> * * 'Each party is required to send a close_notify alert before closing
> * * the write side of the connection. It is required that the other party
> * * respond with a close_notify alert of its own and close down the
> * * connection immediately, discarding any pending writes.'
>
> Now the RFC doesn't mandate a strong connection between SSL connections
> and connections of the underlying transport, so in theory close_notify
> != FIN, but, in practice, SSL APIs close both at the same time. (A FIN
> *without* a prior close_notify constitutes a truncation attack, which
> the API should report to the application.)
>
> So, in practice, once a peer has received a close_notify+FIN, any data
> it has left to send cannot be sent, and indeed must constitute an error
> in the application protocol.
>
> In other words there can be no shutdown-for-write in SSL.
>
> EJP[/color]
As I look more at the traces, it appears the VeriFone terminal
(client) does a TCP close. It does not do an SSL close_notify, as it
should. The server attempts to push some final TCP data, but is
ignored, it finally does its own encrypted alert, which is message
type 21. I'm not sure, but I think that's decryption_failed, but
that
doesn't seem right, since it's a TLS message and this is SSL. After
numerous attempts it finally does a close_notify & FIN which prompts
the VeriFone terminal to do a RST.
It appears that the VeriFone terminal is doing a TCP close, without
closing the SSL session and then doesn't allow the other side to
close
it's TCP session. I've since found out that the VeriFone terminal
runs a firewall made by McAfee. I wonder if it's their application,
IP Stack, or firewall that's causing all these problems.
Chandler Bing
On Jun 12, 8:25*pm, David Schwartz <dav...@webmaster.com> wrote:[color=blue]
> On Jun 5, 11:58*am, Chandler Bing <mel.chand...@gmail.com> wrote:
>[color=green]
> > 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.[/color]
>[color=green]
> > I have packet captures, but I'm not sure how to post them or share
> > them out.[/color]
>
> This is normal if you try to make SSL support TCP's half-closed
> semantics. SSL doesn't fully support TCP's half-closed semantics, in
> the sense that SSL's half-closure doesn't map to TCP's half-closure
> exactly. One consequence can be the abnormal termination of a
> connection as seen at the TCP layer.
>
> The only thing that matters is that the SSL connection terminated
> normally. What do the SSL layers on both ends say?
>
> DS[/color]
What I'm seeing is that the CCT is initiating a TCP close without
closing the SSL session (close_notify). After the CCT's FIN, it does
not acknowledge any data from the server. The server after attempting
to send and re-send the data several times ultimately responds with a
close_notify and a FIN, which is ignored. The CCT finally RST the
connection, sometimes several times.
On Jun 12, 10:38*pm, David Schwartz <dav...@webmaster.com> wrote:[color=blue]
> On Jun 12, 9:09*pm, EJP <esmond.not.p...@not.bigpond.com> wrote:
>[color=green]
> > 'SSL's half closure' doesn't even exist. You can't half-close an SSL
> > connection for write and expect to read anything from it.[/color]
>
> You can send a 'close notify' to the other side. At this point, the
> SSL connection is half-closed. (This is not quite the same as TCP's
> half-closure.) The other side may continue to send data at this point,
> as it has not even received your 'close notify' yet.
>[color=green]
> > It seem to me that the OP's problem would happen even if there was no
> > SSL involved.[/color]
>
> Possible, but there are unique aspects to SSL. For example, SSL
> explicitly permits you to send a 'close notify' and then close the
> underlying TCP connection. If you do this just after the other side's
> 'close notify' has been received, a TCP RST will result. There is no
> directly analogous TCP-only scenario.
>
> DS[/color]
This sounds like the scenario we're seeing. The CCT closes the TCP
session without closing the SSL session and then ignores the server
completely until the CCT resets the connection. The server attempts
to send and resend the final data and then an encrypted alert
(close_notify?) and close the TCP session. I don't know enough about
SSL to determine what the server is ultimately sending. Wireshark
just shows it as an encrypted alert, message type 21. Is that an
error, or is that a close_notify?
Chandler Bing
Chandler Bing wrote:[color=blue]
> (close_notify?) and close the TCP session. I don't know enough about
> SSL to determine what the server is ultimately sending. Wireshark
> just shows it as an encrypted alert, message type 21. Is that an
> error, or is that a close_notify?
>
> Chandler Bing[/color]
Wireshark does have the ability to decrypt SSL packets if you can
provide it with the keys.
Navigate as follows:
Edit menu | Preferences | Protocols | SSL | RSA Keys list:
It can decrypt IPSec, TACACS+, RADIUS, etc.
Best Regards,
News Reader
On Jun 18, 11:20*am, Chandler Bing <mel.chand...@gmail.com> wrote:
[color=blue]
> What I'm seeing is that the CCT is initiating a TCP close without
> closing the SSL session (close_notify). *After the CCT's FIN, it does
> not acknowledge any data from the server. *The server after attempting
> to send and re-send the data several times ultimately responds with a
> close_notify and a FIN, which is ignored. *The CCT finally RST the
> connection, sometimes several times.[/color]
I believe that attempting a normal TCP close without sending an SSL
close_notify is a breach of the SSL protocol.
DS