0

I would like to have a reliable (as in TCP) encrypted (authenticity, integrity, confidentiality) connection between program A and program B. I am the creator of both A and B. I want A to communicate only with B and vice versa. A and B have no malicious intents against each other, so if A says to B that it is A, B can trust it.

Now there are quite a few ways how to do this, including, but not limited to:

  1. A and B have the same self-signed certificate
  2. A and B have each their own certificate which is:
    1. self-signed; in this case A adds B's certificate to its list of certificate authorities and vice versa
    2. signed by the other party; I believe that each party trusts itself.
    3. signed by me, a one-man certificate authority, using my private key.

...

Which approach is the best and why?

I am quite new to cryptography in general and I find this very confusing. I am sure that this is a problem that arises frequently in many applications, so I am sure that each approach has its pros and cons, and that quite possibly I didn't even list the best approach. I know that information security is a minefield so any advice is most welcome.

Martin Drozdik
  • 317
  • 2
  • 7
  • First clarify what "reliable" means. Just "can't be read by third parties" or something else, like "modifications by third parties can be detected" or "A can proof that some message was sent by B instead of A itself" (in that case, same key is bad) or... – deviantfan Jan 13 '17 at 23:39
  • @deviantfan I will edit my question to be more clear. – Martin Drozdik Jan 13 '17 at 23:48

1 Answers1

2

Let's compare the approaches that you are thinking of:

  1. A and B have the same self signed certificate.

  • If any party gets hold of this certificate, they can easily masquerade as any one of the two.

  • In future if you want to add new communicating parties, you will have to find a new way to identify and authenticate individual servers as all of them will have the same certificate.

The second idea is better than the previous one but scalability depends on the kind of implementation that you use.

  1. A and B have each their own certificate which is:
    self-signed; in this case A adds B's certificate to its list of certificate authorities and vice versa
  • It will be a huge problem to maintain this in the future. Ever time you add a new server, you will have to add it's certificate to all the servers that you want to communicate with. If you are planning to distribute these servers separately, then it will not be a pleasant experience for your customers.

signed by the other party; I believe that each party trusts itself.

  • Again you will run into problems with scalability. Adding new servers will require your existing servers to generate new certificates every time.

signed by me, a one-man certificate authority, using my private key.

  • According to me this is the best solution. You will be able to achieve your initial purpose of having a secure communication and it will be easy to scale as well. Each new server will have a certificate generated by the certificate authority which is trusted by the existing servers.

If you are worried about self signed certs v/s CA certs in terms of security, you can read this answer

Community
  • 1
Limit
  • 3,191
  • 1
  • 16
  • 35