哪个有更多潜在漏洞？
#1 楼
SSL和SSH都提供了加密元素，以建立通道以检查机密数据并进行完整性检查。为此，它们使用类似的技术，并且可能遭受相同类型的攻击，因此，如果它们都已正确实施，则它们应提供类似的安全性（即良好的安全性）。两者都存在是一种NIH综合症：SSH开发人员应该在隧道部分重用SSL（SSL协议足够灵活，可以容纳许多变化，包括不使用证书）。隧道周围的东西。 SSL传统上使用X.509证书来宣布服务器和客户端公共密钥。 SSH有其自己的格式。而且，SSH附带了一套针对隧道内部内容的协议（多路传输，在隧道内执行基于密码的身份验证，终端管理...），而SSL中没有这种协议，或者更准确地说，当这样的东西在SSL中使用，它们不被认为是SSL的一部分（例如，当在SSL隧道中执行基于密码的HTTP身份验证时，我们说它是“ HTTPS”的一部分，但实际上它的工作方式与可以解决SSH发生的情况。）
从概念上讲，您可以使用SSH并用SSL中的隧道部分替换隧道部分。您还可以使用HTTPS并用SSH-with-data-transport和一个挂钩从SSL证书中替换服务器公用密钥来替换SSL内容。没有科学上的不可能，如果做得正确，安全性将保持不变。但是，目前还没有广泛的约定或现有工具。
因此，我们并没有将SSL和SSH用于相同的事物，这是因为这些协议的实现历来附带了哪些工具，不是由于安全方面的差异。无论是实施SSL还是SSH的人员，都建议查看两种协议都尝试过哪种攻击。
评论
做得好。实际上，由于SSH比SSL容易设置，因此许多人在SSH内通过HTTP（而非https）建立隧道，例如使用ebox或webmin等Web GUI工具进行远程系统管理。
–nealmcb
2011年1月17日17:58
只是要指出，SSH家伙“应该”使用SSL并不是完全正确的：SSH是专门为具有较小的攻击面而设计的，并且非常安全。 SSHv2在SSL / TLS中没有任何问题和陷阱，因此，他们以他们理解的较小的东西，较少的复杂性，开发出了更适合其情况的东西。这取决于您的偏执程度：根据应用程序的不同，SSL并非不可用，但是SSH的设计使其在根本不受信任的情况/安全社区中可以接受。
–尼古拉斯·威尔逊（Nicholas Wilson）
2012年5月11日18:01
@NicholasWilson“ SSH的设计使其在根本不值得信任SSL的情况/安全社区中可以接受”，例如...
–好奇
2012年6月21日15:49
SSL和SSH是并行开发的（均于1995年发布），因此尚不清楚SSH是否可以使用SSL。是否应该使用现代SSL 2.0也很可疑:-)
–user185
13年2月6日在18:27
嗯，SSH 2.0是对该协议的完全重写，并且在1999年左右出现了一段时间，因此人们可以重用SSL 3.0甚至TLS 1.0。但是，当然，TLS似乎与X.509绑定在一起，这使开发人员感到恐惧。
–托马斯·波宁（Thomas Pornin）
13年2月6日在18:53
#2 楼
这不是一个合理的比较。 SSL是一种保护通过网络传输的数据的通用方法，而SSH是一种用于登录并与远程计算机共享数据的网络应用程序。SSH中的传输层保护功能类似于SSL。 ，因此哪种方法“更安全”取决于您特定的威胁模型所需要的内容以及每种实现是否都可以解决您要解决的问题。
SSH具有用户身份验证层， SSL缺少（因为它不需要它-SSL只需要认证SSH也可以做的两个连接接口）。在UTF-8技术中：关于存在更多潜在攻击的问题，显然SSH具有更大的攻击面。但这仅仅是因为SSH内置了一个完整的应用程序：SSL的攻击面+您需要提供的任何应用程序都无法进行比较，因为我们没有足够的信息。
评论
-1这是一个合理的比较。您错误地假设OP正在将SSL与Unix程序ssh（1）进行比较。 SSH实际上是提供传输层安全性的另一种协议，它恰好具有针对远程Shell和远程执行的特殊规定。
– jpillora
2015年1月11日15:44
+1 @jpillora虽然我同意比较两者确实有意义，但术语SSH通常不用于表示处理与SSL / TLS直接可比的传输层安全性的SSH协议子集。它几乎专门用于参考应用层协议，该协议在此答案中描述的方式不同于SSL / TLS。
– freb
2015年5月4日，3：52
@freb的引用方式通常不会改变事情的真相。 SSH是一种协议，用作ssh实用程序的传输层。公认且投票最多的答案反映了这一事实。
– jpillora
2015年5月4日在4:22
@jpillora我只是说我不认为SSH传输层协议不是大多数人对问题的理解。但是，考虑到被认为是正确的答案，那一定是OP所要求的。
– freb
2015年5月5日，0：20
@freb是的，大多数人的确认为这是措辞，这使得纠正这种普遍的误解变得更加重要。
– jpillora
2015年5月5日，下午1:05
#3 楼
从严格的密码学角度来看，它们都提供经过身份验证的加密，但是以两种不同的方式。SSH使用所谓的Encrypt-and-MAC，即将加密后的消息与明文消息的消息认证代码（MAC）并置以增加完整性。事实证明，这种方式并不总是完全安全的（即使在实际情况下也足够了）。
SSL使用MAC-then-Encrypt：MAC与明文并置，那么两者加密。这也不是最好的，因为对于某些分组密码模式，MAC的某些部分可能是可猜测的，并且会在密码上揭示某些内容。这导致了TLS 1.0中的漏洞（BEAST攻击）。
因此它们都具有潜在的理论弱点。最强大的方法是Encrypt-then-MAC（添加加密消息的MAC），例如，在IPsec ESP中实现。
评论
SSH的二进制数据包协议是crypto-and-MAC，其中，对于每个纯文本消息（m），它都会发送密文E（m）++ MAC（m）（将加密消息与MAC连接），而SSL则发送E（m ++ MAC） （m））。但是，SSH不仅限于其二进制数据包协议（密钥管理，远程外壳客户端/服务器，进行文件传输等），而SSL（现在称为TLS）只是其他添加了其他协议的传输层协议。在必要的功能（例如HTTPS，FTPS，IMAPS等）中。另请参阅EtM，E＆M，MtE的比较，网址为：crypto.stackexchange.com/questions/202
– jimbob博士
13年5月9日在16:39
完全同意，除了我写的东西之外，还有很多东西。这就是我从严格的密码学角度出发的意思。
–哈伯迪尔
13年5月9日在20:55
BEAST与MtE不相关，并且是由于已知CIV（在SSL3和TLS1.0中）具有CBC-SSH2也可以，也不能纠正，尽管它在CTR和TLS都获得AEAD = GCM之前就已经选择了CTR。 （TLS和CCM）（以及ChaCha / Poly）作为更好的选择。基于MtE + CBC填充的攻击是POODLE和Lucky13。
–dave_thompson_085
18年5月30日在1:46
我有一个解决方案，可以使MAC-then-Encrypt对输出大小=输入大小且没有弱数据输入到密码核心的任何密码安全。
–约书亚
18年6月24日在21:19
这个答案已经过时了，因为今天的TLS并非如此。
– David天宇黄
19年11月3日在22:20
#4 楼
我认为这种比较的一个方面被忽略了。 user185接近了，但还没到那儿。我同意这些是苹果和橘子，并且与HTTPS和SSH相比，苹果感觉更好。 HTTPS和SSH利用OSI模型的不同层，因此在传输的不同时间加密数据。那么，真正要问的问题将是在传输过程中何时对这些数据进行加密和解密。这将揭示您的潜在攻击面。使用HTTPS，一旦目标网络中的设备（Web服务器，边界路由器，负载均衡器等）接收到该数据包，则该数据包将不被加密，并以纯文本方式花费其余的时间。许多人认为这不是什么大问题，因为此时流量是内部的，但是如果有效负载包含敏感数据，则将其未加密地存储在它经过的每个网络设备的日志文件中，直到到达最终目的地。通常，使用SSH时，将指定目标设备，并对传输进行加密，直到到达该设备为止。有一些重新加密HTTPS数据的方法，但是这些是在其环境中实现HTTPS解决方案时大多数忘记采取的额外步骤。#5 楼
ssh就像一把钥匙（私人），而锁（像公共钥匙一样）ssl就像门和砖头。
ssl提供了两个计算机服务器之间的安全链接。例如，您和您的连接对象。
ssh是连接计算机如何验证自身并获得访问权限的方法。
评论
您根本不解释“门和砖头”的注释。 SSL还具有公用和专用密钥。 SSL也可以用于客户端身份验证。 SSH还提供了客户端和服务器之间的安全链接。
– schroeder♦
7月1日10:06
#6 楼
SSL是从隧道内容中抽象出来的协议层。 SSH是Shell（SH）的安全版本，其设计目的不是在其下面包含抽象层，它是专门用于承载Shell流量的。因此，尽管两者都使用了加密操作，并且这些加密操作甚至可以相同，但目的和因此的总体设计是完全不同的。请记住，存在特定的差异（如前所述）以上），但大多数差异（如果不是全部的话）都基于不同协议的目的。
评论
-1您错误地假设OP正在将SSL与Unix程序ssh（1）进行比较。 SSH实际上是提供传输层安全性的另一种协议，它恰好具有针对远程Shell和远程执行的特殊规定。
– jpillora
2015年1月11日15:47
#7 楼
如果您真的在寻找SSH vs SSL（TLS），那么答案就是SSH。SSH胜过SSL的原因之一就是它执行身份验证的方式。因此，在使用FTP时，请使用SSH协议（SFTP）而不是FTPS（通过SSL的FTP）。
SSH在公司网络中用于以下用途：
为用户和自动过程提供安全访问
交互式和自动文件传输
发出远程命令
源：https：// www.ssh.com/ssh/protocol/#sec-Typical-uses-of-the-SSH-protocol
评论
“出于某种原因，SSH胜过SSL是它执行身份验证的方式。”您是否有此主张的出处或解释？
– AndrolGenhald
18年1月4日在16:29
在SSH中，有两个选项可以连接服务器。使用基于密钥的身份验证选项，首先需要预先生成SSH私钥和公钥。这没有太多的额外工作。这也是最佳安全做法。 SSL的版本太多，最新的版本是TLS1.2。这意味着它还没有那么安全，但是正在逐步变得更好。
–深
18年1月7日，下午1:35
TLS也具有客户端证书。您没有解释SSH为什么“胜出”的原因。
– schroeder♦
18年5月29日在14:13
如果要从某处复制/粘贴，请确保引用源。
– schroeder♦
18年5月29日在14:14
“ SSL有这么多版本”那么，“那么多”有6个版本吗？ OpenSSH的版本为7.7。 “这意味着还没有那么安全，但是正在逐步变得更好。”您的逻辑在这里毫无意义。
– schroeder♦
18年5月29日在14:18
#8 楼
问题有两个，不仅仅是加密的强项和弱项。但这就是交付的便捷性。因此，从业务角度来看，SSL / TLS更加方便和容易，因为它只需要一个浏览器以及一个公共或私有证书即可。而SSH则需要安装应用程序或瘦客户端才能使用它。从用户Internet客户端的角度和支持来看，这更是一个问题。
评论
这不是一个真正的问题。您正在比较苹果和桔子。如果您可以解释自己想知道的原因，这可能会有所帮助-因为这可能会指导答案。例如，您是否正在寻求实施安全的访问解决方案并且正在寻找最简单的安全方法？@Rory我不这么认为，因为我知道他们俩都做类似的工作（我不比较苹果和橘子），但是也许我错了，所以如果社区向我展示我的错误，我将非常感谢。
@ Am1rr3zA，他们做类似的工作并不完全正确。实际上，SSL和SSH通常用于不同的目的：SSH最常用于远程登录，SSL最常用于加密的Web访问。
@ D.W。看起来它们有时用于同一件事，例如SFTP似乎基于SSH，而FTPS基于SSL。
每个人都有自己的力量。因此，仅从黑客的角度来看它。您宁愿骇客？另外，应该问这个问题“对于... XYZ的目的，哪个更安全”，因为他问这个问题时并没有提供每个人都被困的目的。我关于安全与登录的示例显示了两个不同的目的（人们在这里说“嘿，这两个协议及其安全性通常在使用中不具有相同的功能”，这是绝对正确的。一个可能仍然是“更安全” ”。