I am making a multiplayer game for fun and wish to keep it secure. The client is written in C# and the server in node.js with a working connection over TCP at the moment. I am new to this subject, and implementing something with RSA or Diffie-Hellman or TLS seems confusing and something that I could easily mess up. I have looked into using TLS, but have no idea how to do it without using a client certificate. Google is no help because it does not do well with negative searches if that makes sense; I only seem to get results for using client certificates in TLS. And so I came up with the idea of using HTTPS as a Diffie-Hellman substitute, connecting to the server using a self signed certificate (for clarification, the server is the one using the cert, english is weird), validating user login info, and passing back a key to use for symmetric encryption for the TCP packet transfers.
The general process would go like this:
1. Client initializes TCP connection with server and sends server a temporary ID.
2. Server marks the socket the user is connecting to with the temporary ID.
3. Client sends HTTPS post to server with login info and the temporary ID.
4. Server hashes/salts password and compares to database. On successful validation give authorization to the socket with the temporary ID what the validated user has access to. If either auth validation fails or no socket is found matching the temporary ID, return an error to the client(400). On success, generate a key to use for symmetric encryption and return it to the client(200).
5. The client recieves the symmetric key, and both client and server use it to talk in future communications.
The temporary ID serves the purpose of allowing the server to be able to tell which TCP socket connection to authorize when the HTTPS validates the login info. I think this would be ok against man in the middle attacks because the man would only get the temporary ID which is not used for anything else, and if it were changed the server would not find a socket with a matching ID during the HTTPS phase, and it would just return an error.
I think that this would be inferior to TLS because there will not be any packet signing going on in step 5 and future TCP communications, but it might be fine.
From what I understand about encryption, symmetric keys only act as a sort of cipher, so it probably is not too much overhead to deal with on server side.
Is this system viable?