PNA A Short Life, a Long Shadow - Gev Manekshaw

All right. Uh a very good afternoon to everyone. I hope everyone have is having a great conference. I know I am. Uh I'd like to spend the next 25 minutes uh talking about uh a very important browser security mechanism uh called private network access. Uh we'll talk about what a short life it had uh and what a long shadow it leaves behind. Uh a quick intro. Uh my name is GV. Uh I'm a security engineer. Uh I work uh I work out of Philly. Uh I'm lucky to be joined by some my amazing colleagues at the place I work. Um and in about 25 minutes I'll have the privilege to be a bside speaker. Uh a quick disclaimer

before I start. Uh this is a personal project that I conducted on weekends. Uh all the views expressed are my own. Uh any tools that you see here, please only use them in trusted environments and places that you have permission to test on. Uh all right. Can I have a quick show of hands for anyone who has seen these HTTP headers? A quick show of hands. Uh, awesome. A couple of folks. Uh, great. Uh, quick point, not to be confused with the Coors headers. He's slightly different. Uh, but nevertheless, let's move along. How about this pesky alert? Anyone seen this? Okay, I see a few more hands. Great. Uh so if you're a Chrome user uh and uh you know you've you've

upgraded to Chrome 142 in the last 3 months uh there is a high possibility you might have seen this alert. Now the two that you saw here are essentially two things trying to solve the same problem uh but in very different ways. Let's see what the problem is. Browsers are a very important trust boundary and specifically a network trust boundary. Uh why is that so? Because it lets the internet uh talk to or rather access uh our uh our private networks, right? It can be your home network, it can be your your enterprise network or your local host as well, right? Services running on your local host. Um and that trust boundary has been exploited for a very long time.

For example, for port scanning. uh a couple of years ago every every public almost all public websites were scanning their uh let me let me let me rephrase that not all but quite a few public websites were found post scanning their users uh why so because honestly it's a great way to fingerprint users in a stateless manner that trust boundary was also being exploited for something more nefarious uh for something called as drive by attacks so uh an age-old technique called Soho farming uh what's that about say you say you access a public website and uh it tries to send a fetch request to your router to set the DNS server on it. All right, let's say your your DNS

server is misconfigured. Uh you end up hijacking uh the the the victim's network there. Uh or for something as recent as CV 2025 49596. Uh now that was concerning MCP inspector. All right, that's that's basically a tool that lets you inspect a bunch of MCP uh uh protocols that you might you might be testing. Uh and uh if a public website manages to uh to uh you know get a user to click their link and execute this command, they'd end up having uh shell on on on that system on that host rather. So one way uh browsers decided to solve that problem was by a mechanism called private network access or PNA. uh when it was rolled out it was also called

corors rsc 1918 uh now for those who are familiar with corors uh you'll see you'll see why the name sounds very similar to get to know what PNA is it's important to first understand what pre-flight requests are say for instance uh you live in an apartment building uh and a stranger walks up to the bellman uh and asks them hey I want to visit Mr. XYZ on floor number N. All right, that bellman is going to call you and ask you for your permission. Can I send that that stranger up there? Are you expecting them? And depending on what what the person on the floor upstairs uh responds back, uh the the Bellman is essentially

going to allow or not allow that that stranger to come up there. That exact concept is what PNA uses. So say you open a public website and it tries to initiate a connection to something private, right? Something on local host, something in RFC 1918. The browser is going to step in and do something called as a pre-flight request. It would first send an options request to that private resource requesting private network. So access control private minute network to true. It's going to request that access only if that private resource responds back with the 200 okay with the explicit headers access control allow private network as true and it reflects back the origin only then does the browser know

that this this private connection is authorized by the private resource itself. uh and PNA uh is is is exactly this this pre-flight request. Uh if you're familiar with corores, this this particular pre-flight request should look very similar, right? Just the headers are different. All right. Uh let's look at the timeline of implementation for for PNA. Uh so Chrome initially proposed uh Corors RFC1 1918 to the to the worldwide web consortium. Uh back in November 2020, uh PNA first made its appearance in any browser in Chrome 96 in November 2021. Uh early 2022, it started throwing errors in case you know uh private network access was detected. Uh but by September 2023, uh it was full-blown

blocking access if uh you know using PNA. Uh that was in September 23. uh September 24 uh the worldwide web consortium officially accepted it as a draft for a specification to be included in other browsers as well. Uh but in September 2025 something happened. Uh we'll talk about that a a little later. Uh so a little backstory uh I personally work uh in in web app security. Uh and I personally stumbled across PNA earlier this year uh to to my shame. uh and and in June 2025 uh I was a little curious to analyze what the state of PNA is. Uh so what I did was I chose the largest uh lab space broad uh space uh uh lab/broad

space available uh which is AWS uh US East1. Um I analyzed all web services on port 80 uh using a custom end map script. So essentially I I send that pre-flight request to see who responds back with those headers. Uh so on the right you'd see um 2 million uh 2 million IPs responded back with a valid web service on port 80 but only.1% of them actually responded back with any kind of PNA headers in there. Uh surprisingly 2/3 of them blocked private network access. Uh but onethird of them allowed private network access. I gathered some additional information like what kind of servers are these? Uh, surprisingly a vast majority of them were engine X. Um,

uh, I gathered some title information. Um, what I saw was most of them, uh, mo a vast majority of them did not have any kind of titles. Um, so my interpretation was that PNA adoption is low. um about onethird of PNA enabled servers seem to have an insecure configuration and the lack of titles in these web services probably indicate that these are some kind of APIs. Uh if you'd like to test um if you'd like to test this in your own uh in your own environments uh please feel free to use the end map script and the nuclei template here. Uh if you're a nuclei kind of person, uh feel feel free to use either either of the two.

All right, I'll leave that that up there for a second. Uh perfect. So let's all go back home and make sure all our private resources support uh PNA headers, right? Uh unfortunately, no, it's not as simple as that. Um in September this year uh just three months ago uh the only browser that supported PNA uh decided to deprecate PNA [snorts] and replace it with something called local network access. So private network access became local network access. Um though the two sound though the two mechanisms sound awfully uh familiar or similar in name uh there is a very big difference uh in the two and that difference it's a shift in responsibility in PNA it was up to the the service uh

the the local or the private service to protect itself right it had to allow uh PNA access using those headers explicitly But that model has shifted or that responsibility has shifted to the user in lna. And how does it manage to achieve that? Using this very elementary prompt. So anytime the browser sees uh or intercepts that private network or that that network access to to something local or private uh in in private IP space is going to throw you that error. uh unfortunately uh that so that entire P that entire pre-flight request that we saw is being replaced by this. Um now depending on what uh side of the spe of the security spectrum you are on

uh you are either end up uh you're either going to end up always allowing, always denying or rolling the dice on what to select uh for allowing or blocking that request. Uh so I wrote up a quick uh Chrome extension. It's currently available on on the Chrome store. Um, so on the left you see what that alert looks like, right? So in case you see that popup, you hover over the the the extension and it's going to exactly tell you the URL uh that uh that that public website is trying to access. Uh all right. Uh I will conclude uh by currently drawing a com by by drawing a comparison between uh where we are with

with PNA and LNA. So, private network access has had a lifespan of around four years. Uh, I'm sure there's still uh there still this is probably still going to be around because uh unless you've upgraded to Chrome 142 and above, this is possibly still going to exist. Um, LNA has only been around for 3 months. Uh, the earlier version PNA was only found its way into Chrome. Uh, but LNA has found more adoption. U, it's it's made its way into Chrome Edge. uh Firefox is triing it as well. Unfortunately, both of these specs have not been able to solve port network uh sorry port scanning uh and port scanning is still possible. Both of them broke things uh seriously

broke things uh honestly it caused a lot of confusion uh possibly to users and attackers alike. Uh PNA had its own set of challenges for which it was deprecated. um it had to deal with uh with uh with dealing with mixed content uh policy. Uh so that's when you know when HTTPS uh resources try to access HTTP or uh HTTPS services without without a good certificate. Uh it also had to uh to deal with uh IoT devices or you know legacy routers that that needed these updates where where PNA access was actually required. Uh so those are some of the challenges that led to PNA's downfall. Uh LNA has its own set of challenges. Uh number one

being users. Uh users are not going to know what what those alerts are. Uh if you look at the Chromium issue tracker, uh they are looking at uh at making that prompt a little more intuitive. Uh for now just download my my extension. Um uh but yes, that's that's one of the major challenges. Um it uh the other challenge is that uh that these these mechanisms depend on intercepting different kind of JavaScript APIs right so for example if fetch comes in you know the browser is going to intercept that request and uh and do its thing um but unfortunately for example protocols like websockets are not yet supported um so there is still scope for for uh

private network access in in limited cases uh next uh PNA did not really support any kind of uh centralized configuration for browsers. You could not configure any kind of policy in your organization to to make sure you know your browsers exactly know uh what kind of PNA accesses is actually allowed to happen. Uh but LNA um at least at least for Chrome uh if you're an enterprise customer, they do allow you to uh create some kind of policy that explicit explicitly allows you to define the set of websites that should have local network access allowed. Uh and that is all I have for today. uh all the resources, references, uh my contact is all in this wiki uh that you

can find in uh in in the in the QR code right here. [applause]

[applause]

Uh I possibly finished way before I expected. Uh so I can take questions if if anyone has any.

So, uh, you mentioned that PNA started out and it took four years just to get Chrome to start using it, but LNA has been around for a few months and it's already got three browsers. [snorts] >> Uh, so sorry, it's the other way around. Uh, PNA has was around for four years. Um, yeah, in fact, it was introduced in November 2021. Uh, deprecated a week before I submitted the CFP for this conference. uh which was very interesting. Um but yeah, LNA has been around for for 3 months. >> It just looks like LNA is getting adopted much faster than >> it is uh and it seems like uh you know it has it has good buyin from from

Firefox, the Chromium project. Uh and uh I you know I I think they're trying to solve a lot of problems that they solve they saw with with PNA.

Is there any way you can determine let's say you're using a web browser that it is using LNA? >> Uh right. The question was uh how can you detect whether your browser uh supports uh LNA? Um unfortunately that is not documented in a centralized location. But if you do use Chrome 142 and above, uh you know for sure that the browser supporting uh LNA, uh I do not specifically remember what version of uh of Edge uh supports uh LNA. Uh Firefox is still in it trial version. It's not made its way into the the production version yet. >> I hope that answers your question.

>> Ah, yes. Does the Safari or Apple have anything similar to this? >> Uh that's a great question. The question was uh does Safari for Apple have uh any protections? Uh unfortunately no. Uh Safari uh allows uh at the moment I have seen it allow private network or local network access. >> Uh yes please. >> I feel a little bit stupid asking this but so I thought that in browsers like single protection browser should protect from changing the region of the URL like from whatever script was loaded to trying to foc

>> I'm sorry which uh which mechanism are you referring to >> same origin in the browser >> same origin right right so uh the the interesting thing about uh about that is that uh you know even for cars um that that request actually makes its way to the to the remote service. Um so in the sense that um so just gathering my thoughts here um right so um so for example there's a number of different protections that could have stepped in right there's mixed content policy there's cause um but the initial get request still managed to find its way prior to November 2020 to the remote resource so if you had like a get uh request to your

router with set DNS it would still make it through that uh remote

I have just now realized that all my testing was primarily in Chrome in the last four years. So it's already was in place. So that's why

>> uh all right. I think we don't have any more questions. Uh thank you so much for for uh for being here folks. Uh I hope you have a great rest of the con. >> [applause]