15 ms·
Why can't we have raw UDP in JavaScript?
- shams93 4y agoYou do its called the webrtc data channel.
- torginus 4y agoYeah 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 4y agoThe client is fairly easy, imho. Did you mean setting up the infrastructure? Because yeah, hard to do properly
- torginus 4y agoYeah the infra (NAT traversal is hell), and I'm unsure how I would hook something like that up to a web server like Flask. Either you get a proper WebRTC implementation like Google's which is huge and does a ton of other stuff, or you talk to another browser peer to peer.
- meheleventyone 4y agoOr use something specific like libdatachannel https://libdatachannel.org/ https://libdatachannel.org/ If you’re using WebRTC data channels in a client server config then infra is no more complex than a regular setup because the server will almost certainly have an external facing IP address. People should really try using WebRTC as well because you can get the full pipeline setup for a toy demo in a couple of slow days. I did whilst also writing my own signalling server in Go without having used Go before! It’s certainly not any more complex than rolling all the stuff the article is talking about on top of raw UDP.
- easrng 4y agoIf you're doing nodejs you can just `npm i wrtc` and get the same api as in the browser.
- YarickR2 4y agoThe point is moot at best; how many layers of security does browsing FB and posting pictures on Instgram need ?
- mariusor 4y agoCasey 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 4y 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.
- deleted 4y ago[deleted]
- mariusor 4y agoIs it really necessary to attack Casey with this two bits sarcasm? You can disagree and still be polite for the sake of me taking you seriously, if not for his.
- speedgoose 4y agoWe 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.
- xxs 4y agoraw 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.
- vbezhenar 4y agoWe 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.
- easrng 4y agoRaw 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 4y agoBrowsers 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.
- xxs 4y agoThe 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.
- teraflop 4y agoSame-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.
- LinuxBender 4y agoI 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 4y agoWouldn’t you rather control these capabilities based on the origin domain, through the browser itself?
- LinuxBender 4y agoI would. That would be up to the library. The things I mentioned are the foundation required for the rest of that to work.
- nephyrin 4y agoUDP 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.
- LinuxBender 4y ago
- fulafel 4y agoIf this for some reason gets momentum, please do IP, or at least both TCP and UDP.
- numlock86 4y agoBut 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! :(".
- adamrezich 4y agowhat is the impetus for your over-the-top characterization?
- numlock86 4y agoAh, the "wave off as strawman"-argument. HN's favorite meme. (I guess that's why you edited it out?) Any real counter arguments, though? Even the article fails to make a point other than "UDP can be as secure as HTTPS!" which no one really ever argued about other than the article writer itself to make a synthetic point about it.
- adamrezich 4y agoI edited out the word "strawman" almost immediately after posting since I (correctly) realized it could become a fixation point in your response that you would use to dodge the question.
- numlock86 4y ago
- WorldPeas 4y agoone 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
- fulafel 4y 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 4y 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.
- Ekaros 4y agoFully 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 4y agoSmall 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 https://nodejs.org/api/dgram.html
- Ekaros 4y agoI 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...
- vbezhenar 4y agoIt 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.
- danw1979 4y agoMaybe 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 ?
- Jyaif 4y agoYou either target the web browser, or have to deal with the Stores (Play Store, App Store, Steam, ...).
- capableweb 4y agoOr, hear me out, ship a binary/package from your own website.
- fulafel 4y agoUnfortunately that restricts your platforms a lot, and even for the platforms that this reasonably works for, requires a lot of porting and testing effort (or you need to settle for a single narrow target platform).
- capableweb 4y agoHow does that restrict you more than targeting a specific store like App Store, Play Store or Steam?
- fulafel 4y agoThe point of comparison was targeting the web.
- Jyaif 4y agoGood luck shipping a binary for iOS from your own website :-) That's doable on Android, though security sensitive people won't install a random APK found on the web. And signing a binary on windows is doable, but rather expensive.
- fomine3 4y agoFind "SOP" "same origin": 0 hit.
- ilaksh 4y agoAt 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 4y agoWhy can't we send UDP over Cellular data?
- dncornholio 4y agoThis seems more of a rant then a well thought out technical analysis.
- olliej 4y agoAs 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
- deleted 4y ago[deleted]