Lethean Server 10k View

[Snider]

Lethean Server is a Work in progress client-side application backend that enables PWA's native capabilities, and the code is prototype-grade quality while testing our processes; I frequently look at my code in horror, so if you find the code offensive, feel free to improve, I certainly agree it needs work.

The server is written in TypeScript using Deno, a better nodejs that lets us compile self-contained binaries.

Lethean Application

A Lethean Application is a PWA (Progressive Web Application) loaded into the server installation via our GitHub-based package manager using our itw3.json package format. We can install external projects into our Desktop GUI using an itw3.json file listed in the central package repository. 

Co-operation/organisation with the developers of the project is not required; an example of this functionality is how we load in the CyberChef application by hosting the installation file here: https://github.com/dAppServer/app-utils-cyberchef/blob/main/.itw3.json and then listing this in the package manager source files here: https://github.com/dAppServer/app-marketplace/blob/d331efccab3f9cfa3daeca6d55734d2ea72ffed6/utils/index.json#L4

The Blue bar at the top is the Lethean desktop app. Once the menu is selected, in this instance, the toolbox icon, the server & GUI renders the externally developed application within the GUI using the static file server functionality.

The application files are loaded from the client's local hard drive. Unless the PWA uses remote servers once installed, there is no communication with remote servers, with CORS and caching included with the client-side server; Currently, there is no encryption or authentication taking place; however, that functionality has been created it just removed temporally to help development during this early stage.

The application root is http://localhost:36911/utils/cyberchef/index.html which can be served via a proxy or the VPN exit server, allowing encapsulation of web applications within a SASE use case; in theory, this could be an external service on an intranet or internet service from within the corporate firewall / secure data environment as per company polices.

Once the authentication is put back in, all the requests and responses will be encrypted payloads allowing transmission over cleartext or other public channels; adding TLS would not be required and certainly not designed to be required.

Authentication

Auth and encryption are handled using an encryption handshake; either the Lethean server can decrypt a users request to process a response, or it can not; likewise, the response is encrypted to the user's public key, so only decryptable by the user it was designed for. The user system uses OpenPGP and Quasi Entropy usernames to hide the source data while maintaining reproducible hashes; DNS, an additional abstraction hash is used so that public-facing IDs (DNS) do not match the system hash, and those hashes do not reflect the input text; due to Quasi Entropy the sha256 hashes won't be listed in generic rainbow tables and the entropy ruleset can be adjusted per server installation/organisation to remove hash clash between users.

One of these is "snider", and the other is "test" the test suite for this is the best place to dive deep into the process and is here: https://github.com/dAppServer/server/blob/main/test/auth/rest.test.ts 

There is quite a lot of room for improvement here; the above screenshot is my dev setup; in a SASE deployment, the user .key files wouldn't exist as they would be on the client machine unless Lethean Server is being used as a backend authentication and encryption provider to a traditional SaaS application using remote file storage with per user encryption requirements(as an example).