I've been scratching my head debugging this issue I have when accessing my SSL server. Very often Firefox stalls on the connection and would hang for a minute or even indefinitely.
I analyzed traffic from both sides - one packet gets lost on the way from server to the client and this somehow breaks the further connection.
What's interesting, is that all re-transmissions from the server then never reach the client. How this can be possible? I am not seeing any packet loss on this route and I am certain wireshark is able to capture all traffic without dropping any packets. The proof is that Firefox stalls and it means it also never sees the packet too.
First, here what client does:
And how server replies:
You can see that client sends 3 "HTTP/1.1" requests to which server replies "304 Not Modified".
Now, out of those 3 replies, only 2 reach the client (packet size:311, packets #102 & #109).
One packet is lost.
When packet #109 arrives, Wireshark marks it as "[TCP Previous segment not captured] Application Data" because he knows by Seq/ack number that one packet wasn't seen.
Server then begins re-transmission attempts - packets #155 - 193.
None of them appear on the client!
How this is even possible? It happens with about a 1/10 chance on the page load. I suspect it could be NAT in my cable router as can't find any other viable explanations.
Do you have any ideas?
asked 09 Mar '15, 08:25
Do you have any security software installed on the client that hooks itself into the TCP stream, like AV software, Endpoint Security, etc.
If so, malfunction of that piece of software could cause the described behavior. Please try to disable (better uninstall) that software and repeat your test.
BTW: Are you sure you've uploaded the correct capture files? Both files on cloudshark are identical if I do a binary comparison and couldshark is using the same file for both links (see "more info" -> File on Disk: 93655f5d-46aa-459e-ab3f-b22ce44199fc.cap)
answered 09 Mar '15, 13:37
Kurt Knochner ♦
I am looking at your traces with the filter
So, there is a device in the path between the server and the client that actively blocks this tcp segment. I suspect it to be an IDS or WAF where the content of this TCP segment triggers a detection rule.
Too bad you zeroed out the content of the SSL handshake, as I suspect that the certificates in both trace files are most likely not the same, as I suspect there is a device in between that does SSL decryption and re-encryption to be able to inspect the traffic. Are you able to share the SSL handshake packets? Or would that expose to much sensitive data?
The fact that passing this traffic through a PPTP tunnel makes the problem go away supports my theory, as the decryption/re-encryption can't be done anymore so the inspecting device does not see the content of the packet and can not trigger on it.
answered 09 Mar '15, 16:56