<story><title>Call for testing: OpenSSH 8.0</title><url>https://lists.mindrot.org/pipermail/openssh-unix-dev/2019-March/037672.html</url></story><parent_chain><item><author>segfaultbuserr</author><text>It includes an interesting comment on the scp vulnerability.&lt;p&gt;&amp;gt; This release contains mitigation for a weakness in the scp(1) tool and protocol (CVE-2019-6111) [...] &lt;i&gt;The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead.&lt;/i&gt;&lt;p&gt;I think it&amp;#x27;s the time to &amp;quot;alias scp=sftp&amp;quot;. If the developers officially believe that scp should be retired, let&amp;#x27;s do the switch. Both are parts of OpenSSH and the commandline argument is almost identical.&lt;p&gt;Also, it has&lt;p&gt;&amp;gt; &lt;i&gt;ssh(1), sshd(8): Add experimental quantum-computing resistant key exchange method, based on a combination of Streamlined NTRU Prime 4591^761 and X25519.&lt;/i&gt;&lt;p&gt;This is big. Together with XMSS signature, it means we already have a complete suite of post-quantum cryptography (experimentally) deployed in OpenSSH! It may be the first mass deployment of post-quantum cryptography in a major protocol.&lt;p&gt;One month ago, I commented that the introduction of XMSS post-quantum signature as &amp;quot;useless&amp;quot; (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=19160739&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=19160739&lt;/a&gt;), as the decryption of key exchange is much more vulnerable than spoofing the signature. But now NTRU+X25519 is deployed, great progress here!</text></item></parent_chain><comment><author>MayeulC</author><text>Frankly, I had not realized scp and sftp were two distinct protocols, despite my heavily using them. I thought sftp was an interactive client, while scp was meant for scripting, and never really bothered to dig further. I now will, thank you.&lt;p&gt;However, I expect plenty of people to be in the same case.</text></comment>
<story><title>Call for testing: OpenSSH 8.0</title><url>https://lists.mindrot.org/pipermail/openssh-unix-dev/2019-March/037672.html</url></story><parent_chain><item><author>segfaultbuserr</author><text>It includes an interesting comment on the scp vulnerability.&lt;p&gt;&amp;gt; This release contains mitigation for a weakness in the scp(1) tool and protocol (CVE-2019-6111) [...] &lt;i&gt;The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead.&lt;/i&gt;&lt;p&gt;I think it&amp;#x27;s the time to &amp;quot;alias scp=sftp&amp;quot;. If the developers officially believe that scp should be retired, let&amp;#x27;s do the switch. Both are parts of OpenSSH and the commandline argument is almost identical.&lt;p&gt;Also, it has&lt;p&gt;&amp;gt; &lt;i&gt;ssh(1), sshd(8): Add experimental quantum-computing resistant key exchange method, based on a combination of Streamlined NTRU Prime 4591^761 and X25519.&lt;/i&gt;&lt;p&gt;This is big. Together with XMSS signature, it means we already have a complete suite of post-quantum cryptography (experimentally) deployed in OpenSSH! It may be the first mass deployment of post-quantum cryptography in a major protocol.&lt;p&gt;One month ago, I commented that the introduction of XMSS post-quantum signature as &amp;quot;useless&amp;quot; (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=19160739&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=19160739&lt;/a&gt;), as the decryption of key exchange is much more vulnerable than spoofing the signature. But now NTRU+X25519 is deployed, great progress here!</text></item></parent_chain><comment><author>bArray</author><text>Checking out the mitigation for CVE-2019-6111 [1], how does `sftp` help?&lt;p&gt;&lt;pre&gt;&lt;code&gt;     * scp(1): Relating to the above changes to scp(1); the scp protocol
       relies on the remote shell for wildcard expansion, so there is no
       infallible way for the client&amp;#x27;s wildcard matching to perfectly
       reflect the server&amp;#x27;s. If there is a difference between client and
       server wildcard expansion, the client may refuse files from the
       server. For this reason, we have provided a new &amp;quot;-T&amp;quot; flag to scp
       that disables these client-side checks at the risk of
       reintroducing the attack described above.
&lt;/code&gt;&lt;/pre&gt;
You could just do a remote `ls` and then `sftp` all the files listed to your client - nothing stopping a malicious return from `ls`? Surely it&amp;#x27;s the risk of running any kind of wild card copy? If the server is compromised then there&amp;#x27;s no telling what will be returned from such a command?&lt;p&gt;&lt;pre&gt;&lt;code&gt;    The scp protocol is outdated, inflexible and not readily fixed. We
    recommend the use of more modern protocols like sftp and rsync for
    file transfer instead.
&lt;/code&gt;&lt;/pre&gt;
The protocol itself might be outdated, but surely one of the best aspects of `scp` comes from its simplicity [2]?&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;cve.mitre.org&amp;#x2F;cgi-bin&amp;#x2F;cvename.cgi?name=CVE-2019-6111&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;cve.mitre.org&amp;#x2F;cgi-bin&amp;#x2F;cvename.cgi?name=CVE-2019-6111&lt;/a&gt;&lt;p&gt;[2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;openssh&amp;#x2F;openssh-portable&amp;#x2F;blob&amp;#x2F;master&amp;#x2F;scp.c&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;openssh&amp;#x2F;openssh-portable&amp;#x2F;blob&amp;#x2F;master&amp;#x2F;scp....&lt;/a&gt;</text></comment>