0

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?

Improve this question
2
  • Stick with SSL. No need to reinvent the wheel. The first link on Google for "c# ssl client server example" is a complete application, server with certificate, client without certificate.
    – ThoriumBR
    Commented May 20, 2019 at 3:21
  • 2
    "I have looked into using TLS, but have no idea how to do it without using a client certificate. Google is no help ...." - Using TLS with only a server certificate and no client certificate is the most common case. And don't blame Google if you fail to find something - it is more likely that you did not understand enough of TLS yet to ask a useful question. I recommend that you make yourself familiar with how TLS works so that you a) can ask the proper questions here or at Google and b) don't see a need to reinvent the wheel.
    – Steffen Ullrich
    Commented May 20, 2019 at 4:10

1 Answer 1

Reset to default
3

HTTPS is TLS. Using HTTPS you already establish a symmetric key as part of setting up the TLS connection. You don't need to pass yet another symmetric key around in most scenarios. You definitely should not be dealing with RSA or Diffie-Hellman directly. Just use a well-established crypto library supporting TLS/HTTPS connections. The only thing you need to consider RSA or DH or anything else is in setting up the configuration or calling parameters for your chosen library.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .