如今，大多数受密码保护的协议都使用TLS。这适用于邮件协议，HTTP和许多其他协议。新设计的QUIC还采用了TLS作为其加密层。

但是SSH却不同：它具有自己的加密层。加密层？ SSH拥有自己的加密层是否有任何好处？

关于SSH与其他协议之间的唯一区别是SSH经常发送只有一个按键的消息。如果消息非常短，SSH加密层是否更优化？

相关但不相同：从严格的加密角度来看，TLS与SSH有何不同？认为SSH可以支持SSH（自动学习）的证书验证机制。您只是没有根CA。您将分别接受每个证书，并记住接受。

评论

假设您是说SSL而不是TLS，那么SSH的发明者就在Twitter上-他看起来像个老家伙，所以您可以尝试问他：Tatu J Ylonen
“受密码保护的协议”是指大多数面向连接的客户端服务器全双工八位字节流协议吗？
我认为这是一个正确的想法，甚至我们可以提出其他要求：为什么TLS不是基于SSH构建的？无论如何，鉴于Linix Kernel部分支持TLS，因此在TLS上实现SSH很有意义

#1 楼

不使用TLS的SSH大多是历史悠久的；例如，参见此答案（关于security.SE）。实际上，可以完美地定义一种将TLS用于数据传输部分的SSH。但是，当然，它与现有的SSH服务器和客户端不兼容。从纯粹的加密角度来看，SSH实际上在其加密和MAC加密以及加密的“长度”字段方面存在一些缺陷。由于SSH的特定用法，这不会导致真正可利用的漏洞（攻击者不会使用部分选择的数据来触发数千个新的静默连接，这与TLS相反，这要归功于JavaScript的魔力） ，并且最近的AEAD集成基本上可以解决它们。

评论

$ \ begingroup $
而且，如果SSH在1995年选择了SSL传输（SSH太老了），它早就应该崩溃了。从本质上讲，NIH的选择在很长一段时间内都拒绝了几乎所有合理的攻击。多年来，由于SSL至少为4的加密垃圾，实际上仅发生了一次协议不兼容的更改。
$ \ endgroup $
–约书亚
18年6月24日在21:16
$ \ begingroup $
SSH的较新ETM模式及其对长度字段进行加密的chacha20-poly1305实现解决了其中的一些问题。
$ \ endgroup $
–森林
18年6月25日在2:41

#2 楼

如果使用TLS，则专门指一系列名为“ TLS”的协议，那么，为什么不设计SSH来使用它们的答案非常简单：在设计SSH时就不存在。 TLS在1999年发布，SSH在1995年发布。发行于1995年，与SSH同年。因此，很有可能在知道SSL之前至少已经部分设计了SSH。

SSL 1.0早在1994年就已存在，但从未作为协议发布，因为很快就发现它是严重损坏。这也可能削弱了Ylonen对SSL的信任，因此，即使他知道并考虑使用它，这也可能影响了他推出自己的SSL。

评论

$ \ begingroup $
您通常需要获得TLS证书，而不是仅直接信任密钥对指纹，这一事实与通常的SSH使用相比，通常是如何部署TLS的。您可以设计一个具有TLS隐含功能的SSH，以提示您像SSH一样仅信任密钥对。
$ \ endgroup $
–Rob
18年6月25日在19:57
$ \ begingroup $
@Rob直接信任密钥对是SSH的弱点。如果未通过侧通道验证密钥，则它将为第一个连接上的MitM攻击打开大门。如果随后的任何连接均不受影响，则将检测到攻击。
$ \ endgroup $
– StackOverthrow
18年6月25日在20:30
$ \ begingroup $
但是SSH用于企业设置中，在该设置中可以检查指纹。我认为，真正根本的问题是您根本不知道的东西的巨大信任库。 （即：如果您不居住在土耳其，则土耳其CA应该被称为“土耳其情报局”。）浏览器有太多的信任关系。在非浏览器环境和企业中，消除除内部CA中的所有信任之外的所有信任非常普遍。
$ \ endgroup $
–Rob
18年6月25日在21:19
$ \ begingroup $
@Rob FileZilla Client上FTPS（FTP / TLS）的安全模型不是基于强制性CA（不同于Web浏览器），而是基于“向用户询问新的公共密钥，然后保留并信任”作为首次使用信任（“ TOFU”）。
$ \ endgroup $
–好奇
18年6月26日在22:51