Why can't we have raw UDP in JavaScript?

https://www.computerenhance.com/p/no-really-why-cant-we-have-raw-udp

by adamrezich • 4 years ago

72 105 4 years ago

shams93• 4 years ago

You do its called the webrtc data channel.

torginus2• 4 years ago

Yeah and its an absolute PITA to set up, and a nightmare from the ops perspective, I'm not even sure what even are you supposed to use on the server side.

beebeepka• 4 years ago

The client is fairly easy, imho. Did you mean setting up the infrastructure? Because yeah, hard to do properly

YarickR2• 4 years ago

The point is moot at best; how many layers of security does browsing FB and posting pictures on Instgram need ?

mariusor2• 4 years ago

Casey is a game developer, his use-cases are probably games targeting the browser and how it would be possible to improve their communication with external servers.

stillkicking• 4 years ago

*is a game developer with a particular focus on "RETVRN TO TRADITION" where anything that isn't super lean-and-mean is bloated and inefficient and ridiculous, and only exists because web developers are misguided, miseducated, etc. WebRTC could do what he wants, but then he'd have to build a WebRTC->pure UDP gateway.

I can sympathize, but, even in the original discussion on Twitter it's clear he is ill-informed of the relevant security fiascos that made all these complicated protocols necessary, or the messy legacy constraints they must operate under. Infrastructure is not magic, and tying together e.g. application-level concepts with DNS-level concepts would be a recipe for misery IRL.

I also find it funny he considers the string/text-based parts of HTTPS to be unworthy of a secure protocol, when in fact, the whole reason that approach is considered so dangerous is because of programmers with his attitude who underestimated the difficulty of secure parsing. The niche of "LangSec" is all about solving this problem properly by treating input processing as a formal parsing problem with formal grammars.

speedgoose• 4 years ago

We also don’t have raw TCP or ICMP in a web browser. It’s probably for very similar reasons.

My guess is that there is no strong enough demand for such low levels network protocols in major web browsers. It is not worth the risks, and the costs, and the complexity.

We have HTTP, WebSockets, and WebRTC.

xxs5• 4 years ago

raw ICMP requires root permissions. For instance 'ping' runs with elevated/root permissions. "Raw" TCP is a mystery, though. WebScokets are like, ehh, fine, whatever - it's a framed stream protocol.

vbezhenar4• 4 years ago

We have raw USB in a web browser. I can access my USB security token from the browser right now. I can access my raw keyboard USB connection from the browser right now. How is network access have less demand that raw USB? Even simple thing like mail client can't work in browser without using third-party server (and sending your password to that server). Same about ssh client, etc. A lot of apps are currently impossible in browser or security nightmare because of this artificial restriction.

easrng4• 4 years ago

Raw USB is a Chrome-only extension, Safari and Firefox don't support it because it's an awful idea. Even so, it's much easier to make a meaningful permission dialog for USB than for a TCP or UDP connection. With USB there's a limited set of devices you can connect to, and they somewhat human-readable names or vendor IDs that can be translated into names, and there's no way to do something like a DNS rebinding attack with them since the browser can detect when the device is unplugged.

It is entirely possible to make a secure SSH or IMAP client in the browser, just proxy the encrypted data and do TLS or the SSH protocol in Javascript.

josephg• 4 years ago

Browsers don’t let you send raw UDP packets for the same reason they don’t let you send raw TCP packets: because devices in home and business networks implicitly trust many packets coming from inside your network. A short list of things you could do with raw TCP / UDP capabilities:

- Reconfigure a user’s router (if they have the default password)

- Print to a network printer

- Poison the home network ARP table

- Various network level DOS attacks (ICMP echo flooding attacks, etc)

- Control smart home appliances

- Access network shares

- Insanely invasive fingerprinting (including figuring out the make and model of other devices in the user’s house).

So no, it’s a terrible idea. I don’t want webpages printing things, turning my lights on and off or knowing anything else about me.

If you want the benefits of UDP through your browser, use webrtc or wait for HTTP3 or Webtransport.

The author seems to want the OS to have no knowledge or involvement in the network protocol, for unknown reasons. But they obviously think the user’s web browser is fine. From the point of view of a web application, what’s the difference?

And again - what actual benefits would there be to raw UDP access? The article is very light on specifics.

xxs5• 4 years ago

The connectivity to any address/host would be a bad idea, what about restricting only to the same host of document's origin.

Edit: Java's applets used to have the bog standard TCP (and UDP) and since late 90s. While Java/applets were a security nightmare, as all of them run in the same process and the impl. of SecurityManager (and its checks) was not up to the task [along with various deserialization exploits], the connectivity was not an issue.

teraflop2• 4 years ago

Same-origin isn't sufficient, because an attacker who controls the DNS resolution of their domain can create a DNS record with the same origin that points to an internal target address. (And before you ask, no, the browser can't reliably distinguish internal from external IP addresses.)

If the attacker is restricted to performing HTTP requests, then things like the Host and Origin headers allow servers to defend against this. If you allow web pages to make raw TCP connections, those protections evaporate.

And I'm pretty sure that if Java applets allowed raw TCP, they would have had the same vulnerability; it's just that typical attackers weren't quite as sophisticated in the 1990s.

oefrha2• 4 years ago

HTTP has Host and Origin. Raw TCP/UDP do not. “The same host of document’s origin” can host any number of completely unrelated websites/services thanks to vhosting.

WatchDog• 4 years ago

I think the connectivity issues were simply overshadowed by the deficiencies of the SecurityManager.

fulafel10• 4 years ago

Amusingly half of those things have been modernized to run on HTTP, so browsers can already do them.

rocqua• 4 years ago

Except the very complicated 'same origin policy' makes it generally forbidden by browsers to do HTTP against local adresses.

Hamcha• 4 years ago

I mean it's nowhere as bad, and for legacy stuff usually CORS/SOP helps.

New implementations that use websocket as their root (mostly for web browser compatibility) seem to take security more seriously out of the box, I use a couple apps in my day-to-day which expose APIs over Websocket and don't trust by default.

- Vtube Studio has a auth dialog that pops up on first connection you must accept before commands are executed

- obs-websocket by default requires a password to be used.

There's always outliers sadly, for example "beefweb" (Foobar plugin) has auth but it's not enabled by default.

anonymoushn3• 4 years ago

In TFA, it says

If DDoS was the concern, just require that UDP packets be sent exclusively within the same domain as the originating code.

So you couldn't do any of these things.

And again - what actual benefits would there be to raw UDP access? The article is very light on specifics.

It seems like writing game netcode without setting up a WebRTC server should be reason enough.

chii• 4 years ago

It seems like writing game netcode without setting up a WebRTC server should be reason enough.

this begs the question - is the browser really the right platform for a game where netcode like that is needed?

Why make the browser even more complex, when the original design of it is meant to only display documents? If we keep going down this road, you'd end up with an operating system inside the browser.

quietbritishjim2• 4 years ago

DDOS is essentially the exact opposite of what the parent comment is talking about.

nneonneo• 4 years ago

Restricting origins doesn’t work thanks to a fun little trick called DNS rebinding. Let’s say you get the user to browse your site, say, attacker.com. They lookup your DNS and see that it’s 1.2.3.4, with a TTL of (say) 5 seconds.

Five seconds later, the user’s DNS cache entry expires. Your page triggers a new request to attacker.com. Since the TTL has expired, they do another DNS lookup - and you serve them a different IP address, say, 192.168.1.1. Now they make a new request to that IP believing that they’re still accessing attacker.com.

With HTTP requests there’s at least the possibility of detecting these attacks via the Host header (even if that doesn’t usually happen in practice). With raw UDP, however, the attacking packets would be indistinguishable from legitimate ones.

asojfdowgh• 4 years ago

Have a page load up a script from <nonce>.relevantdomain.tld, once the script sends back a packet to <nonce>.relevantdomain.tld, have the dns settings change subdomain to 192.168.0.1, and then etc

the war between safe things and unsafe things is endless, so we shouldn't be adding a massive unsafe thing and then bodging patches onto it to make it "safer" than completely unsafe

vbezhenar4• 4 years ago

Hide it under prompt and that's about it. Alternative is that user will install some sketchy exe file which will do the same, but without any prompts. Browser could make it more secure.

forrestthewoods• 4 years ago

The article states that, just like microphone access, users would have to approve UDP access and it would only be allowed to a single server. I think that solves your router/printer/etc issue?

what actual benefits would there be to raw UDP access

Author appears to want to control the whole stack. Based on their calling out HTTPS and friends as way too complex to implement. This is the HandmadeHero author afterall.

And the standard answer to “why UDP?” is “required for game dev”. TCP is a non-option for many types of games.

junon• 4 years ago

Small nit, you cannot do ICMP with TCP or UDP.

rubatuga• 4 years ago

Also ARP isn't over TCP or UDP.

lucideer2• 4 years ago

Every one of your threat vectors listed would be prevented by appropriate browser origin policies (which already exist for existing protocols).

The only slight exception might be fingerprinting, as new APIs always extend this surface area somewhat, but not in the way you're describing (enumeration of local network devices) given aforementioned origin policies.

iancarroll• 4 years ago

How do you enforce an origin policy on raw TCP? CORS/SOP are heavily built on HTTP semantics, and you cannot easily map this back to raw TCP sockets. Even just allowing a TCP socket to the page origin's IP address is unsafe, because it might be a CDN and allow skipping CORS for other sites.

benmmurphy• 4 years ago

Browser origin policies are difficult to use to protect something that listens to an IP address rather than a host due to DNS rebinding. This can happen implicitly if the victim service doesn’t check the host header. This is already a big problem with HTTP but with UDP or raw TCP there is no host header so anything that trusted the network would be broken.

arpa• 4 years ago

ARP and ICMP are protocols separate from TCP/UDP.

LinuxBender3• 4 years ago

I suppose one could do this but then each OS will have to set flags on the browser executable and there is a whole can of security worms that opens. In Linux one could use

    sudo setcap cap_net_raw,cap_net_admin=eip /usr/lib/firefox/firefox

This could and probably should be automated in firejail or bubblewrap rather than the installer. Does this exist for Windows or Mac?

If using AppArmor or SELinux rules would need to be created unless Firejail is managing the rules on the fly. Then the browser would need to test for the capabilities and give some meaningful log in the web console because a way to debug this is considered good ettiquite. Then one would need a library or API in the browser that knows how to open raw sockets which means getting all the major browser developers to agree on a standard.

Thinking long term there are going to be security auditing tools that will detect the binary has non standard setcap modes meaning that browser developers would have to reach out to all these companies to get on the same page otherwise corporations will have some knee-jerk reactions.

gorgoiler• 4 years ago

Wouldn’t you rather control these capabilities based on the origin domain, through the browser itself?

LinuxBender3• 4 years ago

I would. That would be up to the library. The things I mentioned are the foundation required for the rest of that to work.

nephyrin• 4 years ago

UDP is not a privileged protocol. You don't need any capabilities to speak UDP. It's used by web browsers already for HTTP/3 as TFA mentions.

But also, apps needing additional capabilities is rather common and handled by most any package manager that's going to be providing you a browser. Chrome in various configurations ships with a `setuid` binary to implement their sandbox, for instance.

LinuxBender3• 4 years ago

UDP is not a privileged protocol.

True, but a raw socket does require privs.

fulafel10• 4 years ago

If this for some reason gets momentum, please do IP, or at least both TCP and UDP.

numlock863• 4 years ago

But nooo, I also want to send raw Ethernet and IEEE 802.11 frames from the browser! /s

There's always a baby that will cry for more. People have been begging for raw socket access and other "I just can't get my head around this"-shortcuts since they wrote their first "Hello World!", TODO-list or guestbook API. There isn't really anything you couldn't solve with the things there are now in every browser. What would UDP bring to the table other than more work to deal with it in that regard? This is nothing about innovation or technical limitations. This is just another case of "B- b- but I want it my way because that's how I always did it! :(".

adamrezich2• 4 years ago

what is the impetus for your over-the-top characterization?

WorldPeas• 4 years ago

one half of me is crying and clapping knowing it'll let me do more cool web stuff. The other is cowering in fear, knowing full well this is just one more step in the web cabal's master plan to run a full virtual pentium 3 with soundblaster and ATI card just so i can read the news

easrng4• 4 years ago

https://copy.sh/v86

nly2• 4 years ago

Can't believe there's no Windows ME

fulafel10• 4 years ago

"If you were a large company with significant academic and engineering resources, you might instead want to design your own private secure protocol that:

    Uses encryption you control, so it cannot be bypassed by hacking the certificate authority,

    Uses UDP to avoid having OS connection state on the server side, and

    Uses a well-designed, known packet structure to improve throughput and reduce security vulnerabilities from HTTP/TLS parsing."

I think at this point they would have done well to explain why WebRTC data channels are not usable or incrementally fixable for the purpouse. It's SCTP tunneled in DTLS over UDP. Missing is just the home brewed encryption requirement which would generally be a no-no in security engineering practices.

HWR_14• 4 years ago

Missing is just the home brewed encryption requirement which would generally be a no-no in security engineering practices.

Maybe if the "large company" he talked about was the NSA/FSB/MI6/Chinese Intelligence it would make sense.

Ekaros2• 4 years ago

Fully forgetting that what ever they roll has to have state on server side, just this time in the server software... Not solving too much...

And then forgetting the nice stuff TCP offers like in-order guaranteed delivery...

Both which is needed for most sensible encryption schemes. And doesn't really get away from needing a PKI... Or then you could just grab a connection before it is formed. If you can MitM HTTPS you can MitM anything else...

TameAntelope• 4 years ago

Small point of order, but shouldn't this be retitled to, "No really, why can't we have raw UDP in the browser?" since you definitely can do UDP in "JavaScript"?[0]

[0] https://nodejs.org/api/dgram.html

Ekaros2• 4 years ago

I see just too many issues. Including things like NAT having to guess what to do with your unique UDP packets and then some users complaining why your site doesn't work...

Also generally rolling your own anything isn't that great idea from interoperability to security concerns. And just imagine this multiplied to everyone copying some blog post who knows from where...

vbezhenar4• 4 years ago

It is really PITA. We're making a service which works with various devices. Most devices work over serial, so WebSerial makes it painless. But there are some devices which work over TCP/UDP. So we have to install our software to user computer, install our CA certificate into user store just to be able to talk to TCP/UDP from the browser. Much security.

easrng4• 4 years ago

Unless you support Safari you don't need to add a cert, http connections to localhost are considered secure connections in Firefox and Chrome and basically every browser besides Safari, so you can connect to them from an HTTPS site with no mixed content issues.

vbezhenar4• 4 years ago

Thanks!

danw1979• 4 years ago

Maybe if you don’t like HTTP you shouldn’t be trying to implement whatever it is you’re trying to do in a web browser ?

Jyaif2• 4 years ago

You either target the web browser, or have to deal with the Stores (Play Store, App Store, Steam, ...).

capableweb4• 4 years ago

Or, hear me out, ship a binary/package from your own website.

fomine3• 4 years ago

Find "SOP" "same origin": 0 hit.

ilaksh• 4 years ago

At this point the primary operating system globally is Chrome. It is an overlay operating system, but still should go in that category.

The web platform has APIs for just about everything else at this point. Even USB.

The main reason we don't have UDP, aside from some security challenges, is probably that it actually really opens up possibilities for decentralization via direct P2P connectivity, which could rapidly decrease the control and profits of the big internet companies. Yes there is WebRTC but that is not quite the same and specifically is scoped inside of the browser.

Ordinary UDP support would invite things like libp2p to be ported. Then people bringing in entire decentralized applications using web assembly.. and finally people will eventually realize they don't need a bloated overly complex browser and start using lighter weight platforms built in web assembly extended with things like UDP and cryptocurrency support etc.

That will also pave the way for script/app free information browsing as it becomes popular to break out of the Google platform.

So there are billions of reasons for Google to suppress UDP. They would never admit it though.

44gg44gg• 4 years ago

Why can't we send UDP over Cellular data?

dncornholio• 4 years ago

This seems more of a rant then a well thought out technical analysis.

olliej• 4 years ago

As a person who worked on the original web socket spec - it's because many networks run "deep packet inspection" routers, etc (to protect the network or some such), and those routers are almost universally badly written.

There have been many cases where those routers can be compromised by sending specially crafted content. That's apparently something that hit Java applets, presumably ActiveX (though with activex that is surely on the lower end of the security issue spectrum?).

Because of the nature web sockets providing much more control of the actual bytes on the wire from a browser it was necessary to "encrypt" the bytes. The goal isn't to secure the content, it's to make it so attacker JS can't control the byte content - the "encryption" key is literally prepended to the data being sent so anyone sniffing network traffic can "decrypt" the WS data.* From JS running on a webpage this is completely transparent (or is that opaque?) because obviously if the web content knew the key material they could modify their data to get the correct bytes again.

This is one of the things people forget when asking for browsers to provide features: it's not just "what can I use this for?" but "what can a malicious actor do with this?". Because the threat model for a browser is not the same as an app - browsers can be trivially made to load and run arbitrary JS - Ad networks are notorious for it, but unending websites make it possible. One of the things that make the web a great and amazing thing is that I can go to any website, and not worry about it doing anything to my computer (and with the exception of chrome) browsers also try to make malicious behaviour like spying on you hard as well. Yes there are security bugs that can be exploited, but there's a difference between a security bug that can be fixed, and a literal specified attack surface. *

* To actually protect data you should be using TLS, but you knew that right?

* Fun story, there was a version of the SVG standard (or a draft? it was a long time since I was on that committee) that provided raw socket access

Why can't we have raw UDP in JavaScript?

Related Stories