The reason for the transaction failure appears to be that the
participants (server, client) pulled out of it before it could be
completed.
Here's an analysis for you. Maybe someone else on the list can help
with the rest for explanation why - I can see what's going on, but I'm
a little shaky on tying events to RFCs :)
=================================================================================
Frame 8721
The client acknowledges receipt of the last two shipments of bytes,
starting at the server's last known sequence number of 2463. The
accounting goes like this: 2163 + 303 + 26 = 2492. (Seq: 832, Ack:
2492, Len: 0).
Time goes by...(17 seconds)... server and client are both waiting for
something to happen. The client is waiting for the server to send
more bytes, but we see in the next frame that the server has been
waiting for the client to acknowledge another 23 bytes!
Frame 8722
The server wonders if the client's last ack was lost; the server's
spot in the sequence is not 2492 but 2515 (Seq: 2515, Ack: 832, Len:
0)
Frame 8723
The client concludes that a packet was lost; it says the last sequence
number it was aware of was 2492 (Seq: 832, Ack: 2492, Len: 0).
Time goes by... (1 second)... maybe the server is hesitating to resend
any part of this transaction, encrypted or not
Frame 8724
The server resends the missing 23 bytes (Seq: 2492, Ack: 832, Len: 23)
but trips an alert (SSLv3 Record Layer: Encrypted Alert) and says
let's close this socket (Flags: 0x19 (FIN, PSH, ACK)).
Frames 8725-8726
The client acknowledges receipt of the missing 23 bytes (Seq: 832,
Ack: 2516, Len: 0) and hastily withdraws (Flags: 0x14 (RST, ACK)
=================================================================================
I don't know exactly why this happened.
On the surface it seems the server decided the security of the
transaction might be compromised because a packet (containing the 23
bytes) was reported missing. But what happened with the 23 bytes?
Sometimes you see that if one side of the communication or something
in the middle had to fragment packets to get them though a pipe that
was narrower than they expected.
The client would like the pipe to be 1460 bytes (Frame 8707,
MSS=1460), but the server says no, don't send any more than 1380 bytes
in a packet (Frame 8708, MSS=1380). That makes me guess there's a
firewall in front of the server (probably trying to accommodate
overhead of VPN traffic). But the largest segment size I saw in this
exchange was 1360 bytes (Frame 8712, from the server: Seq: 1, Ack:
103, Len: 1360).
Although I didn't see any packets getting fragmented at the IP layer I
did see that it took two TCP segments (Frames #8712(1281), #8714(726),
to transmit the certificate. It is frame #8712 where something has to
be split to fit in two shipments, but that would be the case
regardless of mss as that payload is 2002 (2007?) bytes. But I don't
know that any of that observation is relevant, and now we're getting
to the limits of my interpretation skills :(
Could someone else please continue? (Yes, I'm sure it's staring us
right in the face, but that's as far as I got.)
Hope this helps,
Vikki
On 4/8/09, Bart Greyson <sonofgrey@xxxxxxxxx> wrote:
> On Wed, Apr 8, 2009 at 1:36 PM, Sake Blok <sake@xxxxxxxxxx> wrote:
>
>> On Wed, Apr 08, 2009 at 12:59:40PM +0200, Bart Greyson wrote:
>> >
>> > I installed Wireshark to see what is being sent back and forth
>> > between
>> the
>> > PCCharge software (VeriFone) and the bank. It looks like a package
>> > got
>> > lost, but I'm new to this kind of deep debugging, so if someone can
>> tell
>> > me what's happening here, that would be great!
>> >
>> > When the transaction fails I get these messages:
>> >
>> > 8705 2009-04-07 20:24:27.689549 192.168.1.64 192.168.1.254
>> > DNS Standard query A sslgw1.53.com
>> [...]
>> > 8726 2009-04-07 20:25:05.595049 64.57.146.209 192.168.1.64
>> > TCP https > wg-netforce [RST, ACK] Seq=2516 Ack=832 Win=0 Len=0
>> >
>> > Can anyone tell from these messages what went wrong and what might be
>> the
>> > cause?
>>
>> It would be helpful to have this data as a binary capture file. Could
>> you post a binary capture file with packets 8705-8726 of the original
>> file?
>>
>> Cheers,
>> Sake
>>
>>
> Hi Sake,
>
> I don't know exactly where I can turn this data into a "binary capture file"
> in Wireshark. I uploaded it in a more detailed form if that's what you
> wanted: http://www.greyson.be/capt.txt.
>
> Thanks!
>