2

I have an executable, and I have the SSL certificates and keys necessary to establish the secure connection. The application performs self-updating by downloading and replacing itself with an updated executable. What is the proper way to distribute these credentials when I ship my executable?

The keys themselves are used by the client to open a secure, persistent TLS connection to a server endpoint.

  • I could bundle them in a .zip with an installer script that places the key files where they need to go, but it is difficult to update those keys without shipping another .zip and installing over it.
  • I could encode and store the keys as strings in the binary itself. This makes updating easier, but even encoded key strings sound like a security concern. But then again, so is shipping them in a .zip.

The executable itself is not publicly available, rather it is distributed intentionally to end clients. All else equal, what would be a proper way to distribute these credentials?

Chris
  • 121
  • 2
  • Excellent question (+1), but more context would be helpful. Is your application a client, that needs to make a secure connection to a server, using a client certificate to authenticate with the server? – mti2935 Aug 01 '22 at 17:50
  • It is not clear for me what the role of the keys is in your application and thus how well they need to be protected and what from. If it is about authenticating the user then giving all users the same key is likely not a good idea in the first place, i.e. it should not be shipped with the application but users should be enrolled in a different way. If it is about protecting an API against misuse by having the app authenticate - there are several other questions about this topic. – Steffen Ullrich Aug 01 '22 at 17:54
  • The client opens a persistent connection to a server to continuously stream data. This stream is what the keys encrypt. Specifically, I'm using HTTP3 with TLS1.3 but I don't think that detail matters. – Chris Aug 01 '22 at 18:00
  • @Chris: Client side keys are used in a connection for authenticating the client against the server, not to open a secure connection. Just to protect the communication against some man in the middle no keys are needed in the application, but only trust into the servers certificate or the certificates issuer. So what role the keys you have exactly play? – Steffen Ullrich Aug 01 '22 at 18:03
  • @Chris See https://security.stackexchange.com/questions/110621/ssl-newbie-does-https-client-also-need-a-certificate – mti2935 Aug 01 '22 at 18:09
  • In your case there is no difference – gapsf Aug 01 '22 at 23:52

1 Answers1

1

I could encode and store the keys as strings in the binary itself. This makes updating easier, but even encoded key strings sound like a security concern. But then again, so is shipping them in a .zip.

If you ship your SSL keys with your application, you'll only be shipping your public keys. So, it is not a security concern if those keys are exposed, publicly or otherwise.

From a security perspective, it really doesn't matter how you ship your SSL keys. Just pick whichever approach makes sense technically, with the caveat that the key files should require just as much priviledge to modify as the application (e.g., don't store them in user data).

It is more common to rely on the CA system, rather than shipping the public keys to the end user. The primary security benefit of shipping the keys with your app is that you are protected from MITM by rogue or compromised CAs, akin to the protection offered by certificate pinning.

Brian
  • 962
  • 5
  • 17