0

Topology: Client ----- Intermediate Device ----- Server

Client: win7

Intermediate Device: unknown

Server: CentOS 5.8

The problem occurs when the client and server are trying to establish a SSL connection. It happens to one specific port, 2000. I haven't been able to replicate the problem with other port numbers.

I captured packets on both client and server. After the TCP handshake, from the client's perspective, it's not receiving ACKs for its previously sent packets so it kept re-sending them. On the server side, however, it did receive those packets and sent ACK packets.

The weird thing is, after the server sent those ACKs, it received a [RST, ACK] packet, from the intermediate device, for every packet it sent.

What could be the cause?

xiaofeng.li
  • 103
  • 4
  • Are they on the same wire? (i.e: no other devices in between such as a firewall, router, ...) – ndrix Jun 26 '12 at 08:41
  • @m1ke No they are not on the same wire. The server is located in an IDC, and the client is my own desktop using ADSL(or something similar) – xiaofeng.li Jun 26 '12 at 08:47
  • Do you see any of the TLS handshake (Client Hello at least)? – Bruno Jun 26 '12 at 10:22

1 Answers1

1

If this happens after the SSL connection has been negotiated, it is possible that the intermediate device considers encrypted traffic on port 2000 as a potential security threat (or in some way "unwanted") and makes two things:

  • intercepts the "ACK" sent by the server so they do not reach the client that will consider the server as not responding
  • sends a reset to the server so that it will not keep the connection open waiting for traffic that will never come from the client
marcoc
  • 748
  • 4
  • 10
  • It happens during the SSL negotiaion; however, maybe the intermediate device thinks even trying to start an SSL session is a threat. Seems I have no choice but switch to another port. – xiaofeng.li Jun 26 '12 at 09:02
  • You are correct: my statement has to be corrected into "If it happens after the *TCP* connection..." – marcoc Jun 26 '12 at 09:14