5 ms·

I'm not a security researcher, but somehow I suspect the "maintaining connection while switching networks" holds potential for a flaw.

teejmya 11y ago
If my client session dies (laptop kernel panics or runs out of battery) then mosh will notify me on the next login that "there are sessions running with these PIDs" I've tried to reattach sessions to no avail, mosh was designed this way. I have to just kill the sessions. Looks like I'm not alone in this either: https://github.com/mobile-shell/mosh/issues/394 https://github.com/mobile-shell/mosh/issues/394
- gue5t 11y ago
  There's no way to know if a machine you can't contact is on the other side of a network partition or if it has died/disconnected/given up. You could have the client try to persist its state across local reboots, at least to the extent necessary to kill the session (in case the latest crypto state needed to resume couldn't be saved before the system died), in which case you would have to kill fewer sessions.
geofft 11y ago
Can you describe what you're worried about? The connection is set up over SSH, and mosh-client generates a random AES-OCB key and sends it to mosh-server. Packets are sent over UDP, protected using authenticated encryption, and discarded if they fail integrity protection (which is fine, since packets could just be dropped and perhaps corrupted anyway because of bad network connections). Replayed packets are invalid. At that point the client's IP address no longer matters, since it's the only entity with the key. The server accepts valid packets from anywhere, and also sends packets to the IP address that most recently sent it a valid packet. This should as much protection as an SSH connection over TCP. One thing I'd worry about is whether the server or client can be DoS'd with invalid packets. Is there anything else that seems concerning?
- aerovistae 11y ago
  I guess I was thinking about something involving a principle similar to session fixation, but it was just a passing thought. Your methodologies seem sound.
  - geofft 11y ago
    Yeah, I think in order for session fixation to work, you have to have multiple connections trying to use the same session, and trick one of them into reattaching to the wrong session. For HTTP + cookies, that's doable. But the only concept of a "connection" in mosh is this key shared between client and server and only stored in RAM, and there's exactly one session per server process, and one client per server. A new connection is a new session (you have to use screen or something if you want to connect to an old terminal). There are occasional requests for the ability to write out the client key and cryptographic state to disk, so you can reboot your machine, kill and restart a process on Android, etc. without losing your connection. But they've been pushing back because it breaks this straightforwardness.

teejmya 11y ago

If my client session dies (laptop kernel panics or runs out of battery) then mosh will notify me on the next login that "there are sessions running with these PIDs" I've tried to reattach sessions to no avail, mosh was designed this way. I have to just kill the sessions. Looks like I'm not alone in this either: https://github.com/mobile-shell/mosh/issues/394 https://github.com/mobile-shell/mosh/issues/394

gue5t 11y ago
There's no way to know if a machine you can't contact is on the other side of a network partition or if it has died/disconnected/given up. You could have the client try to persist its state across local reboots, at least to the extent necessary to kill the session (in case the latest crypto state needed to resume couldn't be saved before the system died), in which case you would have to kill fewer sessions.

geofft 11y ago

Can you describe what you're worried about? The connection is set up over SSH, and mosh-client generates a random AES-OCB key and sends it to mosh-server. Packets are sent over UDP, protected using authenticated encryption, and discarded if they fail integrity protection (which is fine, since packets could just be dropped and perhaps corrupted anyway because of bad network connections). Replayed packets are invalid. At that point the client's IP address no longer matters, since it's the only entity with the key. The server accepts valid packets from anywhere, and also sends packets to the IP address that most recently sent it a valid packet. This should as much protection as an SSH connection over TCP. One thing I'd worry about is whether the server or client can be DoS'd with invalid packets. Is there anything else that seems concerning?

aerovistae 11y ago
I guess I was thinking about something involving a principle similar to session fixation, but it was just a passing thought. Your methodologies seem sound.
- geofft 11y ago
  Yeah, I think in order for session fixation to work, you have to have multiple connections trying to use the same session, and trick one of them into reattaching to the wrong session. For HTTP + cookies, that's doable. But the only concept of a "connection" in mosh is this key shared between client and server and only stored in RAM, and there's exactly one session per server process, and one client per server. A new connection is a new session (you have to use screen or something if you want to connect to an old terminal). There are occasional requests for the ability to write out the client key and cryptographic state to disk, so you can reboot your machine, kill and restart a process on Android, etc. without losing your connection. But they've been pushing back because it breaks this straightforwardness.