Why don't you just have your server broadcast a bunch of bits that change every minute and use them instead of a timestamp to hash with your secret?
Your protocol seems vulnerable to eavesdropping, technically couldn't someone sniff any client's packets to find out which port to connect to?
Also, I suppose you have some kind of tolerance for when you send a packet to the server at minute x and 59 sec and it arrives at minute (x+1) and 01 sec?
Yes, you are correct this approach would be vulnerable to a simple man-in-the-middle attack. Just sniff packet headers to find out what port the server is accepting indicated by packets sent back with an ACK flag set. Headers with that flag set will be the currently valid port at that instant, since all other packets will be sent back with RST set (blocked).
And yes you could have potentially very frustrating synchronization problems. With TCP you wont be able to control certain things such if a connection request is going through exponential back-off due to network congestion. For example, lets say you could make a connection request within your alloted tolerance, but if there is network congestion and your NIC is not getting either RST or ACK packets back, it will continue to send connection requests at continuously increasing intervals which you cannot easily control since its done at the transport layer. Then one of your connection request packets finally reaches the server late, and you are blocked from connecting again for 15 minutes.
If you could work around the second issue though it could work. I think its a great idea in general, nice creative work!!
So the way I currently have it the man-in-the-middle is useless because once a client connects to the SSH server all other IP addresses are locked out from that port.
I agree about congestion, but IIRC the TCP connection timeout defaults to 75s so since I'm tolerant to connections across two windows (i.e. two minutes) then I think I'm safe.
Ah, so your server only accepts 1 connection at a time on a given listening port? That is good protection.
I didnt realize there was a TCP standard for the max acceptable amount of retransmissions. But yeah if you can account for this with a pad then you should always be safe.
If you ever opensource your network code I'd love to see it.
Why don't you just have your server broadcast a bunch of bits that change every minute and use them instead of a timestamp to hash with your secret?
Your protocol seems vulnerable to eavesdropping, technically couldn't someone sniff any client's packets to find out which port to connect to?
Also, I suppose you have some kind of tolerance for when you send a packet to the server at minute x and 59 sec and it arrives at minute (x+1) and 01 sec?