[Nokinside]

Ah. I get your point.

Tell me what percentage of attackers on the net have full access to the network traffic and can do full MITM attack?

If the goal is layered defense and minimizing exposure, worst case scenario is not good counterargument.

[penguinduck]

You don't need to be able to do a full MITM attack. You just need to be able to read the traffic, not modify it.

And if you believe this is an unreasonable assumption, why did you link me a program which says in its description "The problem with the original concept was that if your port sequence was observed by passive eavesdropping, it was easily replayable." ? It tries to solve this exact problem - a sniffing attacker.

I am just explaining why this program fails to solve the problem you claimed it solved in your original reply. Surely you can understand that.

[Nokinside]

Tell me if I understood something wrong:

Without knocking:

Service is listening and accepting new connections in well known port. When client makes connection attempt, attacker can replay the connection attempt and server starts handshake. Even without sniffing attacker can initiate handshake by just requesting connection.

With knocking:

Server/firewall opens requested port for client who knocks. That port is _not_ open for subsequent connection attempts. Simple replay is not going to initiate handshake. You need to block client from sending.

[penguinduck]

There is no need for a subsequent connection.

It is irrelevant whether the legitimate client connects or the attacker does if the attacker is sniffing traffic. This is just how IP and TCP work.

If I am sniffing traffic, I can fool the server into thinking I am the client and do what I want, while fooling the client into thinking I am the server and make him happily drop the connection after he sent the initial packet I needed to find out the port.

Basically, in IP protocol you can say you are any IP address you want in your packet. There is no way for the receiver to tell whether you're lying[1]. Then TCP introduces sequence numbers -> if I say I am 1.1.1.1, but I am actually 2.2.2.2, the server will send a sequence number to 1.1.1.1, and expect that number + 1 in response, but as I am not 1.1.1.1 I will not receive his sequence number and be unable to reply with number + 1 - I don't know the number. However, if I am sniffing traffic, I will see the sequence number he sent to 1.1.1.1 anyway, and I will correctly reply with number + 1 while continuing to lie I am 1.1.1.1. So it makes no difference to the attacker whether the server is talking to 1.1.1.1 or 2.2.2.2 (attacker's IP) as long as he can sniff traffic. It also makes no difference whether the legitimate client initiated the connection or the attacker did. It is just packets, it doesn't matter who sent them.

I am not sure if I am understanding what you're asking correctly. Basically, you don't need MITM capability to pretend you're a different IP than you are. Lying about your IP is a basic feature of the IP protocol. And if you are sniffing traffic, it is also not in any way prevented by TCP.

[1] except in special cases when the sender claims something clearly impossible, like claiming to be an IP from a different interface (claiming to be 127.0.0.1 for example) than the one the packet was received on

[Nokinside]

Packet sniffing is passive.

If client has already sent connection request, replay is not going to work if only one connection is accepted. You need to be able to block the traffic from legitimate server or be faster (how?) to get there first.

[penguinduck]

There is nothing magical about a "connection". It is not some kind of secure tunnel. There are only packets. The attacker can take part in the accepted connection that the legitimate host initiated and the server accepted, and pretend to be the server to the client and pretend to be the client to the server, as long as he has the sequence numbers, which he gets from passive sniffing.