drs*_*drs 8 ssh ssl vulnerability poodle
在新发现的 POODLE 漏洞之后，我想在我的所有 SSH 服务器上禁用 SSLv3。我如何使用 OpenSSH 实现这一目标？
slm*_*slm 22
这对 OpenSSH 来说不是问题，因为它不使用 SSL。
摘录 - SSL 与 SSH 有什么区别？哪个更安全？他们对隧道周围的事物有所不同。SSL 传统上使用 X.509 证书来公布服务器和客户端公钥；SSH 有自己的格式。此外，SSH 附带了一组用于隧道内部内容的协议（多路传输、在隧道内执行基于密码的身份验证、终端管理......），而 SSL 中没有这样的东西，或者更准确地说，当这些东西用在 SSL 中，它们不被认为是 SSL 的一部分（例如，在 SSL 隧道中进行基于密码的 HTTP 身份验证时，我们说它是“HTTPS”的一部分，但它确实以类似的方式工作SSH 会发生什么）。
从概念上讲，您可以使用 SSH 并用 SSL 中的隧道部分替换隧道部分。您还可以采用 HTTPS 并将 SSL 替换为 SSH-with-data-transport 和一个钩子，以从其证书中提取服务器公钥。没有科学上的不可能性，如果处理得当，安全性将保持不变。但是，没有广泛的一套约定或现有工具。
作为进一步的证据，我会将您引向RFC 4253，其中讨论了“安全外壳 (SSH) 传输层协议”。这是 SSH 自己的自定义传输层，它与 HTTPS/SSL 使用的不同。
本文档描述了 SSH 传输层协议，它通常运行在 TCP/IP 之上。该协议可用作许多安全网络服务的基础。它提供强大的加密、服务器身份验证和完整性保护。它还可以提供压缩。
最后，来自安全 SE 站点的问答题为：SSL3“贵宾犬”漏洞是关于贵宾犬攻击的。
摘抄Poodle 攻击在选择的明文上下文中起作用，例如之前的 BEAST 和 CRIME。攻击者对使用 SSL 保护的数据感兴趣，他可以：
- 在他想要获取的秘密值前后注入自己的数据；
- 检查、拦截和修改线路上的结果字节。
满足这些条件的主要和唯一可能的场景是 Web 上下文：攻击者运行一个虚假的 WiFi 接入点，并注入一些他自己的 Javascript 作为受害者浏览的网页（HTTP，而不是 HTTPS）的一部分。邪恶的 Javascript 使浏览器向受害者的浏览器具有 cookie 的 HTTPS 站点（例如银行网站）发送请求。攻击者想要那个cookie。
因此，无需针对此特定威胁对 OpenSSH 采取任何措施。