All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
[RELEASE] Zero-Trust-Lite: Tiny & Secure Zero-Trust Gateway for your VPS
[RELEASE] Zero-Trust-Lite: Tiny & Secure Zero-Trust Gateway for your VPS
Hi LET community,
I'm releasing a project I've been working on: Zero-Trust-Lite.
It’s a high-performance, ultra-lightweight reverse proxy built in Go, designed to protect your internal web services. It’s perfect for low-resource environments (VPS) where you need more security than a basic Nginx Auth but don't want the bloat of enterprise solutions.
Pre-compiled binaries and documentation are available on GitHub.
🌟 Key Differences & Features
- Proprietary 8-Digit TOTP: Unlike standard Google Authenticator (6-digit), this uses a private TOTP implementation for enhanced security. (Authentication tools/methods provided in the documentation).
- Smart Session Management (IP Whitelist based): The IP Whitelist isn't just a firewall—it acts as a session duration controller. If a user's IP is in the whitelist, they get extended session persistence, significantly improving UX while maintaining strict security for unknown IPs.
- Built for "Low-End" Boxes: Single binary, zero dependencies. Typically uses <10MB RAM.
- Admin Approval Workflow: Designed for scenarios where you need to grant access to others without revealing your private TOTP secret. Third-party users can submit an access request, which you can then securely approve via your hidden Admin Panel.
- Robust Protection: Built-in AES-256-GCM cookie encryption and an intelligent brute-force auto-blocking system.
- Full WebSocket Support: Works seamlessly with web-based terminals (ttyd, wetty) and real-time dashboards.
📦 GitHub Repository & Downloads
I’ve consolidated all configuration guides and binary releases on GitHub.
Project Hub: https://github.com/Usagi537233/Zero-Trust-Lite
In the GitHub README, you will find:
* Custom TOTP Guide: How to use the proprietary 8-digit token system.
* Whitelist Configuration: How to set up remote/local IP lists to control session TTL.
* Multi-Instance Setup: Managing multiple backends with a single JSON config.
* Security Specs: Details on failed-attempt thresholds and blocking durations.
🚀 Quick Start (CLI Mode)
After downloading the binary from the GitHub Release page, you can start it instantly:
./zero-trust-lite -L :8080 -backend http://127.0.0.1:9000 -token YOUR_PRIVATE_SECRET
Comments
Okay, let's see:
Doesn't sound like zero trust to me, you have to trust the external provider
Right! Nothing says professional website like numeric $1/year xyz domain.
Further link called "Introduction" from that professional site leads to fully Chinese page:
https://ipsafev2.537233.xyz/information.html?
I wouldn't trust this random project even with random personal blog, it's highly suspicious.
On TOTP: The TOTP implementation is a proprietary protocol designed for this specific architecture. If you don't trust the implementation or the security model I've built, you are perfectly free to not use it. Nobody is forcing this tool on you.
IPM vs IPSafeV2:
You seem confused by the links. IPSafeV2 is the free version available to everyone. IPM (ipm.537233.xyz) is simply an upgraded version with a more polished UI and advanced customization options. It's the same core engine, just a different feature set and interface.
On the ".xyz" Domain & Documentation:
Judging a security tool by its TLD price or the initial language of its documentation is a logical fallacy. Many lean, high-performance tools start on affordable domains. While the extended documentation is currently being translated into English, the core logic—which is what actually matters—is a standard, standalone Go binary.
I am not asking for "blind trust." I am providing a high-performance, low-memory (<10MB RAM) gateway for specific use cases. If a $0.99 domain is your primary technical barrier to evaluating the actual AES-256-GCM implementation or the proxy logic, then you are simply missing the forest for the trees.
I’m here to provide a lightweight alternative for the community. If you have a technical critique regarding the AES-256-GCM encryption or the proxy logic, I'm happy to discuss. Otherwise, let's stick to the tech.
Why reinventing the wheel when it is already an open battle tested protocol ?
You are fundamentally confusing "Zero Trust" with "Self-Containment."
Identity Over Location: The core principle of Zero Trust is "Never Trust, Always Verify." It’s about verifying identity regardless of where the request or the authentication source comes from. Relying on an external Identity Provider (IdP) is actually the industry standard for ZTNA (Zero Trust Network Access) solutions like Cloudflare Access, Google BeyondCorp, and Okta.
Security Decoupling: By using a proprietary, remote TOTP binding model, the security secret is decoupled from the local server. If your VPS is compromised, the attacker still doesn't have the TOTP secret. This effectively prevents a single point of failure—a design choice, not a flaw.
Proprietary Logic: This is a proprietary 8-digit TOTP protocol designed for specific high-security needs. If you don't trust the model or the protocol, you are perfectly free to not use it.
I have Zero Trust to this AI slop of code.
Because if a standard TOTP secret leaks, it's a security nightmare—I'm using a proprietary 8-digit protocol to prevent generic tools from being used to exploit stolen tokens.
free to not use it.
What will happen to me, if your ipsafev2.537233.xyz domain goes down to China town? Or CF will go down?
why do we fly to the moon to see what's there, when E.T was here and told us all about it ?
UI is vibecoded, definition was vibed, answer are vibed
Let answer this.. vibed answer with.. my yapping pawer
What a non sense is this, blablabla Trust blaba bla through Logic, then give us with black box, github link with single unknown binary
Trust are based on mutual understand, not logic, its who are you, and your other credentials that make people "trust" you,
If you think trust is earned through Logic, you will never get a Wife
Shut it, Its called suspicious by association, we dont care about domain, nor the language, what we care is the the content, who own the content, and what is the content
.xyz is often used for malicious intent, and Im not installing things in Chinese, because of I DONT SPEAK CHINESE
Your last argument:
What Implementation? What Logic?
We only get a blackbox binary!
I dont give a fuck about implementation when I cant see the implementation, AES bla bla bla
you taking a forest when you give us a dying tree
Relying on an external Identity Provider (IdP) is actually the industry standard for ZTNA (Zero Trust Network Access) solutions like Cloudflare Access, Google BeyondCorp, and Okta._
Did you read NETWORK ACCESS, They give us VPN NETWORK to connect, to be able to verify AND
They are big name, Its Industry Standard to Relying to Someone who control half the internet, Its dumb standard to relying someone random in the Internet
Comparing yourself to a company it already "Logical Fallacy"
Secret leaks, thats so idiot things to do, just because wooden door can break you reinvent shit to install iron door
Just fucking revoke the Key, when you already know its compromised, who in the right mind keeping other in.
Also your iron door can be decompiled, your "proprietary" is not "proprietary"
It seems you’re more interested in "vibes" and personal attacks than actual technical evaluation, but I’ll address the few technical points hidden in your "yapping":
On Trust & Open Source:
In the security world, "Don't trust, verify" is the rule. If you don't trust a compiled binary, don't run it. It’s that simple. I provide a lightweight, high-performance binary for users who value low resource usage (<10MB RAM) over the bloat of enterprise tools. If you need source code to feel "safe," there are plenty of heavy, open-source projects out there that will eat 500MB of your RAM.
On "Black Box" vs. Logic:
The "Logic" I refer to is the architecture. The AES-256-GCM and the proxy logic are the standard mechanics of the tool. Just because you can't see the source doesn't mean the logic doesn't exist. You’re calling it a "dying tree," yet it solves a problem that your "standard" tanks can't solve on a low ram VPS.
On "Secret Leaks" & The Proprietary Door:
You say "just revoke the key." That assumes the user knows they are compromised immediately. My proprietary 8-digit protocol is a proactive defense layer, not a reactive one. It prevents generic brute-force and phishing scripts from working out-of-the-box. It’s an iron door for people who don't want to rely on "just revoking it" after the damage is done.
On Comparing to Big Names:
I’m not saying I am Google or Cloudflare. I am stating that the model of external identity verification is a proven industry concept. Attacking the TLD or the language instead of the network model is exactly the "suspicious by association" bias that keeps people from discovering efficient tools.
Bottom line: This tool is for people who want a fast, tiny, "deploy-and-forget" security layer for their low-end boxes. If you are terrified of binaries and need a "big name" to hold your hand, this isn't for you.
Keep your "vibes," I'll keep the performance. Cheers.
Because if everyone has E.T.'s map, then everyone knows how to hijack the ship.
The reason I "reinvented" this is simple: To prevent token leakage from becoming a total compromise. In a standard 6-digit TOTP setup, if a secret is leaked, anyone with a generic authenticator app can instantly take over. By using a proprietary 8-digit protocol, I ensure that even if a token is exposed, it's useless to standard tools and scripts.
I’m not flying to the moon for the view; I’m building a vault that doesn't use a master key everyone already has a copy of.
Apart from the points that are pointed out here.
I am more concern about the implementation itself, unlike the big players, I don't see any documentation on how this proprietary TOTP is implemented and how secure this product is.
When it comes to security products, the product will look more credible if the implementation is peer reviewed(eg open source) or independently audited.
This is because no one is going to use a security product if they have no idea how it works.
At this point this just sounds like a product whitepaper masquerading as a tutorial.
this screams ai slop. use headscale or firezone, not this crap
ban this post @admins
This guy bragging about technical evaluation when he talking about unknown binary
And some of them are lightweight
Never mind talking to this, the llm doesnt even know what vibe code mean, neither this guy
Just copy paste answer from llm, pretty generic
I completely agree with you. In a perfect world, every security tool should be open-sourced and independently audited to build maximum credibility.
However, the current design choice to keep the 8-digit TOTP protocol proprietary is a deliberate trade-off based on a specific threat model: preventing immediate exploitation after a token leak.
I understand this is a "black box" for now, which is why I don't expect everyone to adopt it immediately. I am focused on providing a lightweight alternative for users who prioritize this specific defense-in-depth approach over enterprise-standard transparency.
As mentioned before, if I ever sunset the service, the logic will be released to ensure no one is locked out.
This is a massive positive point. Give someone the secret and they can use any RFC 6238 compliant app on any device they have, they're not just limited to whatever app you produce, possibly with bugs, and only on whatever platforms you think are worth supporting.
If a secret is leaked, revoke the permissions associated with the leaked secret, and the access will be revoked automatically at the next time step.
Also, if you're leaking secrets, you have bigger issues anyway. You haven't solved these issues with your solution.
I completely agree—standardization is the greatest strength of RFC 6238. The ability to use any trusted app and the ease of revoking keys are why it’s the industry gold standard.
However, the design of this tool stems from a different security philosophy:
I see standard TOTP and this proprietary approach as two different tools for different needs. One prioritizes universal compatibility, the other prioritizes an extra layer of defense against token-based exploits.
One of the basic tenets in security is that security by obscurity is not security.
If by some miracle your system gets used by anything worth breaking, and the secrets leak, the attackers will just look at the source or spend a couple of hours disassembling your app to figure it out. All you've done is create a false illusion of security, which will mean you let your guard down to the real issue - how it's possible to leak your secret in the first place. If an attacker has access to your secret, you've already seriously failed.
@ralf said:
Well the reason is obvious, over validated by LLMs
I have zero trust in this
Just wait until the LLM give next plausible answer
You make a fair point about reverse engineering, but even if an attacker de-compiles the binary to understand the algorithm, they aren't "in" yet.
My goal isn't to create an "unbreakable" mystery, but to ensure that an attacker must bypass multiple, independent layers: the proprietary protocol, the specific secret, and the rate-limiting defense. In security, every extra step we force the attacker to take is a win.
Then don't use it. My tool isn't a charity project seeking validation from everyone on the internet.
Nobody is forcing this on you. If you need a "big name" and source code to feel safe on your $10/year VPS, this isn't the tool for you.
Exactly like same with every stand TOTP implementation.
As I said, if you're leaking the key / secret, you've already lost.
Here is a suggestion why WebAuthn is the superior choice given all the points you have raised about the weakness of leaking your secret:
1. Phishing Resistance (The "Origin" Check)
The TOTP Flaw: If you are tricked into visiting facébook.com (a fake site) and type in your 6-digit code, the hacker can instantly relay that code to the real facebook.com and log in.
The WebAuthn Fix: Your browser and security key (or phone) look at the domain. If the domain doesn't match the one where the key was registered, the device refuses to sign the request. You can't be "tricked" into giving away your credentials because the hardware does the checking for you.
2. No "Shared Secret" to Leak
The TOTP Flaw: TOTP relies on a symmetric key (a shared secret). Both you and the server have the exact same "seed." If the server's database is hacked, every user's 2FA secret is exposed.
The WebAuthn Fix: It uses Asymmetric Cryptography.
Public Key: Stored on the server (useless if stolen).
Private Key: Stored inside your device's "Secure Element" (a physical chip). It never leaves your device, and the server never sees it. Even if the server is breached, there is no "secret" for the hacker to take that would allow them to impersonate you.
5. Anti-Brute-Force
WebAuthn (Passkeys) doesn't just "prevent" brute force; it makes the entire concept of brute-forcing an account mathematically impossible. Unlike an app that just shows a code, WebAuthn requires a "Handshake" (Challenge-Response) between the server and your physical device (phone or YubiKey) on the client.
With WebAuthn, there is nothing on the server to brute force.
3. Protection Against Malware
If your computer has malware, it can easily "scrape" a TOTP code from your screen or memory. This includes your proprietary TOTP protocol. With WebAuthn, the cryptographic signing happens inside a separate, isolated hardware chip. The malware can ask for a signature, but it cannot "steal" the key itself.
(Generated by Gemini Flash 3, because that's about the same respect this thread has given me)
You could add that to any standard TOTP verification process anyway. That doesn't require adopting a proprietary everything.
Look finally the LLM hallucinating how to answer, we didnt ask that and the llm ask big name
:kek: