Telepath Encryption for File Exchange

[stag-enterprises]

@stag-enterprises the intended solution is to tunnel it yourself, or generally access a secured instance over a VPN.

Despite that, it's a valid point, and I could certainly try to look into implementing the authentication functionality for encypting text based files. The biggest challenge with this approach is the performance overhead, because it would have to encrypt EVERY file. The least common denominator could be an amscript with an API token as you've suggested, but it could also be a config file inside the raw content of an uploaded auto-mcs backup. Since most of the functions that manipulate remote files are either blocking or async, this shouldn't be a huge problem. I am stumped as to how I might implement that other than wrapping the upload/download endpoints with a key exchange, like the login methods. If you have any suggestions from a methodology standpoint I'd love to know your thoughts!

The biggest issue I have with directly implementing HTTPS is that it makes it an order of magnitude more challenging to debug Telepath itself. Since I'm the only one working on this project right now, I don't feel confident in globally implementing a solution like that internally and being able to maintain it effectively. Additionally, HTTPS has overhead due to the encryption in the first place, which is why I wanted to implement it solely for authentication. Telepath is noticeably more responsive when using HTTP from my testing.

With that being said, I would like to have that discussion in another issue. I'd be happy to look into implementing file-only encryption with the current solution like you've suggested, but it likely won't be in this update.

Originally posted by @macarooni-man in #116

[stag-enterprises]

the intended solution is to tunnel it yourself, or generally access a secured instance over a VPN.

Yep, this makes sense. I would recommened adding this to the website though, just in case some beginner doesn't know this.

The biggest issue I have with directly implementing HTTPS is that it makes it an order of magnitude more challenging to debug Telepath itself.

I've had some experience in low-level network enginereeing and I might be able to make a PR; although I'm not too familiar with Python.

Additionally, HTTPS has overhead due to the encryption in the first place, which is why I wanted to implement it solely for authentication. Telepath is noticeably more responsive when using HTTP from my testing.

This is pretty suprising, HTTPS generally shouldn't be that much slower. I'm not sure how the Telepath API looks like internally, but doing something like a keep alive connection could boost performance by a lot.

[macarooni-man]

Really appreciate you opening another issue for this!

Yep, this makes sense. I would recommened adding this to the website though, just in case some beginner doesn't know this.

That's a great idea considering Telepath is designed to be attractive and accessible by people who aren't familiar with remote access. Additionally, that's why I'm pretty motivated to consider your suggestion because an optimal balance of security and convenience is really important for what Telepath is intended to solve.

I've had some experience in low-level network enginereeing and I might be able to make a PR; although I'm not too familiar with Python.

That's certainly great! You don't necessarily need to make a PR as I'm more than happy to work on implementing this myself. We can keep this conversation here in the issue if you're able to articulate your suggestions abstractly. Professionally, I do network administration so I have a good understanding of security and networking from a high level perspective, but other than making receivers/scrapers from REST API's Telepath is my first implementation/expirement of my own with connecting that experience with programming. I'm certainly open to suggestions if there are more secure or efficient ways to acheive my design philosophy, but I may not understand them from a low level programming perspective!

This is pretty suprising, HTTPS generally shouldn't be that much slower. I'm not sure how the Telepath API looks like internally, but doing something like a keep alive connection could boost performance by a lot.

Additionally, I'm not exactly sure when I tested this but it was a while ago, it could have also been before I implemented keep alive! Currently, Telepath caches a requests session in memory, and internally whenever the client requests data from an endpoint it returns the saved session to make a request with that instead of making a new one. It would likely be a lot easier to test this again. But I would prefer to implement what you suggested before since not everyone understands how to set up SSL and I think the least common denominator is important. Although with what you're suggesting compared to the current design I feel like it might be trivial to support now that you mention it.

[macarooni-man]

Opening a Discord feature request as well for ease of communication https://discord.com/channels/1186409550375563384/1329899921276670084

[stag-enterprises]

(this is just me thought dumping)

Assuming no performance barriers to HTTPS and that the only API requests made are simple GET/POST/etc... to the server, I imagine securing the connection could be done like this:

1. Each instance generates a X509 cert on first start, creating server.key and server.crt files
2. When a client connects to a remote instance, it queries the /certificate route using HTTP. The route returns the server.crt file, and the client caches the file locally.
3. The cert is hashed on both sides, and users are asked to compare them for security
4. Afterward, all Telepath API requests from the client to the server are encrypted using the cached server.crt
5. Pairing and other things continue as normal

[macarooni-man]

(this is just me thought dumping)

Assuming no performance barriers to HTTPS and that the only API requests made are simple GET/POST/etc... to the server, I imagine securing the connection could be done like this:

1. Each instance generates a X509 cert on first start, creating server.key and server.crt files

2. When a client connects to a remote instance, it queries the `/certificate` route using HTTP. The route returns the server.crt file, and the client caches the file locally.

3. The cert is hashed on both sides, and users are asked to compare them for security

4. Afterward, all Telepath API requests from the client to the server are encrypted using the cached server.crt

5. Pairing and other things continue as normal

Yeah if that's the case, it would take a lot more effort to rework full TLS support. I'm already generating a cert, I provided the current data flow in the Discord ticket if you'd like to take a look