5 ms·

This significantly increases the threat model for your remote servers to include all sorts of remote attacks through the web, including: * garden-variety web

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

sedatk 4y ago
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.
- gunapologist99 4y ago
  > 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.
  - sedatk 4y ago
    A malicious browser extension can access your email, SSO prompts, password manager, etc, and therefore gain access to your Tailscale network anyway. SSH web doesn't add a new threat vector here. It's already game over.
    - ipaddr 4y ago
      A browser extension cannot access your email or password manager. But it can use this new security hole created by tailscale.
      - yjftsjthsd-h 4y ago
        If the extension in question has the read/modify all websites permission, why would it not be able to access your email or password manager?
        r2_pilot 4y ago
        Who's using extensions in a work context anyway? I only use an ad-blocker because it's safer from a malware perspective.
        throwawaaarrgh 4y ago
        > Who's using extensions in a work context anyway? literally everyone?
        francislavoie 4y ago
        React Developer Tools, for example.
        r2_pilot 4y ago
        Ah, thanks. I'm more on sysadmin side for my day job, and didn't even know about this. I'll have to keep it in mind as I've been dabbling with learning a modern web framework and React was a candidate.
ignoramous 4y ago
Well, this exists: https://engineering.fb.com/2022/03/10/security/code-verify/ https://engineering.fb.com/2022/03/10/security/code-verify/
deleted 4y ago
[deleted]
dgentry 4y ago
(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.
- otterley 4y ago
  Given the apparent (yet possibly unfounded) concern, it might be useful to discuss this issue in the blog post. Would you consider updating it?
  - mynameisvlad 4y ago
    Doesn't the post say exactly what the parent comment did? It explains the process that they came up with the WASM Tailscale, and how it authorizes and works. If anything, the parent comment just paraphrased the article.
    - elcomet 4y ago
      It doesn't paragraph, this is the important sentence > Connections opened from the browser engine don't get the ability to reach the tailnet. That was not really explained in the article. Maybe it's obvious to some people, but I'm sure it's not for many.
_hyn3 4y ago
This seems to really expand the scope of how keys are handled and authorized. It at least appears to be optional, however. Or just use userify's public key distribution model (then you can stick with a simple and proven design that just automates the standard SSH design that's been around for decades) Or just do it the old way, by hand: drop your teams' public keys on groups of remote servers, setup their sudo access, and you're done. Or just use Ansible or Chef or Terraform, or any of those other server orchestration tools, too (just without the permission layer/bulk remote session kills/user deletes of Userify). of course, if you really need an ssh terminal in a browser, then you have to go with one of these sorts of crazy things, and at least it's not using passwords!
deleted 4y ago
[deleted]

sedatk 4y ago

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.

gunapologist99 4y ago
> 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.
- sedatk 4y ago
  A malicious browser extension can access your email, SSO prompts, password manager, etc, and therefore gain access to your Tailscale network anyway. SSH web doesn't add a new threat vector here. It's already game over.
  - ipaddr 4y ago
    A browser extension cannot access your email or password manager. But it can use this new security hole created by tailscale.
    - yjftsjthsd-h 4y ago
      If the extension in question has the read/modify all websites permission, why would it not be able to access your email or password manager?
      - r2_pilot 4y ago
        Who's using extensions in a work context anyway? I only use an ad-blocker because it's safer from a malware perspective.
        throwawaaarrgh 4y ago
        > Who's using extensions in a work context anyway? literally everyone?
        francislavoie 4y ago
        React Developer Tools, for example.
        r2_pilot 4y ago
        Ah, thanks. I'm more on sysadmin side for my day job, and didn't even know about this. I'll have to keep it in mind as I've been dabbling with learning a modern web framework and React was a candidate.

ignoramous 4y ago

Well, this exists: https://engineering.fb.com/2022/03/10/security/code-verify/ https://engineering.fb.com/2022/03/10/security/code-verify/

deleted 4y ago

[deleted]

dgentry 4y ago

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

otterley 4y ago
Given the apparent (yet possibly unfounded) concern, it might be useful to discuss this issue in the blog post. Would you consider updating it?
- mynameisvlad 4y ago
  Doesn't the post say exactly what the parent comment did? It explains the process that they came up with the WASM Tailscale, and how it authorizes and works. If anything, the parent comment just paraphrased the article.
  - elcomet 4y ago
    It doesn't paragraph, this is the important sentence > Connections opened from the browser engine don't get the ability to reach the tailnet. That was not really explained in the article. Maybe it's obvious to some people, but I'm sure it's not for many.

_hyn3 4y ago

This seems to really expand the scope of how keys are handled and authorized. It at least appears to be optional, however. Or just use userify's public key distribution model (then you can stick with a simple and proven design that just automates the standard SSH design that's been around for decades) Or just do it the old way, by hand: drop your teams' public keys on groups of remote servers, setup their sudo access, and you're done. Or just use Ansible or Chef or Terraform, or any of those other server orchestration tools, too (just without the permission layer/bulk remote session kills/user deletes of Userify). of course, if you really need an ssh terminal in a browser, then you have to go with one of these sorts of crazy things, and at least it's not using passwords!

deleted 4y ago

[deleted]