adding "srcon" protocol, and new cvars:
authordivverent <divverent@d7cf8633-e32d-0410-b094-e92efae38249>
Thu, 9 Apr 2009 07:30:53 +0000 (07:30 +0000)
committerdivverent <divverent@d7cf8633-e32d-0410-b094-e92efae38249>
Thu, 9 Apr 2009 07:30:53 +0000 (07:30 +0000)
commita737a50df4004443459e818e1e463141ef246280
tree201e90e5a244b4e408a73033d90112543ce3493e
parentc7eea28ff1214ea7c198be1bda5638e1df314ab1
adding "srcon" protocol, and new cvars:

rcon_secure - if enabled, client sends srcon requests instead of rcon, and server ONLY accepts secure (HMAC-MD4) rcon.
rcon_secure_maxdiff - maximum clock difference between srcon client and server in seconds (is used to protect against replay attacks)

In srcon, the command is included into the hashing, so one can still sniff the command and its replies - but what an attacker can't do in srcon is sniff the password, or change the command over the wire. There is still limited replaying potential (within 15 seconds, the command can be replayed), but I don't think this can cause much harm.

TODO: add some way to FORCE rcon_secure to be 1, as currently a malicious server could stuffcmd("rcon_secure 0\nrcon ...") and then issue a rcon command to get the password.

git-svn-id: svn://svn.icculus.org/twilight/trunk/darkplaces@8886 d7cf8633-e32d-0410-b094-e92efae38249
hmac.c
host_cmd.c
netconn.c