> To make this possible, we ported the following to WebAssembly: the Tailscale client, WireGuard®, a complete userspace network stack (from gVisor), and an SSH client. I love that they were clearly inspired by fly.io. Warms my heart that a random blog post with a good idea can spread like this.
Which blog post are you referring to? But yes, we love Fly and use them (and they use us) and we share a slack channel between our two companies for casual banter.
Making an SSH client the hard way
61–70 of 108 posts
Re: Making an SSH client the hard way
#62Hi Mihai! Great work! I would love to see where this goes! Forgive my ignorance but is there any sort of native client besides the browser running in the background to help with websocket to tcp? Or a tunnel to a cloud service to help there?
No native client is running. The browser makes a WebSocket connection to our relay server, and we run the WireGuard tunnel over that.
You mean WireGuard (in userspace w/ netstack) tunneled in WebSockets to DERPServers, correct? What sorcery is this. (:
Re: Making an SSH client the hard way
#63In the old days, people said you shouldn't write crypto in JavaScript because it was somehow insecure. Have those concerns gone away with WebAssembly and https everywhere?
I don't think the argument was ever that "JavaScript was insecure." It was that the websites hosting it may be compromised or may change the script at any time without any indication (or the FBI forcing a site to backdoor the JS for some investigation)
Yeah, but see also Code Verify (and sub-resource integrity): https://blog.cloudflare.com/cloudflare-verifies-code-whatsap...
Re: Making an SSH client the hard way
#64This significantly increases the threat model for your remote servers to include all sorts of remote attacks through the web, including: * garden-variety web attacks (i.e., XSS, CRSF, etc) * attacks that might become viable against the browser (for example, Mobile Safari has a history of vulnerabilities) * various attacks against the backend web server (API attacks) * attacks against the WASM layer * CDN injections *…
Well, this exists: https://engineering.fb.com/2022/03/10/security/code-verify/
Re: Making an SSH client the hard way
#65This significantly increases the threat model for your remote servers to include all sorts of remote attacks through the web, including: * garden-variety web attacks (i.e., XSS, CRSF, etc) * attacks that might become viable against the browser (for example, Mobile Safari has a history of vulnerabilities) * various attacks against the backend web server (API attacks) * attacks against the WASM layer * CDN injections *…
[deleted]
Re: Making an SSH client the hard way
#66> To make this possible, we ported the following to WebAssembly: the Tailscale client, WireGuard®, a complete userspace network stack (from gVisor), and an SSH client. Would it be possible to bundle the same into a portable application allowing you to use Tailscale without installing it? My understanding is that currently if you can't install Tailscale on a client you need to use Subnet Router. https://tailscale.com/…
You‘d have to redirect all network usage (i.e. the sockets API or your platform‘s equivalent) through the custom stack, which is possible if you can rebuild the source or by using something like LD_PRELOAD for binaries, but can get very tricky in the general case. There‘s an utility called SSHuttle that does something similar for SSH instead of Tailscale/Wireguard: It redirects all sockets usage to go through an SSH…
. You can use tools like proxychains to leverage LD_PRELOAD to redirect all network traffic via a socks5 proxy.
Tailscaled comes with a socks5 proxy
Re: Making an SSH client the hard way
#67Earlier quoted context omitted.
The Tailscale VPN client, the same one which runs on other devices, is compiled to WASM. It handles all of the key exchanges to connect to the tailnet. The SSH session is running as a WASM Tailscale client. The browser, opening connections from within the browser engine, doesn't have the keys for SSH or VPN access.
It doesn’t have the keys, but it can inject any javascript and do whatever the user can do.
Like intercepting your oauth token next time you login into SSO and then use that to access your tailnet.
This was true even before this new feature.
The new threat model is entirely psychological.
Re: Making an SSH client the hard way
#68This significantly increases the threat model for your remote servers to include all sorts of remote attacks through the web, including: * garden-variety web attacks (i.e., XSS, CRSF, etc) * attacks that might become viable against the browser (for example, Mobile Safari has a history of vulnerabilities) * various attacks against the backend web server (API attacks) * attacks against the WASM layer * CDN injections *…
(Tailscale employee)
It is not a web page with a shell open.
It is the Tailscale client, compiled to WASM, maintaining the keys for connections to nodes on the tailnet. Connections opened from the browser engine don't get the ability to reach the tailnet.
Re: Making an SSH client the hard way
#69This significantly increases the threat model for your remote servers to include all sorts of remote attacks through the web, including: * garden-variety web attacks (i.e., XSS, CRSF, etc) * attacks that might become viable against the browser (for example, Mobile Safari has a history of vulnerabilities) * various attacks against the backend web server (API attacks) * attacks against the WASM layer * CDN injections *…
That's unnecessary sensationalism. Most of those vectors are behind an SSO login and are not exposed to Internet at all (from the article: "your browser becomes a Tailscale client, and joins your tailnet in the same way as any other device that you run Tailscale on"). Or, did you mean attacks on SSO? If that's the case, then SSH web wouldn't make any difference. Someone authenticating themselves could use regular SSH…
> Again, attacks on browser means end of game already.
A bad Chrome extension does not allow the bad guys to open a terminal on my machine, load my ssh keys, launch an authenticated SSH connection, and launch an authenticated SSH connection into an enumerated list of remote servers.
Re: Making an SSH client the hard way
#70Earlier quoted context omitted.
How does a VM or sandboxing help anything? The whole point of wireguard is to get the (shitty) OS VPN out of the picture entirely. Give me a stream of bytes and let the whole world see it for all I care--wireguard will build a secure private network entirely on that stream of bytes. It could be totally public coffee shop wifi with zero encryption (basically yelling your passwords and secrets out in the open) and yet…
The VM encapsulates the OS component for networking and networking virtualization. In my experience, the virtualized software stack in the VM host is very reliable and predictable, and all the existing OS tools I need as a sysadmin (like tshark, ip, and other commands) all work just fine for debugging. I understand the desire for moving more TCP logic to applications but, given my experience with network technology,…
Yeah, in a way we're already there.
It gives a new meaning to "my computer is a datacenter" phrase.
we easily run multiple VMs kn the same laptop with multiple kernels with multiple TCP/IP implementations; even withing the same OS user space programs come with their own DNS resolvers that ignore system wide settings (Go without cgo, I'm thinking of you), and soon we're going to have a proliferation of user space networking stacks.