Repository navigation
webassembly platform #139
Description
Wow, amazing stuff. Why can't we create a webassembly based virtual nic which runs in the browser? Route the packets over websocket. Doesn't Rust compile to webassembly?
My intention in submitting this issue is to figure out if I'm crazy or not.
Reacted by Daniel Lamando, Sinan Bir, trevyn and Artur Kantorczyk
Activity
unicomp21 commentedon Aug 9, 2020
Eventually, it should also be possible to route packets over the QUIC RTCDataChannel getting added to Chrome.
unicomp21 commentedon Aug 9, 2020
This would also create the need for a webassembly implementation of the HTTP2, HTTP3(QUIC), and websocket protocols. Initially, I think websocket protocol (over wireguard) should be pretty quick/simple. The others could follow later.
vkrasnov commentedon Aug 11, 2020
That doesn't sound crazy at all. There is also a Rust implementation of QUIC https://github.com/cloudflare/quiche
So yeah, that is definitely doable, with a simple NAT.
unicomp21 commentedon Aug 12, 2020
Yes! Let's do it! Does this need to be approved as a feature or something? Once we have a webassembly build, I'm thinking another repo could be dedicated to the layers on top of wasm-boringtun-client, such as http-vpn, ws-vpn, etc. In addition there would be the ws-wireguard-vpn proxy (which forwards wireguard packets) for the wasm-boringtun-client to connect with.
unicomp21 commentedon Aug 12, 2020
If we get this thing working, and it catches on, it will beg a very large question. Browsers might be forced to introduce a vpn_wireguard_url w/ a vpn client embedded in the browser. Exciting times.
unicomp21 commentedon Aug 12, 2020
Wow, the future is starting to look a LOT simpler from a security perspective.
unicomp21 commentedon Aug 12, 2020
I wonder if we could get Mozilla to jump on board early.
vkrasnov commentedon Aug 13, 2020
Ha, your excitement is contagious! Yeah it doesn’t seem super complicated, definitely doable. Obviously if you want to send the packets over ws you need a server that can accept them, but this is almost trivial.
unicomp21 commentedon Aug 13, 2020
Lol, to quote someone, "You wanna make a dent in the planet?"
Mohsen7s commentedon Jan 22, 2022
I guess this will be the first VPN client over wasm since no other VPN protocol implemented to wasm. Is there any hope or its forgotten ?
Noah-Kennedy commentedon Jan 24, 2022
This issue was largely forgotten, but if there is interest, this can be pursued. I do not have the bandwidth to pursue this sadly, but contributions are welcome. If someone wants to look into what would be required to make this work, that would be a good first step here.
unicomp21 commentedon Jan 24, 2022
I think the CheerpX guys have something working internally over RTCDatachannel. Wouldn't this effort be best served by webtransport? Does cloudflare support webtransport yet? I think webtransport just went GA in chrome recently?
Noah-Kennedy commentedon Feb 14, 2022
This would be interesting with webtransport. I don't have the bandwidth to do this right now, but I would welcome any PRs.
XChikuX commentedon Feb 1, 2023
I hear that WebAssembly is going to support 'components' i.e. a secure way for different webassembly applications to securely talk to each other in the browser.
Not sure if that would kill the need for a virtual nic.
jeffparsons commentedon Feb 2, 2023
@XChikuX That's not quite what Wasm Components are for, and they don't obviate the need for a virtual NIC. If anything, a virtual VPN-integrated NIC would be implemented as a Wasm Component, and could be inserted at link time between an "application component" and the underlying runtime without the application component needing to have any knowledge of this.
(EDIT: you could think of this use case as
LD_PRELOADon steroids.)justin13888 commentedon Mar 7, 2024
Wondering if there are any updates on this?? Would porting boringtun to webassembly be too much of a technical effort given scope of the project?
Downchuck commentedon Sep 27, 2025
Going down this technical path here's what I see:
So -- yes, there are components one could glue together to do this in WASM and/or Javascript; for blake2s, x25519, chacha20 and poly1305 -- they're fast enough for client side use, but it's messy.
With BigInt being both "insecure" to timing attacks, and the Uint64BigInt being too tiny anyway, and without a u64 * u64 option in webassembly that's going to work, it's a bit complicated and inefficient.
I don't see a cross-compile from boringtun working out anyway - but if it were going to happen, I wouldn't really suggest championing the idea until and unless wide arithmetic is brought into standard use with webassembly.
All that set aside, it's just more likely to just use these things in JavaScript like x25519 in the web crypto API - and eventually chacha20-poly1305 in the api.