HN Explorer

Ask HN: Can a TCP connection be MitM attacked if already established?

4 points by pcdoodle ↗ HN
I was wondering, if I have a Server that accepts TCP connections from clients, assuming the initial TCP connection is established without attackers, can the client assume that communication received on that socket is actually from the server? Thanks in advance.

14 comments

[ 1.5 ms ] story [ 39.1 ms ] thread
dsp
> can the client assume that communication received on that socket is actually from the server?

No.

pcdoodle
1. Client micro computer connects to my server over internet.

2. They exchange some secret sauce to make sure they're sure of each other (I have no room for TLS on micro computer).

3. The connection is never severed.

How does this get attacked over WAN? IP Spoofing or something? Let's assume the LAN of the client is secure.

bombcar
Imagine there’s a router on the WAN.

Now imagine that router does things to your packets.

If they’re not encrypted how do you know?

pcdoodle
You mean the clients router being compromised or somewhere past that?
bombcar
Anywhere in between. Do a trace route to hacker news or something - it’ll be 10-20 hops, only two of which are the local routers at the endpoints.
__d
If you're able to intercept traffic anywhere in the path between the two parties, interception and hijacking is trivial. So yes, client LAN, server LAN, transit link, or any router on the path. And there's a bunch of routers, switches, etc, on that path, all of which have firmware that can be exploited ...

If you're not able to directly intercept the traffic, you can generally spoof the source address, but getting a copy of the return packets (other than on the client's local network) is also possible if you can inject a bogus route, for instance.

The only reason this doesn't happen a lot more than it does is that most valuable stuff uses TLS/SSL.

__d
The network stack matches TCP/IP packets to sessions using the 5-tuple of source and destination IP and port number plus the protocol number. It doesn't (and can't) care how such a packet actually gets to the receiver.

So by spoofing the source address, it's trivial to send packets to your target host. However, to have them actually accepted, the sequence numbers need to be right (or right enough) to slot that packet into the ongoing stream.

But ... packets with bad sequence numbers don't break a connection, they're just assumed to be retransmissions of something that already arrived (if the number is low) or an indication that a bunch of packets were lost (if high). This is a little complicated by the fact that the session is bi-directional, but not too much.

So, especially if you're able to monitor the packets of the session, it's fairly simple to hijack it by sending sequence numbers a bit ahead of the legitimate sender, causing its packets to be discarded as duplicates, and yours to be accepted.

pcdoodle
Thanks for the in depth response. This is starting to make sense to me.
toast0
> I have no room for TLS on micro computer

How micro is your micro? There are embedded TLS stacks such as wolfSSL[1]. If you carefully select the cipher suite and certificate requirements, and perhaps limit TLS payload sizes, you may be able to fit on a lot more systems than you initially suspect. x.509 is expensive in code space though, if that's the constraint, you may do better with an application specific certificate replacement of some sort.

[1] https://www.wolfssl.com/

badrabbit
No. At any point an interceptor can double proxy between you and the other side. It is also possible to hijack the connection completely and simulate the other side.
pcdoodle
What if we assume the client LAN is secure? Does that change anything? Any further reading you would recommend?

Thanks

__d
Plenty of stuff out there: search for 'tcp session hijack' and go from there.
pcdoodle
Thank you. I will look into this concept.
badrabbit
You should never assume that. If this is a real world thing, just put TLS on the connection properly and be done with it.