0

My client-server program uses OpenSSL to handle the data exchange and is working, but I need to be sure that the server on which my client is connecting is the correct server and not a fake one.

The problem is my program generates a self-signed certificate and the client cant verify by that. If I embed a certificate, anyone could extract it, make a fake client-server and try to steal the information. The same for OpenPGP keys.

So, can I implement some method to verify the server even when the server binary is available for everyone, since it is the client too?

Fusgyus
  • 1
  • "If I embed a certificate, anyone could extract it, make a fake client-server and try to steal the information" is not correct. That can only happen if you embed the private key as well. The simple solution, as always, is to get the certificate signed by a CA. – user207421 Oct 31 '14 at 05:01
  • But the private key has to be on server, right? The client acts as server too, is like P2P. – Fusgyus Oct 31 '14 at 14:27

1 Answers1

0

In this situation, the secure authentication does not rely on the actual certificate, but the key pair covered.

Asymmetric cryptography relies on a private and a public key. The private key must remain confidential (so keep it on the server which has to be authenticated, the one you described as the correct server). The public key can be arbitrarily spread, the only thing somebody could do is encrypting information for the private key's holder, or verifying a signature issued by him.

The (very) basic idea behind the actual authentication process works by either the authenticating client sending an encrypted random number, which only the correct server can decrypt and return, or by having the server sign something defined by the client. The real process implemented for authentication is a little bit more complicated to prevent man-in-the-middle-attacks, but far beyond scope of this answer.

So, can I implement some method to verify the server even when the server binary is available for everyone, since it is the client too?

Rely on something already there, and do not implement crypto code on your own. Maybe consider using TLS for encrypted communication anyway if you're already distributing keys, authentication will be done during the handshake phase.

Jens Erat
  • 37,523
  • 16
  • 80
  • 96
  • The program is already using TLS 1.2, but a fake server could act like the correct server and examine my protocol handshake (performed after the TLS connection is established) and then starts to steal the information. I think that any method (that doesn't involve a thirty-party) would be prone to reverse engineering, since the server binary is known. – Fusgyus Oct 31 '14 at 14:41
  • If you validate the fingerprint of the server's certificate, this cannot happen. Nobody is able to perform a TLS handshake without the private key, which you don't have to (and may not) publish. – Jens Erat Oct 31 '14 at 14:44
  • Sorry, I don't get it. To my server (that is the client too, like P2P, but not) perform the TLS handshake I have to embed the private key in it (?). So how it is possible to a attacker that have the server binary not get into the private key by reverse engineering. – Fusgyus Oct 31 '14 at 16:46
  • You wrote about your own server which has to be authenticated by other servers (in this context, these are clients). The server that need to be authenticated gets the private key, the others only the public one. If all servers need to authenticate against each other, you need to generate a new key pair for each of them. Consider a public key a a padlock, and the private key the (physical) key to unlock it. Authentication means the (authenticating) server unlocks something locked by the client. – Jens Erat Oct 31 '14 at 17:09