Challenge-response port knocking for TCP
The idea of advertising opportunistic crypto presence in TCP/SYN inspired me to another one: authenticated connection handshake for TCP protocol. Scenario: Application listening on port P of server S, only for authenticated users. Unknown user sends TCP/SYN to S:P, gets back TCP/RST, with challenge in MD5 field of TCP options. The user doesn't support this scheme, so considers the port closed. Unknown-now known user sends TCP/SYN, gets back TCP/RST with the challenge, sends another TCP/SYN, this time with calculated response using a shared secret, again in TCP MD5 option field, gets back TCP/SYNACK. The random challenge should be sent back in all TCP/RST packets, otherwise port scanning will still be possible. Is it a good idea? Could it work? Why not?
At 11:21 PM 3/19/2004, Thomas Shaddack wrote:
The idea of advertising opportunistic crypto presence in TCP/SYN inspired me to another one: authenticated connection handshake for TCP protocol.
Scenario: Application listening on port P of server S, only for authenticated users.
Unknown user sends TCP/SYN to S:P, gets back TCP/RST, with challenge in MD5 field of TCP options. The user doesn't support this scheme, so considers the port closed.
Unknown-now known user sends TCP/SYN, gets back TCP/RST with the challenge, sends another TCP/SYN, this time with calculated response using a shared secret, again in TCP MD5 option field, gets back TCP/SYNACK.
Firewalls may munge the TCP headers, and if you're just protecting the session setup, you still need to worry about eavesdroppers and session hijackers. Also, this doesn't strike me as the right protocol layer to address the problem at. If you want to be secure, either use IPSEC (in which case this isn't that necessary), or else use SSL if you'd rather wrap things in Layer 4. Alternatively, do the job at Layer 7.
participants (2)
-
Bill Stewart -
Thomas Shaddack