In broad strokes, here is the problem at hand with its unusual combination of constrains, and the solution I’ve come up with.
While this question does involve cryptography, it isn’t related to the math and theory, rather the high-level use of a implementation in system, which is why I’m posting it in this exchange specifically.
The environment:
- About a dozen users on on a corporate LAN I have no control over.
- Every user has to interact with a legacy web app, also out of my control.
- I’ve written software that improves workflow by carefully orchestrating requests on behalf of each user (the whole point).
- Currently, each user has to run my program on their machines, where it reads their authentication token from the Chrome cookie store. This combination is a terrible solution as you can imagine, and will soon no longer be possible (and is already extraordinarily fragile).
- I do have control over one server on the network where I already host useful services. Obviously, it would make sense to move my software on this server centrally.
- As far as retrieving the users authentication token in a robust manner without arbitrary executables, I have found Chrome extensions can do so, of which I happen to maintain one the users already use.
The big question is about practical methods to secure the users authentication token in transit between machines, within the incredibly limited environment I have to work with.
- I cannot add to the OS certificate store, which is exclusively what Chrome uses on Windows. For this and other considerations, it seems off-the-shelf TLS is off the table from my perspective. Therefore, all communication will be over plain HTTP, but I would encrypt the contents where applicable.
- Let’s Encrypt CA does not sign for LAN IP’s.
- I cannot expose the server to the internet for the ACME challenge.
- I do have what I would consider a secure out-of-band method of providing each user with some form of pre-shared key.
- Chrome rightly does not allow extensions to send web requests with alternative certificates.
- I don’t want this system to be the weakest link in terms of security, therefore being able to at least mitigate MITM, replay and impersonation attacks on the LAN is a goal.
- [Edit] While I don’t have control over a DNS server, I do at least have a static IP reservation for my server, the address of which I would provide to my users out-of-band, and even if a malicious machine were to squat the address, the mutual authentication outlined below would catch it.
My proposed solution:
- Embed libsodium.js into the browser extension (client).
- Publish the server’s public key along with the network address to the users.
- Provide each individual user with a once-per-install pre-shared key out-of-band.
- The client and server respectively send each other signed (random value) challenges to validate each others identities.
- A shared session key is the SHA256 of both challenge values and the pre-shared key combined.
- The users authentication token and any other sensitive data is sent to the server when needed in a secret box created with the shared session key and vice-versa. Each message in both directions increment a counter unique to the conversation, which starts at a random value.
I’ve thought through this for a long while and made some prototypes, and so far it seems suitable, but I’d like a second opinion, if you are so inclined. Thank you.
8
This situation is pretty much what public key cryptography is intended for. Have a look at GPG encryption documentation for guidance, but you can use the SSL public key encryption libraries to do this.
You need a SSL key that you generate and keep the private key part on the server, and keep it safe so that it cannot be accessed. include the public key with your browser extension. This allows your browser extension to encrypt messages that only your server can decrypt.
You need your browser extension to create a user specific SSL key that it keeps the private key secure and encrypted, but freely passes the public key as part of requests to your server.
As long as all requests from your browser extension are encrypted by your servers public key, so that only your server can decode the request, and that such requests are all signed by that users private key so that the server can verify that the signature is valid then you have secure communication.
If your server receives a signed request from an SSL key that it does not know, then it sends a response back to the extension rejecting the message, and requesting the users SSL public key is sent.
8