Hi, What would cause TCP DUP's (and spurious retransmissions, fast retransmissions, a cpl up to a dozen) to be received from random SSL-enabled webservers on virtually every package, WHILE REGULAR TCP/IP (non-TLS) doesn't generate any DUP's? Zero. If the latter would be the case, I would just have a faulty router or a low level networking issue (hardware/IP stack). I fail to see how this only concerns SSL traffic, it clogs up a nice view in Wireshark with all the DUPs. asked 13 Feb '16, 03:59  boiiingg |
One Answer:
If it's only SSL/TLS it could be a security device interfering with SSL/TLS like a firewall. However, without access to a capture file it's hard to say more than that! Regards answered 13 Feb '16, 04:26  Kurt Knochner ♦ |
have you tried deduplicating your capture? See https://blog.packet-foo.com/2015/03/tcp-analysis-and-the-five-tuple/ for more info why.
(Thanks for https://blog.packet-foo.com/2015/03/tcp-analysis-and-the-five-tuple/)
Some issues I noticed:
Just a shot in the dark... I wonder if Wireshark somehow tricked, seeing these packages as DUP ACKs.
Are these issues typical for a SPAN VLAN monitoring port at the ISP?
Anything else that would explain change of the ID-field in the IPv4 header while the rest of the datagram is untouched?
The difference in IP ID field means that the "duplicates" have been really sent by the sending machine and haven't occurred due to properties of the capturing method.
If you SPAN the whole VLAN and do not / can not set additional filtering on the switch, you basically get a duplicate of each and every packet because you get one copy of the packet when it enters the switch and another copy of the same packet when it leaves the switch, so it would not explain, even if the IP ID fields would not differ, why the DUPs only exist for the SSL traffic. (There are exceptions related to total traffic volume vs. the monitoring port bandwidth and to broadcast/multicast packets, but that's a different story).
So I'd vote for the SSL stack to be responsible.
I thought the SPAN VLAN would be a bit fat fetched ... I am going to run some more tests using a different SSL stack. Despite having a very popular system (Linux 3.16.0-4) with openssl 1.0.1k-3+deb8u1). Will need to reinstall the OS anyway in a cpl of days.