I'm not sure whether this topic belongs in Cryptography, Programming or StackOverFlow so please forgive me if I don't add a useful question to this site.

I want to give both server and client programs (.jar archives) to my users.

  • The SERVER is a mod for a game (has one server-id)
  • The CLIENT is a smartphone that is supposed to control the game by sending messages to the server (has one client-id)

I wanted to keep everything encrypted so I think SSL is a good choice. Because the Server is actually not mine what I did was let the server create a self-signed certificate and store it

Because accepting any certificate can be exploited, e.g. the attacker could spoof the server-id of another server and my client app would send the internal password (not SSL related) to the attacker. The attacker could now spoof the client-id and has control over a game

How should I implement the client so that it verifies and distinguishes servers by their certificate?

  • Will you centraly sign the server's certificates (so you act as CA) or will you do "Trust-On-First-Use"? If you do use "Trust-On-First-Use" you'd "just" verify the certificate you see this time is the same as you saw last time and then you're safe. – SEJPM Nov 26 '15 at 21:23

With most TLS implementations you just need to store the self signed certificate of the server in the trusted certificate store. You may have to add a specific option to the command line or API call to mark the certificate as trusted.

In that case the chain of the server certificate leads to a trusted certificate because the server directly uses the trusted certificate (i.e. a "chain" of one certificate).

You do need to establish trust before establishing the connection, e.g. by distributing the self signed certificate with your client application.

| improve this answer | |
  • Could I let the server broadcast their certficates and set their server-id to the SHA-256 of the encoded certificate? The client would trust every certificate but would verify the server-id. – KeksArmee Nov 27 '15 at 15:11
  • Anybody could send any certificate, right? So I don't see any trust relationship being established that way. If you already know the certificate then you can just as well store the certificate itself. – Maarten Bodewes Nov 27 '15 at 23:29
  • Sorry, I forgot to mention that the client has to create an "account". The server will save [client-id, sha256salt(password of account)] and the client will store [sha256(public key), password of account]. If the attacker doesn't know the private key, he cannot decrypt incoming data. If the attacker gives any public key he won't get the account password – KeksArmee Nov 28 '15 at 19:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.