Networking and Security

A regular connection works on a very simple custom protocol built on top of TCP.
On top of it goes an encryption layer.

Connections are encrypted by default using RSA (4096-bit), ephemeral ECDH, and AES (256-bit).
Encrypting a connection goes as follows:

From the connection receiving/listening side:

  1. Check incoming remote RSA public key.
  2. Send local RSA public key.
  3. Receive, decrypt, and derive AES key from received "Accept" message with remote ECDH public key, save received random nonce.
  4. Send local ephemeral ECDH public key and random nonce - encrypted with remote RSA public key.
  5. Receive back nonce using the derived AES key and check if its the same as previously sent.
  6. Send back remote nonce using the derived AES key.
  7. Encryption completed.

From connecting side:

  1. Send public RSA key.
  2. Check incoming RSA public key.
  3. Send "Accept" message with a new ephemeral ECDH public key and random nonce - encrypted using server public RSA key.
  4. Receive, decrypt, and derive AES key from received ECDH public key, save received nonce.
  5. Send back received nonce encrypted using derived AES key.
  6. Receive back our nonce using the derived AES key and check if it's the same as previously sent.
  7. Encryption completed.

From that point onwards, all messages are encrypted using the derived AES key.

This approach ensures secure and trusted connections.

  • Someone without a trusted RSA key will not go past the first 2 steps.
  • It is not possible to impersonate someone without their private RSA key that is never sent over the network.
  • Man-in-the-middle and replay attacks are prevented by using cryptographically strong random nonces on both sides.
  • Forward secrecy is achieved through the use of ephemeral ECDH keys / a "ECDH Key Exchange".

Inspired by the way SSH handles connections, without a way to use passwords (the least secure option).

User identities are RSA key pairs.

Ephemeral ECDH ensures that even in the case of someone's private RSA key being compromised, past communication can not be decrypted since the EC keys are forgotten.

Keep in mind that since someone with your private RSA key can impersonate you, they can just as easily get access to what you have access to.
This only protects against decrypting past communication.

An additional benefit is that no bots currently exist that use this protocol, there is no scanning the entire internet and attempting to use some sort of vulnerability or to scrape content like it is the norm with websites.

Since there is no way of accessing a server without a valid key pair, it is pretty much pointless to try outside of DDoS attacks to exhaust system resources by attempting to connect over and over and making each step take as long as it can.

Encrypted connections have a set timeout that simply closes the connection if it doesn't manage to open in time.

I am no security expert, this is just the best solution that I understand after many iterations and a lot of research.

If you know of a way to break this process and gain unauthorized access, please let me know.
Contact

Permissions

Once the connection is established, we reach the application-level permissions.

The server will not simply allow any command to be executed by anyone.

There are user management and access management sections in the admin panel to allow for precise access control.

Updates

Updates are distributed through dedicated "Package Distribution Servers".

They take built packages/releases and allow users to check which versions are available and download them.

When a new release is built, a manifest is created that contains all information about it.
The manifest contains a list of all files, their paths, hashes, and sizes.

Once the manifest is written, it is signed using the private part or an RSA key pair (the release key).

All builds of the installer, updater, and player have the public part of the key baked in, and use it to then verify that what was downloaded/installed is valid and has not been tampered with.

This way, as long as you get the first version from a legitimate source, you will only be able to download legitimate updates through the built-in update system.

As long as the private release key doesn't get leaked, I will try my best to never let that happen.

In the worst-case scenario, when a key does leak, or there is a suspicion that it could be compromised, there is a way to rotate it.
This will probably also be done even without a leak as a good security practice and to ensure that the mechanism keeps working.

For someone to distribute a malicious update, they need the key and access to a distribution server that people use.
A key allows for releasing potentially malicious releases, and a server allows for distributing it to existing users.