Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making an SSH client the hard way

tailscale.com

Post reply on HN
Print view View original

51–60 of 108 posts

Re: Making an SSH client the hard way

#51

Post by apenwarr »

dekhn wrote: post #19
apenwarr wrote: post #16

Earlier quoted context omitted.

(I'm a tailscale cofounder) I think of Tailscale more like a set of tools that lets you do any architecture you want. Nobody has to use Tailscale ssh console, but if you believe in the future of wasm -> apps -> web console -> ssh, now you can have it. On the other hand, if you believe in the future of OS private network connectivity -> console -> ssh, then you had that already with native Tailscale and Tailscale ssh.…

Hi Avery. I think we may have chatted when I worked at Google (you can figure out my username pretty easily). To be honest I can't evaluate your product at work- to determine whether it helps our users and whether the idea of moving more of the network stack into the application makes sense- because my corporation (a large multinational pharma) disallows us from visiting the entire tailscale website because you sell…

"https with auth" is fine and good, and obviously the world has been heading in this direction. But I secretly suspect this is because 90%+ of developers nowadays don't know how to hack on any layer below http.

Tailscale is not a typical VPN; it's just a system that attempts to provide beyondcorp-like behaviour at a lower level of the stack, so that you don't have to rewrite all your apps (ssh in this case!) to use https, and don't have to have open ports in your firewall, and don't have to run everything through the cloud if you don't want.

As in my post above, there's more than one way to do it. You can also build traditional-beyondcorp-over-https on top of a Tailscale network, so you get all the improved network connectivity and also all the benefits of a "pure" beyondcorp architecture.

Re: Making an SSH client the hard way

#52

Post by lxgr »

PaulWaldman wrote: post #50

> 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 connection, to allow usage of SSH port forwarding without explicit SOCKS support on the app‘s side.

Re: Making an SSH client the hard way

#53

Post by lxgr »

Asmod4n wrote: post #49
dgentry wrote: post #13

Earlier 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.

And then the addon intercepts the loading of the Wasm code, injects it’s own payload into it and has access to the keys.

What keys? I think the implementation does not use regular SSH keys for SSH authentication, but rather something custom (I believe traffic to port 22 on each SSH enabled client is intercepted and the daemon handles authentication itself).

Re: Making an SSH client the hard way

#54

Post by gunapologist99 »

Spivak wrote: post #41
shp0ngle wrote: post #38

Earlier quoted context omitted.

It doesn’t have the keys, but it can inject any javascript and do whatever the user can do.

To me it seems they've taken all precautions they can reasonably take -- "what if the user installs a keylogger" isn't fixable by anyone.

"Installing a keylogger" is a vast oversimplification, even if it is outside of their threat model.

Installing almost anything in your browser is usually a matter of a couple of clicks.

Re: Making an SSH client the hard way

#55

Post by gunapologist99 »

Scaevolus wrote: post #43
vngzs wrote: post #10

This is really cool and fun, but is this a safe way to run SSH clients? If, say, the adblock Chrome extension you're using gets bought by a malware operator and backdoored[0], now it also has SSH and VPN access. [0]: https://www.wired.co.uk/article/fake-chrome-extensions-malwa...

If you have an actively malwared extension, there's probably an easier way to exploit any given target-- the simplest being recording passwords. There's not really a "safe" website when the browser is malicious.

This is turning a remote server into a previously "safe website" and expanding the threat model to include remote web browser attacks.

Re: Making an SSH client the hard way

#56

Post by lxgr »

kevin_thibedeau wrote: post #31
skybrian wrote: post #27

In 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?

It will never go away because you can't guarantee constant time algorithms will be implemented as such when transformed by a JIT.

If machine code can issue the necessary hints to the hardware to skip all time-variant optimizations, why couldn‘t the same work for a WASM runtime?

Re: Making an SSH client the hard way

#57

Post by lxgr »

easrng wrote: post #39
skybrian wrote: post #27

In 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?

Now that HTTPS is everywhere and crypto.getRandomValues provides a secure RNG I think most of the concerns are mitigated.

Maybe for Javascript, the language.

Definitely not for browsers as the execution environment, at least browsers running extensions.

Re: Making an SSH client the hard way

#58

Post by gunapologist99 »

This 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's backend (various types of injections, timing attacks, or deeper attacks on Tailscale's infrastructure like the nightmares of HeartBleed, Shellshock, Meltdown, etc)
That's probably a very incomplete list.

Realistically, this essentially (actually, literally) opens a remote root shell into your entire infrastructure through a web page, with apparently nothing more than matching an IP address pair (https://news.ycombinator.com/item?id=33361837) to authenticate.

What could go wrong?

This design with its loose coupling between authenticated user and IP addresses for high-value targets makes me view Tailscale's security model in a whole new light.

Re: Making an SSH client the hard way

#59

Post by sedatk »

gunapologist99 wrote: post #58

This 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 or whatever.

Similarly, Tailscale backend is already subject to the vectors you mentioned (API, side-channel attacks). This feature doesn't add any new attack vectors.

Again, attacks on browser means end of game already. Someone can use that vector to access to your local network in other ways. They don't need Tailscale's SSH web client for that.

Re: Making an SSH client the hard way

#60

Post by Serow225 »

lxgr wrote: post #52
PaulWaldman wrote: post #50

> 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…

SSHuttle was created by the CEO/co-founder of Tailscale :)
Post reply on HN