I work on an open source project called OpenZiti. We created a ‘clientless’ endpoint which allows a user to access a web app - in this case, Odoo - from their browser with a public SaaS type experience (i.e., they land on a web page, authenticate to ID, get access to the app without loading a local client) while the web app, Odoo, sits in a completely private network. No need for VPNs, no complex FW rules or inbound ports.
The following guide was created using the free tier of our commercial product - https://support.netfoundry.io/hc/en-us/articles/18953824082189-Accesing-ODOOwith-BrowZer. Soon we will release the fully open source, self-hosted guide.
this is awesome and your marketing’s awesome. whoever figured out that there are people using odoo that don’t trust it enough to leave it exposed to the internet was spot on!
If you want to keep Odoo in a private network (so that it is more secure) and let users access it, they need to be able to access the private network, which is commonly done using a VPN. This has (at least) 2 problems:
- (1) the VPN concentrator has publically exposed ports and thus could be exploited as well as most VPNs not doing least-privilege, micro-segmentation etc
- (2) users need to have VPN clients installed and working on their devices. Usage of this VPN may also deteriorate performance
We can solve (1) by using a zero trust network overlay. It allows us to close all inbound FW ports and make Odoo ‘invisible’ - read my blog on comparing zero trust using Harry Potter analogies - https://netfoundry.io/demystifying-the-magic-of-zero-trust-with-my-daughter-and-opensource/.
It is harder to solve (2) as all zero trust overlay networks required a client & strong identity on the users devices trying to access Odoo… until we created a ‘clientless’ endpoint. In practice, it’s not ‘clientless’; only it seems like it to users. We achieve this by having the user authenticate to their IdP and as the IdP returns the strong identity (x509 certificate), we also load an endpoint into the users browser tab running in memory. This allows the browser tab to make E2E encrypted connections to the zero trust overlay network. The Odoo app makes an outbound connection into the overlay network as well. Therefore, we can solve (1) and (2) using completely open source software.
So in this case I guess you’re trusting the browser? Or do you have an in-browser runtime that you believe to be secure and inviolable?
As the creator of BrowZer, I’ll be the first to admit that it can be difficult to quickly explain how it works – but here is a high-level overview.
There are multiple components to the system, and one piece, which we refer to as the Ziti BrowZer Runtime (or ZBR for short) is probably the closest to what you alluded to.
The ZBR is a mixture of JS and WebAssembly. The ZBR is dynamically loaded into the browser (description of how it’s loaded is skipped here for brevity), and the ZBR handles the various chores related to IdP interactions, PKI work (keypair generation), negotiations with the Ziti Control plane, and all necessary mutual TLS (mTLS) handshake & encrypt/decrypt work required to connect to the “dark” Odoo server over the Ziti overlay network.
While BrowZer doesn’t mistrust the browser, it also doesn’t rely on the browser to handle any of the low-level i/o or certificate management related to the mTLS security that is fundamental to Ziti.
The ZBR does all the mTLS x509 certificate and mTLS encrypt/decrypt work at the JS runtime level. The TLS primitives present in the browser aren’t involved in a BrowZer world.
As far as inviolability goes, we can say that penetration testers respected in the industry were consulted, and they were unable to hack into a web server protected by BrowZer.
I’m more concerned about injecting into the ZBR. So you’re using the wasm VM for networking? And how do you validate that or the js runtime? In a normal circumstance a secure endpoint tool can ensure that the host connecting to the website hasn’t been compromised but that option isn’t available in a public browser situation. An unlikely attack vector but if we’re talking about a tool designed for this then I’m curious how it’s addressed.
Can you elaborate on the concern about “injecting into the ZBR”, as well as “validate the JS runtime”?
I’d like to know what “secure endpoint tool” you have in mind. Perhaps getting an understanding of that will help me also understand your above concerns and how they are mitigated in a non-BrowZer env.
WASM vm’s do not have networking, so no. ZBR leverages wasm for all PKI and TLS needs.
so if I’m using a normal PC, let’s say one managed by corporate IT, it’ll be locked down to a degree, anti-virus, root kit detection, VPN, &c. A public PC won’t have that protection and could have an adversary with access to install hidden extensions to a browser.
Anything running in a browser is going to be dependent on the security of the browser JavaScript engine and wasm stack.
Theoretically, in a zero trust environment, it’s tricky to build a secure channel when the system function calls themselves could be compromised.
The “managed/locked-down by corp IT” example perfectly fits BrowZer as the user is likely prohibited from installing any new software (such as the Ziti Desktop Edge) on the device. The user can still reach the dark Odoo site via BrowZer however, because the device would certainly have the ubiquitous browser, and that’s all that is needed on the client side. All necessary x509 artifacts are created/managed dynamically/ephemerally by ZBR.
Now, in the “public PC” example, if the device was already pre-compromised somehow, there are no features in ZBR tasked with a search-and-detect of some malicious Chrome extension (for example) and then mitigating it.
If you have a specific example(s) of the hypothetical you are concerned about, let us know and we can consider looking at it in the “lab”.
Now, in the “public PC” example, if the device was already pre-compromised somehow, there are no features in ZBR tasked with a search-and-detect of some malicious Chrome extension (for example) and then mitigating it.
and that is the way it should be. Such a feature would give a false sense of security to developers while being unreliable at best.
ah, my apologies. I interpreted “public SaaS type experience” incorrectly. carry on, good work, sorry for the disruption 
