1️⃣ Browser Isolation as a Jumpbox for Private Networks

Hi, my name is Abe Carryl and welcome back to Cloudflare TV and the Cloudflare One Week.

Cloudflare One week is a week where we make a lot of different product and feature announcements about our Zero Trust Suite.

And with me today is Tim Obezuk from the Browser Isolation team.

And I wanted to quickly pass it over to Tim to you to talk and kind of intro us on what we're going to talk about today and yet what we're announcing today related to Browser Isolation.

Cool.

Thank you, Abe. Hi, everyone.

I'm your product manager for Cloudflare's Browser Isolation product.

And today we're going to be talking about private IP connectivity with the remote browsers.

And I'm really thrilled that I've been joined with Abe Carryl today because he's the product manager for Cloudflare Tunnels.

And what we're announcing today is a deep integration between these two products.

So it's going to be a fun conversation.

So jumping into it, with Browser Isolation and Cloudflare One and Zero Trust, essentially what we're doing is we're taking what used to be these legacy combinations of on-premise boxes and legacy architecture like Secure Web Gateways, VPNs, virtual desktops, and building a cloud-based service to protect networks for users wherever they are working.

Our data lives in SAS apps, users are working from home, people are connecting from everywhere, from anywhere to anywhere.

And having users hop in through on-premise networks doesn't make sense in this modern world.

And today we'll be double clicking more on how people securely connect to internal resources and how VDI has historically been a solution there and where Browser Isolation is starting.

It is replacing those use cases for a lower cost, more efficient solution.

Yeah, I love that.

That's a great intro and I think one of the things that I really liked, I had a chance to read your blog and I love the format of that blog.

So if you haven't had a chance to check out the blog, please do read it, like and retweet, of course.

But I think that I'm going to try to somewhat just follow the outline of that blog.

And to do so, I want to take a step back and talk a little bit about what remote browsers are to begin with and why we want them to connect to private networks.

What value does that kind of serve and what was the use case that we had in mind when we originally thought about joining these two things together?

Yeah.

So, Cloudflare's been delivering Browser Isolation on our network for a couple of years now.

And when we started doing it, the first problem we were looking to solve is just safe browsing.

So every time you go to a website in your computer, your browser is downloading this untrusted bundle of code to your local device and executing it.

And if you were to have a modern application go through a security approval process and that application's behaviors were described as downloading code from untrusted sources, those untrusted sources can go out to other untrusted sources and executed on a local device, that would never pass a security review today.

But it's extraordinary that Web browsers have evolved into the business, and they do this every day and we accept it.

So to mitigate the risk of malicious code within...

executing on our devices, we're isolating browsers at the edge of our network so that if there is any malicious payload that is executed in the remote browser and it safely terminated at the end of their session and destroyed and not on the user's device and potentially compromising anything they're connected to.

So that's where we started.

But one of the really interesting things about isolating the browser is, yes, you can protect the user from a malicious website that they're browsing, but you also get an enormous amount of control over how users are interacting with the website they're on top of.

And this is because all user interactions like typing a letter, scrolling on a page, copying and pasting content, all of that is broken through the remote browser before it hits the web page itself.

And this puts us in a really powerful position to protect sensitive web applications while they're actually loaded and in use on the user's device.

For example, we can disable printing, disable copy and paste, file downloads, things you wouldn't typically be able to do on a local device where all of that is just, it's downloaded to the user's device and exists there by the time they've already opened it.

Interesting.

And so now that we know a little bit about the history of remote browsers and and why we want to connect them to private networks, can you tell me a little bit about how that actually works from an end user's standpoint.

If I wanted to use this feature, would I have to download some sort of client to establish that connection?

How does that piece actually work? Yeah.

So the way it's connected is it's really a testament to just the ease of use of Cloudflare One and how all of our solutions work well together.

The remote browser itself, users can connect to it very easily.

They can go to a one of our clientless isolation endpoints.

They're presented with a single sign-on to log in so the remote browser is authenticated for that user and within a second they're authenticated and logged into that remote browser and able to browse the internet at the edge of our network.

Connecting to a private network is really easy as well because and, as a great blog post you wrote, which was the "Ridiculously Easy Tunnels", because connecting your private network to Cloudflare's edge is as easy as just running a single command to install an agent inside your private network.

And once that's done, the remote browser and any requests to a private IP address transparently route from remote browsing into your private network.

And that's the extent of the configuration.

Oh wow, so no client on the user side at all.

All you need to do is just go to kind of the, this isolated authentication realm.

And then from there, we establish a connection to your network through Tunnel, so really the only installation that you need to do is to take that single installation script from the Tunnel side, deploy that somewhere within your subnet or on your home network or your corporate network, and then that establishes connectivity, kind of as a jump post, into your private network, and then just from the browser directly, you can reach private resources straight through that?

Yeah.

And I'm glad you brought up the word jump house or jumpbox because we see this as a powerful way to start deprecating virtual desktop interfaces.

It's interesting, as we've been talking to customers, seeing how virtual desktops are still used in businesses, because if you go back to the old days when virtual desktops first started being used in businesses, they were powerful ways to securely deliver business applications to users without them needing to install on their local device and also to connect to the data inside that corporate network.

But over time, the trends have changed where desktop software is no longer being used as often as it used to be, web-based software is taking over, and also the corporate network isn't as strong a wall as it used to have, since data is in applications all over the place.

But VDI still exists in some businesses and that is because it's a somewhat elegant way to just have a window into a private network.

But it's also an extremely expensive way to have that window into a private network and have a browser inside a private network.

With Browser Isolation, you can get rid of the expense of the browser in a virtual desktop environment and all the costs of the compute for serving that workload and just have to use a connect to the remote browser and then straight into that private resource.

This is great for anything like, let's say, is a legacy on-premise web app that you might still have contractors who still need to connect to, or you have developers connecting to a Kubernetes cluster, and they want a web-based interface into that environment.

There's a lot of flexibility and control with how you can use this to have that Web presence into a private network.

Interesting.

And it sounds, it sounds relatively complex in the architecture as far as the different pieces that need to communicate with each other.

Must have taken a really long time to build this, right?

Right?

This was actually a fun, quick win because one of the...

so, our Secure Web Gateway team and your team on the Tunnels team wanted to make sure that any traffic that egresses from the Secure Web Gateway to a private network was inspected, logged and tracked.

So, just through our natural work of building Cloudflare One and integrating our platforms, we already had a path to connect traffic from the gateway to a private network.

We did some testing and we were looking into how the remote browsers could potentially leverage this path.

And at first it didn't work, so we started diving into it and what we found was we had implemented a, like a very naive block to just say a remote browser should never be able to connect to a private resource.

And at the time when we had written that, that was before we had deeply integrated into the Cloudflare One platform.

Then over time, we reassessed that behavior and realized that the flow of private IP connectivity from the remote browser already had the security function in place from our network, and we actually just had to remove a few lines of code in order to enable this functionality for our users.

Very cool.

I love that. It reminds me of of a blog post that Annika wrote yesterday of building a stronger bridge to Zero Trust.

And really, it's kind of a perfect example of the Cloudflare One vision, which is being able to connect anything to anything, having multiple on-ramps, multiple on-ramps and off-ramps.

And it's really speaks to the power of having a fully composable and programable network that spans the globe.

So it's surprising, but awesome to hear that that was such a quick win and such an easy feature to kind of knock out, especially since it serves such a broad use case.

Yeah, absolutely.

And yeah, it's been fun testing it. I've been testing it with internal dashboards I've been using.

And the...

all of the functions that you would typically be able to use in a remote browser like disabling a clipboard, preventing printing, all of those works out of the box.

So you can use it to, if you have some sort of resources and you want to extend it to a third party to let them look at the data, but not potentially exfiltrate it, you can do that with the remote browser.

Yeah.

So, it sounds like out of the box then, we already have secure web gateway policies that could be built against this or Cloudflare Access policies.

Is that kind of true?

And you could, you could say, I want this user to be able to reach wherever my router configuration page lives or something like that.

And you could say this user can do this, but they can't copy, they can't take screenshots, they can't print like, are all those kinds of rules built in from the from the gate?

Yes, all those rules are built in.

I will just confirm screenshots is not something we can block, but we are thinking a lot about that problem and how we can help solve it.

- But those other features you mentioned do work.

- Cool, logging as well. You can see that in the Zero Trust dashboard, I assume.

Yes.

Any requests to private IPs will be logged in the dashboard, that can go off to your SIEM.

Actually, one of the really cool things is since all requests...

so typically when a user connects to...

they go through a VPN and then they connect to a private IP resource.

The VPN might know that they connected to that resource, but it's quite cumbersome to implement micro segmentation or control who can connect to what private resources.

Since all connections to the remote browser are authenticated, you're able to apply policies to, say, one group of users can connect to 10.0.0.1, and another group of users connect to another CIDR range, but they can't connect to each other's CIDR range.

So if you have a fairly unsecure private network, Browser Isolation is a great way to, with Tunnels, is a great way to apply those identity controls across an existing network.

Interesting.

Would you need multiple tunnels to do that or would you do that just there one tunnel and multiple policies?

What would kind of be your recommendation there?

I know the answer, but you're the expert in this space.

So I'm going to guess the answer is you need one tunnel per...

actually, I think you can have one tunnel for multiple networks.

So as long as it can see every network, you can set multiple CIDRs for each one.

Exactly.

Yep. So... Exactly.

So we almost always recommend using one tunnel. It just helps from an orchestration standpoint.

Yeah, as long as you have visibility to those other subnets or you're able to reach those, then the one tunnel should do it.

What's interesting there too, and since you opened the door for me there, is that you can also use these same terminals to expose things on the public Internet as well.

They don't have to be things that are just available on private networks.

You can route things through your zone on Cloudflare as well.

So, yeah, so generally one tunnel should do the trick for most use cases.

Kind of moving forward a little bit.

What do you see as being some of the next features that are kind of on your roadmap?

What are you looking forward to?

Features like this obviously are incredibly powerful because, A.

you know, they kind of remove legacy architectures, but they also are things that are, again, very, very intuitive to kind of set up if you already have some things going on in Zero Trust because of that 1 plus 1 one equals three.

Are there things like that that you're looking forward to and what's that roadmap look like?

Yeah, so we see Browser Isolation as a security layer that integrates with a number of Cloudflare Zero Trust and security products.

So as I mentioned in the beginning, the core value of a remote browser is that it can instantly protect a user from a malicious website.

But it also works in a reverse direction for protecting users on sensitive resources.

So from the malicious websites perspective, an announcement we made earlier this week is we're integrating with Area One, which is our email security offering.

So if a, if there's a deferred phishing campaign that reaches your inbox, we're able to isolate and restrict how users can interact with a potentially malicious website before that attack is even militarized.

As well, from the Zero Trust perspective, looking at the other side of the coin, which is protecting sensitive apps from...

protecting sensitive apps, we're looking more in... we're working closer with our Zero Trust team to integrate with our Access products so any users can securely access a private SAS application or web app through Browser Isolation, beyond the private IP services, as well as integrating with our DLP platform, which a great product manager who's joined us, Noel has been working on.

With the DLP platform, there's going to be a lot of interesting things, like for example, if the remote browser sees a PDF document that has credit card information in it, for example, that can be blocked from being even downloaded into the remote browser since all of those DLP and security controls can work for isolated traffic, non-isolated traffic, wherever it comes from.

And interesting you mentioned the screenshots issue.

This is a space where we're thinking a lot about watermarking of sensitive applications since it's quite...

there's a technical challenge known as the analog hole which makes it very hard to effectively block a screenshot, since some other software or someone just pulling it out their phone could actually take a photo of that content.

What we found as we've been going down the DLP path is the vast majority of data loss events aren't actually because of malicious users.

It's like 56%, so because of naive users and a user making a mistake.

So we see watermarking as a way where we can educate users to prevent them from making that mistake, and also a way of annotating screenshots so that if a user does intend to upload it, the DLP platform is able to detect it and block it.

Wow, there's a ton in there.

But I'll go back to I think your first feature that you mentioned, which was the the remote isolation fo Area One and the integration there.

I know that you were at the Zero Trust Roadshow in, I believe, San Jose on Monday.

I was, at the Computer Science Museum, which is a really cool place of old, like World War II computers and things like that.

That's a great venue for it.

Yeah. And then I was at the one in Dallas this weekend and we have, that's a 12-part series, so there's ten more cities.

So definitely check those out. But one of the topics that got brought up was that exact feature because it was hot off the press and there's a ton of interest from the crowd in that.

And one of the things that came up most often, or one of the most frequently asked questions after the session was over, was how does that actually work?

So so this would have been something that would have been maliciously executed on my local machine.

This is now in the cloud?

How does Cloudflare deal with that?

But what's happening at the VM?

Yeah, this is a good opportunity to talk about how our isolation technology works.

And it's the same for any on-ramp, whether it's from a suspicious email or a user connecting to a private resource.

Rather than executing any of the website code on the end user's device, we run full-featured chromium web browsers at the edge of our network, so that's really important from a latency perspective, since every interaction, such as scrolling or typing, clicking, all of those are roundtrip over the network, whereas before it was something that was immediate and instant on your device.

So a question we often hear is How much latency is this going to add?

And the answer is not much because our network is so close to users, we automatically position the remote browser really close to the user and they get a extremely low latency experience and we've had an enormous amount of feedback that people actually forget they're even using a remote browser since latency is so low.

From a technology perspective, the way we stream the web page to the user is a bit different from any other isolation product.

We wanted to make sure that when we stream a web page, it's reliable, so no websites could break while connecting to it remotely.

And also it doesn't negatively impact performance or increase bandwidth usage on the device.

You can imagine, we're all using web browsers all day, every day. So if that was a high-resolution video, I'd even need to essentially be downloading a 4K video all day, every day to do my job.

Or I would have to degrade the quality and the quality of my browsing experience to lower the bandwidth.

Those weren't tradeoffs that we wanted to make at Cloudflare because our mission is like we want to make sure we deliver security without compromising on performance.

So our approach actually uses vector streams.

So when you get to the end of computing all of the HTML, CSS and JavaScript, the web browser actually constructs two-dimensional draw instructions on the user's browser and says, draw a square here, draw a squiggly line here.

If you draw enough squiggly lines, you'll eventually get text out of that.

Draw all different colored boxes. And all of these, when you combine them together, is what gives you the web page that you're looking at.

And they're really lightweight and resolution independent, so we're actually able to stream them over the wire to the users' browsers, re-render them and present a vector-based implementation of the web page so it doesn't have the performance or bandwidth constraints of a vide- based solution.

I love that answer because you answered two different questions and you answered my...

if my dad's out there watching, he's very happy with the way that you just answered because he always asked me, how does code turn into these images that I see on the screen?

And you kind of just alluded to some of that as well. I think that one thing that's interesting there as well that you mentioned was, How do we actually or how does Browser Isolation think about the user experience?

And do you want users to be able to tell that they're using a remote browser?

Is there any kind of value in them knowing that they're in an isolated session?

Is that something that you've given thought to in the past?

Yeah, generally we lean towards transparency to make sure the experience is...

works just like using a local web page.

There are a few occasions where we do present UI to the user, but we want to be really thoughtful about when we do that.

With our clientless isolation approach, which is where users...

we have two different on-ramps.

One is when users are connecting on a proxy, so their domain name is the exact same.

The other is via URL, where the domain name is prefixed.

When the domain name is the same, we don't need to show an address bar or anything like that, but when the domain name is different, we want to make sure that the user is aware of the host name of the website that they're looking at so that they don't get confused by the domain name of the website, the domain name of the remote browser.

So we do show an address, a small notch- based address bar inside that mode.

But generally we avoid presenting UX unless it's absolutely critical, since people are using the website, they're not using the remote browser, and that's what we want to make sure they're focused on using.

Yeah, I love that and I love that you mentioned that you can use your favorite browser, that you don't have to change your browsing habits in order to adopt the solution.

And that seems really powerful as well. I'm curious from the Cloudflare side, is this something that, Am I using this?

Am I using this every day?

Are there any kind of policies that we're using ourselves to try this out?

Yeah.

So Cloudflare is, if anyone's paid enough attention to Cloudflare, we're often eating our own dog food and using our own products.

So everyone at Cloudflare is using the full end-to-end suite of Zero Trust products.

So our WARP Roaming Client, Gateway to protect internet, Tunnels to connect internal resources, and we apply Browser Isolation on top of higher-risk browsing activity so that users can do their job without hitting blocked pages all the time and without our IT departments assuming, like needing to tolerate the risk of letting people access too much of the Internet.

Very cool.

I love that. I think that that kind of brings us full circle and what we announced today, which is the ability to use remote browsing to connect to a private network.

From there, how remote browser actually works, how we built this, how it was kind of honestly a pretty quick win for us just because of the composable nature of the Zero Trust suite, how we've maintained performance, how you can layer on the Zero Trust security aspect on top of that.

The fact that we're trying it out internally, some use cases to kind of get started with at home, and then, of course, some exciting new features that are coming down the line.

Anything else that you want to make sure that we mentioned in this segment that we covered from the remote browser perspective.

No, I think it's been a fun conversation.

Definitely anyone who's interested in testing this out, it's really easy to configure.

Basically, if you're already using Browser Isolation, you only need to configure a tunnel.

If you're already using Tunnels for your network, you just need to enable Browser Isolation and then you can connect to those resources.

This has been great. Yeah, how long would you say, roughly, that it takes to to set this up?

I guess just based on some of the things that you mentioned before, maybe 15, 30 minutes.

Is that, does that sound about right? Yeah, I think that sounds about right.

In fact, the blog post is a great thing for people to read and I needed to prepare the video that we...

we have a video inside the blog post of this behavior.

I needed to connect the remote browsers to my private network to prepare this video last night, and I was able to get the video recorded and the implementation done in under 30 minutes.

And that was even with me rerecording the video to make sure I typed everything without any typos, since I always keep rerecording videos if I don't type it perfectly the first time.

Yes, there you go.

So rather watching, kind of a couple easy steps. Step one is to set up your Zero Trust account.

You can do that for free today for up to 50 users.

Step two is to follow the clientless web isolation tutorial in our developer documentation.

Step three is to follow the ridiculously easy to use tunnels tutorial as well.

That kind of connects all three across the board, and then you should seamlessly just be able to connect to your private network.

And yeah, I think that you should be able to do that in 15, 20 minutes.

So it's pretty, pretty quick and a pretty fun exercise.

And yeah, you can start accessing your own home lab from the road or for more complex use cases as well.

Yeah, awesome.

Thank you for having me today, Abe. Yeah, thank you as well.

And yeah, happy Cloudflare One Week to everyone out there and we'll see you on the next segment.

Great.

Thank you, everyone. Bye.

We have seen malicious foreign actors attempt to subvert democracy.

What we saw was a sophisticated attack on our electoral system.

The Athenian project is our little contribution as a company to say, How can we help ensure that the political process has integrity, that people can trust it, and that people can rely on it?

It's like a small family or community here, and I think elections around the nation is the same way.

We're not a big agency.

We don't have thousands of employees.

We have tens of employees.

We have less than 100 here in North Carolina. So what's on my mind when I get up and go to work every morning is, What's next?

What did we not think of and what are the bad actors thinking of?

The Athenian Project, we use that to protect our voter information center site and allow it to be securely accessed by the citizens of Rhode Island.

It's extremely important to protect that and to be able to keep it available.

There are many bad actors out there that are trying to bring that down and others trying to penetrate our perimeter defenses from the Internet to access our voter registration and/or tabulation data.

So it's very important to have a elections website that is safe, secure and foremost accurate.

The Athenian project for anyone who is trying to run an election, anywhere in the United States, is provided by us for free.

We think of it as a community service.

I stay optimistic by reminding myself there's a light at the end of the tunnel.

It's not a train.

Having this protection gives us some peace of mind that we know if for some reason we were to come under attack, we wouldn't have to scramble or worry about trying to keep our site up, that Cloudflare has our back.