<div dir="ltr"><div>Hi Keith,</div><div><br></div><div>The replies in this thread have been incredibly helpful and even more</div><div>than we had hoped for! Thank you to all!</div><div><br></div><div>Just this evening Simon and I put together a nice PDF summarizing the responses (including a link to this thread) and sent</div><div>it to the Broad director of IT. We&#39;ve met with him before and hope to</div><div>meet again, after he reads it, to further discuss Mosh. In case you</div><div>think this document would be helpful, I&#39;m more than happy to share it</div><div>in private; I&#39;ll email it to you directly.</div><div><br></div><div>Thanks again! We&#39;ll absolutely be in touch if we think there are</div><div>additional ways you or Mosh&#39;s community can help us.</div><div><br></div><div>Best,</div><div>Hayden</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 12, 2015 at 8:06 PM Keith Winstein &lt;<a href="mailto:keithw@cs.stanford.edu">keithw@cs.stanford.edu</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Hayden,<div><br></div><div>The thread seems to have run its course -- do you have enough to proceed, or how can we help you move forward?</div><div><br></div><div>Best regards,</div><div>Keith</div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 7, 2015 at 4:33 PM, Hayden Metsky <span dir="ltr">&lt;<a href="mailto:hayden@mit.edu" target="_blank">hayden@mit.edu</a>&gt;</span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
mosh-devel mailing list<br>
<a href="mailto:mosh-devel@mit.edu" target="_blank">mosh-devel@mit.edu</a><br>
<a href="http://mailman.mit.edu/mailman/listinfo/mosh-devel" rel="noreferrer" target="_blank">http://mailman.mit.edu/mailman/listinfo/mosh-devel</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div>