Introducing OpenZiti BrowZer
Simple secure access — to any private web app — based on trusted identity — using only a browser.
I am pleased to introduce you to
BrowZer, a new group of open source components that collectively enable you and your organization, enterprises and self-hosting enthusiasts alike, in the cloud or at home, to operate private-to-the-internet web applications while still easily providing secure access for your authorized internet-based remote users.
Z in this article's title, within the word normally spelled "browser", is not a typo. It is a purposeful indication that we are bringing you a solution, unique in today's technology offerings, for securing browser-based applications. This solution is built as part of the OpenZiti project.
OpenZiti enables developers to embed secure networking into their applications, as code. With BrowZer, we extend that revolution by also enabling developers to automatically embed zero trust networking in the browser, transforming it into a full-fledged OpenZiti client.
In this context, private doesn't mean invite only. Here, private means the web application is dark — with no open incoming ports on your cloud instance — nor any port-forwarding on your home internet cable modem/router.
And while your web application will be invisible to, and thus protected from, malicious attackers on the internet, BrowZer still facilitates simple and secure access for remote users that you authorize. And it does so without requiring your users to install any additional software on their client-side laptop, tablet, or mobile phone. Again, all they need is the browser they already use every day.
Also noteworthy is that BrowZer places no burden upon web application developers to first instrument or otherwise make any modifications to the web application itself in order to enable remote access to its dark deployment.
This is a great enabler. For example, if you are operating a web app licensed from a 3rd party that you want to make dark (e.g. Mattermost), and you can't make alterations to it, there's no problem. The same goes for a web app you can alter, but elect not to.
BrowZer has you covered because it does the necessary Zitification instrumentation of your web application automatically, on the fly, as it is being loaded from the web server to the user's browser. It's what I call touchless-Zitification. More details on how this is accomplished are discussed below.
OK, that was a mouthful, so let's unpack what was just said.
Traditional Web App Security
To help you better understand how BrowZer works, and why we are building it, let's first consider an example that highlights the traditional challenges that can occur when remote users require access to a critical web application located in a private network.
Usually, some kind of gateway bridges access into a private network. For example, the gateway could be a VPN or an SSH bastion host. Both solutions offer varying degrees of security, but, the side effects might not be acceptable.
This traditional access model is not well suited for cloud-native highly ephemeral environments (like K8S). Also, scaling this type of solution as company workforces and infrastructure grows or fluctuates also creates substantial pain points and complexity for administrators.
Speaking of pain, remote users typically dislike or experience technical struggles installing, configuring, and using VPN software on their (sometimes personal) laptops and mobile phones.
Let's not forget that once users gain access to these private networks using traditional access models, they can access any system on the network, and not just the intended target. The dangerous follow-on is that if the credentials used to access the VPN or SSH host fall into the wrong hands, a malicious actor could access the entire network.
Traditional workflows typically place a firewall inside private networks that restricts what users have access to in order to safeguard against this risk. However, managing internal firewalls is time-consuming, tedious, error-prone, and wasteful, when the system granting access should have followed the principle of least privilege from the outset.
Modern Web App Security via BrowZer
BrowZer's mission is to simplify workflows involved with providing zero trust access to private web applications while simultaneously reducing the attack surface associated with traditional solutions.
With OpenZiti in general, and certainly with BrowZer, access is based on the trusted identity of the user, rather than their network location. The user first authenticates to the network, then connects to the network, and only then, based on their assigned roles, can they connect to web applications made available to them — with role-based access controls (RBAC).
It bears repeating:
BrowZer enforces a pattern of authenticate-before-connect and the principle of least privilege for your web applications.
Trusted identities and roles are a core principle in OpenZiti BrowZer. They define which users are allowed to connect with which specific set of web applications.
For example, with BrowZer, you could grant only developers access to connect to a Jenkins web app and grant only HR members to a payroll web app, even while both web apps are operating within the same private network.
This model allows BrowZer to define logical sets of web applications and removes the brittleness associated with static IP addresses.
The diagram below depicts how various components connect to each other in a BrowZer deployment.
Although this diagram shows the target web app example is Apache Guacamole, BrowZer supports any web app. If you are unfamiliar with Guacamole, it is an open-source RDP, VNC, and SSH gateway. And yes, BrowZer supports HTML5-based RDP.
Note that my upcoming blog articles will do deep technical dives into BrowZer RDP support, so be sure to subscribe to this blog to receive further educational materials
Now let's discuss the various BrowZer components.
Authentication in a BrowZer Environment
Below is a (simplified) diagram depicting the network-auth flow from user to a web application in a BrowZer environment.
You'll notice that similar to the traditional model, there is still a gateway (more details on that below). But with BrowZer, the user doesn't provide a unique VPN credential or SSH key.
Instead, users need to perform a single sign-on (SSO) that provides a strong assertion of the user's identity.
BrowZer requires that an Identity Provider (IdP) be associated with the network. Which IdP is used is up to you. It could be ADFS, AzureAD, Okta, Auth0, ...whatever.
You can even enable MFA if you like. This is pluggable by design.
The example in the above diagram shows BrowZer using Auth0 which in turn federates out to Google for authn, but BrowZer doesn't care who the IdP is. It uses OpenID Connect (OIDC) protocol to integrate with your IdP. Bring whatever your favorite or existing solution is. BrowZer just needs your web application users to be able to prove who they are.
While there are no burdensome VPN credentials or SSH bastion host keys to manage, BrowZer does involve a little upfront administration in the Ziti network to inform the control plane about the IdP. Note that my upcoming blog articles will do deep technical dives into BrowZer-IdP integration, so be sure to subscribe to this blog to receive further educational materials
With a small amount of network admin work out of the way, the user-facing flow that BrowZer enables for your dark web application is intentionally designed to be very simple, and friction-free.
On the client side, it will look like the following:
open your favorite browser (on a laptop, mobile phone, tablet, etc)
surf to URL representing dark web app (see discussion of gateway below)
perform an SSO
enjoy using the dark web app
BrowZer authenticates and authorizes web request flows, and maps users to web applications at a logical service level. This is important because it lets you elevate from the details that are dynamic — like IP addresses.
The BrowZer Gateway (Ziti HTTP Agent)
As mentioned above, BrowZer environments have a gateway. But unlike traditional approaches (like VPNs) where all network traffic from all remote users funnels into and is concentrated within a single gateway, BrowZer takes a different, and novel approach.
In an OpenZiti BrowZer deployment, the component that acts as the gateway is something we refer to as the HTTP Agent.
The HTTP Agent has the following responsibilities:
Ensure all incoming HTTP requests have an established BrowZer-Session, and if they do not, to redirect out to the IdP so the user can authenticate themselves
Inject a component into the browser — something we refer to as the Ziti BrowZer Runtime (see discussion of the ZBR below)
Respond to requests from the now browser-resident-ZBR to load other BrowZer components — namely the Ziti BrowZer Service Worker, and the Ziti BrowZer WebAssembly — to complete the Zitified web app boot-strapping process.
The Ziti HTTP Agent then gets out of the way.
The Ziti BrowZer Runtime (ZBR)
Note that my upcoming blog articles will do deep technical dives into the Ziti BrowZer Runtime, so be sure to subscribe to this blog to receive further educational materials
For now, just understand that the ZBR will intercept all
WebSocket requests, as well as some HTML5 events.
If something is happening in the browser that requires contact with the dark web app, the ZBR is responsible for facilitating it.
All HTTP requests are examined, and those requests targeting the dark web app are transparently routed directly from the browser to a Ziti Edge Router on the network, where the requests will ultimately be delivered to the dark web app residing inside the network.
If an HTTP request targets a resource that is not associated with the dark web app (e.g. a POST to Google Analytics), the ZBR will simply let it go to the raw internet for processing.
The Ziti BrowZer Service Worker (ZBSW)
If a DOM request targets a resource that is not associated with the dark web app (e.g. a resource load from the JsDelivr CDN), the ZBR will simply let it go to the raw internet for processing.
The BrowZer WebAssembly
BrowZer does some heavy lifting involving dynamic PKI (key-pair generation, CSR generation, x509 certificate acquisition), it also does its own mTLS handshakes and message encrypt/decrypt.
Yes, you heard that right. BrowZer does not use the browser's native ability to do mTLS.
The reasons for this revolve around the necessity to employ x509 certs to accomplish trusted connections between the browser and the Edge Router(s). Since nothing can be installed on clients ahead of time, including certificates, the certificates are acquired from the control plane dynamically (a ZBR-to-Controller conversation), and the certs are subsequently used by mTLS logic within the ZBR.
Translation: double encryption for your web app traffic as it traverses the network.
Do you host a web app and want to be invisible to malicious intruders?
Do you want your users to have easy access from anywhere with no additional software on their client devices?
Do you want to do all this without making any modifications to your web app?
If you are nodding yes, then we hope you'll try BrowZer.
Please stay tuned to this blog for more information concerning how you can get started.