<div dir="ltr"><div>Hi,</div><div><br></div><div>A friend (Simon Ye, CC&#39;d) and I are PhD students at MIT who are</div><div>currently working at the Broad Institute (a genomics center) using</div><div>their computing infrastructure. The standard workflow is to use ssh to</div><div>connect to a login server and then do work on that. This login server</div><div>is accessible from anywhere (including outside the VPN) and password</div><div>is the sole method of authentication.</div><div><br></div><div>We would like the Broad Institute&#39;s IT staff to unblock UDP ports</div><div>60000-61000 so that we can use mosh to connect to the login servers.</div><div>(We&#39;ve both used mosh elsewhere and loved it.) Unfortunately we&#39;ve</div><div>encountered resistance from the security team, who have cited a number</div><div>of security concerns. We&#39;ve responded to many of these concerns but</div><div>have made little progress. Of course, the security team&#39;s view is</div><div>going to be biased in a conservative direction.</div><div><br></div><div>Since networking and computer security are well outside our area of</div><div>expertise, we think it would be helpful to pass the concerns along to</div><div>mosh&#39;s developers. We would love to hear your thoughts; obviously we</div><div>would welcome rebuttals, but we would also be happy to hear if you</div><div>think the concerns have validity.</div><div><br></div><div>Below I am going to quote six concerns verbatim from a document</div><div>written by the security team. Under some of these concerns I&#39;ll</div><div>include a short note from myself giving our thoughts.</div><div><br></div><div>* &quot;Mosh requires opening UDP ports on the Broad perimeter. That makes</div><div>  the Broad network available as a participant in a DDoS performed</div><div>  against external entities, specifically ICMP PORT UNREACHABLE class of</div><div>  attack (&quot;Smack&quot; is one productized version). Even unwitting</div><div>  participation by the Broad in a DDoS could have materially damaging</div><div>  effect upon the Broad as a whole and the outcome of such an event</div><div>  would inevitably involve closing the ports anyway.&quot;</div><div>   - This is the team&#39;s primary concern. Our initial thought is that it</div><div>     is difficult to imagine a single machine (server or router) having</div><div>     a meaningful impact in a DDoS amplification, but perhaps this is</div><div>     mistaken. Or maybe it is possible to use mosh with restrictions on</div><div>     outgoing traffic that would avoid the Broad from participating in</div><div>     this kind of attack? Even though this is not specific to mosh, we</div><div>     would very much appreciate your thoughts.</div><div><br></div><div>* &quot;Mosh is based on the experimental MIT State Synchronization Protocol</div><div>  (SSP). SSP is not know to any commercially available firewalls or</div><div>  perimeter devices, so the use of mosh would not be manageable. Also</div><div>  the first UDP mosh packet is from client to server. That underscores</div><div>  the fact that there is no way for a firewall to have any control of</div><div>  state.&quot;</div><div><br></div><div>* &quot;Both Google and Mozilla have rejected mosh.&quot;</div><div>   - I don&#39;t know about Mozilla, but my understanding is that this is</div><div>     incorrect with regard to Google. Even if Google only allows mosh</div><div>     access from within a VPN and we&#39;re asking the Broad to allow access</div><div>     from outside (ssh is allowed from outside), it is difficult to see</div><div>     how this is an argument against mosh.</div><div><br></div><div>* &quot;Mosh sends the session key as an environment variable. User-</div><div>  controlled environment variables are an injection path - their use</div><div>  for sensitive purposes opens security vulnerabilities.&quot;</div><div><br></div><div>* &quot;Mosh requires server-side modification to /etc/sshd_config to enable</div><div>  &#39;SendEnv LANG LC_*&#39;; this is turned off by default to protect against</div><div>  environment variable injection.&quot;</div><div>   - There&#39;s a lot that&#39;s misleading or incorrect about this. First, I</div><div>     think they mean &#39;AcceptEnv&#39; rather than &#39;SendEnv&#39;. On many OS&#39;s,</div><div>     it is my understanding that this is actually turned *on* by default.</div><div>     When I run &#39;ssh broad locale&#39;, I receive back my laptop&#39;s locale</div><div>     (even after changing it), indicating that the server is accepting</div><div>     my LANG/LC_* env variables. So I suspect this is in fact turned on</div><div>     (I cannot read the file). Regardless, we&#39;re able to install mosh</div><div>     and use it internally among nodes, which we believe suggests that</div><div>     no changes need to be made (besides unblocking ports).</div><div><br></div><div>* &quot;The mosh client can, at startup, invoke any program on the server.</div><div>  The program does not have to be the mosh-server. So it is an</div><div>  unrestricted and unmonitored remote execution environment like rsh.&quot;</div><div>   - We&#39;re a bit confused on this point. The same (we believe) is true</div><div>     of ssh, and since mosh authenticates via ssh we don&#39;t quite see how</div><div>     this might be held against mosh given that ssh is already used.</div><div><br></div><div>Thank you all so much for looking at this!</div><div><br></div><div>Best,</div><div>Hayden</div></div>