If two hosts (Host1 and Host2) successfully accomplish a TCP handshake process and have a connection, would a third host (Host3) be able to send messages directly to Host1's address and (ephemeral) port once it knows them, spoofing these messages with Host2's address and port?

In other words:

Host1 ( <-------------> ( Host2

Host3 sends a message directly to, spoofing it's source port and address to

Would this work, or does TCP have some mechanism that avoids it? As TCP sessions are identified by source and destination addresses and ports and they would have been spoofed, I can't see how can this message be known as being bogon.

  • You should edit your question to be specific to how TCP operates, and remove all the references to clients and servers (TCP has no client/server concept). Word your question as a TCP protocol question, not a client/server question. When you edit the question, it will automatically start the reopen process. – Ron Maupin Jul 4 '16 at 19:46
  • Ok, I'll try, but I think somebody will rate topic as having not enough information after that, as I can't find a better way to explain it than using an example. – Tiago.SR Jul 4 '16 at 19:48
  • We can work through that to tweak you question to make it right, but we can't edit your question in a way which substantially changes what you are asking. For instance, what you are asking requires TCP on server 2 to be configured as if it had an established connection, but that would be off-topic here. You should generalize your question so that it assumes that is done. – Ron Maupin Jul 4 '16 at 19:52
  • I think the place this really belongs is on the Security SE, but at this point, it certainly seems OK here. – MAP Jul 4 '16 at 21:07

For a device to spoof its way into a TCP conversation, it will need to do more than spoof the source address of one of the the hosts in the TCP conversation. It must also be able to know the sequence/acknowledgement numbers, window sizes, ACKs, etc. It would be very difficult to get this to work correctly. For example, you would need TCP on the host being spoofed to not respond to traffic from the other host, otherwise the host to which spoofed traffic is sent will get two ACKs for everything it sends to the host to which it thinks it is connected.

Application TCP sessions (sockets) are identified by a concatenation of the ports and IP addresses, but I think the part you are missing is that the TCP on each host communicates directly with the TCP on the peer connection, and TCP buffers data before sending it to the application. The application doesn't get involved with TCP windowing, sequence numbers, ACKs, etc. There are things that TCP does which don't involve the application to which TCP is connected.

To get this to work correctly, you would need to have direct control of TCP on both the spoofed host and on the host doing the spoofing.

To understand how TCP works, the original source is RFC 793, TRANSMISSION CONTROL PROTOCOL.

  • Ok, all this spoofing stuff is the desired behaviour, I have the control of both spoofed and spoofing hosts and can grant spoofed one won't respond to other host. It's also possible to control TCP headers, sequence numbers, etc. by coding raw sockets. But it wouldn't still work, right? Because ACK would reach spoofed host, spoofing one would have no feedback about delivery of message... or isn't this a problem? – Tiago.SR Jul 4 '16 at 20:56
  • Now you are getting into subject which are off-topic (programming, raw sockets, and controlling TCP on hosts). The TCP on the spoofed host will automatically respond with an ACK to data sent to it, and it will automatically receive ACKs from the other host. It will also do the window negotiation, and the sequence/acknowledgement numbers. You would need direct control over TCP to handle this, and I don't think raw sockets will even give you that sort of control since it happens in the TCP code. You may want to take this to Stack Overflow, where there are many network-savvy programmers. – Ron Maupin Jul 4 '16 at 21:02
  • @Ron Maupin: This can easily be done either with a Man in the Middle (MitM) attack, or by tapping into the conversation and once you've collected all the info you need, you can do active suppression of one host while speaking to the other. – MAP Jul 4 '16 at 21:05
  • @MAP, the question wasn't about MiTM, it was about the spoofed host sending the information to the spoofing host. This is cooperative spoofing, rather than an attack. It is more akin to a poor man's load balancing. – Ron Maupin Jul 4 '16 at 21:07
  • 1
    @MAP, what the OP was asking about is storing content on other servers, and letting the original server send information to the content servers, which would then step into the existing TCP conversation just for the content which the servers have. The question was about the content servers being able to spoof into TCP for their parts, even though the connection is with the original server. It wasn't about any sort of attack. – Ron Maupin Jul 5 '16 at 4:38

sure, that "works". To do it reliably you need to know the sequence numbers. Lots of load balancers work this way - sometimes called 'one-armed' operation where one host does the handshake and hands the rest of the flow off to the balanced server and then gets out of the way.

even if you don't know the sequence numbers you can hunt around and find one in window (aka close enough) fairly quickly which is good enough for injecting some data at imprecise locations.. RSTs are especially annoying.

An authenticated transport like QUIC, or TLS layered on top of TCP, would prevent bogus third parties from being part of the conversation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.