The original (authorized) sender would then think something went wrong (packet loss), send a new packet and be none the wiser.
Thanks for the feedback! It doesn't describe how it prevents that attack, because it doesn't prevent this attack :).
As someone else wrote, I could put the IP address of the sender into the encrypted data and validate that in the backend and drop the packet + block the IP address.
I will add that in the next release!
But if an adversary uses the SAME network, then the IP address that the server sees will be the same for the client and the adversary, so it only matters if the adversary takes the packet and sends it from a different network, which the adversary won't have to do, because they still control the network where the packet was originally sent from.
https://github.com/beac0n/ruroco/blob/ce766751b51c8ff6246a2b...
The encrypted information is current time, command and random data. So the server could feasibly detect that a retransmission has occurred but that's about it.
This doesn’t feel like an unpickable lock so much as a decorative cover that makes the lock less obvious.
Port knocking is IMHO just to keep your sshd logs clean from huge lists of failed attempts, that prevent me from actually finding interesting information in them.
Ruroco can be used for more than just keeping sshd logs clean, for example I could also enable a service other than ssh, for example a private file server that I want to get access to when I'm on my phone (although I haven't implemented an android version yet, it should be doable).
Spoofing TCP is useless - you actually need to receive all the packets sent to the original TCP, which means either you are already on the receiving path, or managed to put yourself on it e.g. through a BGP route advertisement - either way, it leaves some trail and much harder to carry out.
(And even so, the attacker still has to go through SSH authentication or an SSH vulnerability)
See: https://en.wikipedia.org/wiki/TCP_sequence_prediction_attack
It's not practical but it is possible. It was more effective in the past when operating systems had more predictable initial sequence numbers. Famously this is how Kevin Mitnick (allegedly?) attacked Tsutomu Shimomura.
IIRC even SYN cookies are older than 20 years at this point.
RST attacks in particular are common enough to make TCP completely unsuitable for reliable long-term connections. And since TCP is also unsuitable for short-term connections, that leaves UDP the only option.
Now, RST attacks are still a thing, but mostly irrelevant to this port knocking alternative.
What do you mean "original TCP"? I'm talking about an attacker creating a new TCP connection with a spoofed source address.
> which means either you are already on the receiving path
Yes, I believe that's the threat model under discussion here. Tepix mentioned an attacker who can intercept a packet, which I believe means the attacker is already on the receiving path.