0

The title may be a bit misleading so I will try to make this as clear as possible. We have several microservices that expose endpoints and they communicate to each other. They needed to authenticate each other so we used mTLS (Two way TLS) to secure the connection between them. The certificates are signed by a CA created by us so we make sure that only the certificates signed by this CA are trusted in this information exchange loop.

So far so good. We have yet another problem now. The app will be an open source app. And we will have a UI Client that will communicate with the above mentioned services through HTTPS. This UI Client will have a certificate of its own and will be part of the trusted certs. The problem is that when we ship the app with the certificate and the key, that could also give an attacker the right tools in hand to mimic the UI client and make calls that were not meant to be. The client will be dynamic, meaning that it can be installed in different (end-user) machines.

How can I make sure that the client is the right client and not some mimicked one?

P.S user will have to authenticate himself through the UI client and the User is able to create his own certificate chain (change the CA and create one of his on, I don't think that this is relevant but still..)

The stack is: C++ for the UI Client and Warp/Rust with C++ DDLs for the Server Layer.

Renis1235
  • 101
  • 3
  • *"How can I make sure that the client is the right client and not some mimicked one?"* - You can't. No matter if the client is open source or closed source, no matter which language or framework is used. There is simply not enough control over the client side that you can ensure that only your client is running. And you should never rely on such things. Always verify input, never blindly trust trust a client to send the correct data. – Steffen Ullrich Nov 19 '21 at 16:40

0 Answers0