<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">On Fri, Aug 7, 2015 at 4:33 PM, Hayden Metsky <span dir="ltr"><<a href="mailto:hayden@mit.edu" target="_blank">hayden@mit.edu</a>></span> wrote:<br><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'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'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've both used mosh elsewhere and loved it.) Unfortunately we've</div><div>encountered resistance from the security team, who have cited a number</div><div>of security concerns. We've responded to many of these concerns but</div><div>have made little progress. Of course, the security team'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'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'll</div><div>include a short note from myself giving our thoughts.</div><div><br></div><div>* "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 ("Smack" 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."</div><div> - This is the team'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>* "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."</div><div><br></div><div>* "Both Google and Mozilla have rejected mosh."</div><div> - I don'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'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>* "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."</div><div><br></div><div>* "Mosh requires server-side modification to /etc/sshd_config to enable</div><div> 'SendEnv LANG LC_*'; this is turned off by default to protect against</div><div> environment variable injection."</div><div> - There's a lot that's misleading or incorrect about this. First, I</div><div> think they mean 'AcceptEnv' rather than 'SendEnv'. On many OS's,</div><div> it is my understanding that this is actually turned *on* by default.</div><div> When I run 'ssh broad locale', I receive back my laptop'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'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>* "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."</div><div> - We'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'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>_______________________________________________<br>
mosh-devel mailing list<br>
<a href="mailto:mosh-devel@mit.edu">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>