dsniff & httpsniffing

Question

我运行命令dsniff -i eth0，如果我打开一个新的终端窗口并尝试FTP服务器，连接和退出。dsniff返回用户名和密码。

如果我在google.com或其他webservices中尝试相同的操作，那么dsniff就不会报告pass和用户名。

为什么会这样呢？我使用的站点是否对这种攻击有免疫力？我对任何HTTP服务都没有任何进展。我用这个在我的本地主机上，为了测试目的，我想没有必要欺骗？

Answer 1

通过使用dsniff，您可以确切地了解为什么在开发具有身份验证的站点时，必须使用TLS来加密通信。

加密层会在“受保护的”隧道中混淆HTTP协议的内部工作，并且dsniff无法在正常情况下访问未加密的流。

要获得更多信息，我将留下一个指向TLS的链接，以及我在security/stackexchange中的答案。

https://security.stackexchange.com/questions/110914/https-is-able-to-prevent-arp-poison-attack-in-lan

来自https://en.wikipedia.org/wiki/Transport_层_安全性

该连接是私有的，因为对称加密用于加密传输的数据。此对称加密的密钥是为每个连接唯一生成的，并且基于会话开始时协商的秘密(参见握手协议)。服务器和客户端协商在传输数据的第一个字节之前要使用的加密算法和加密密钥的详细信息(请参阅算法)。共享秘密的协商既安全又可靠(协商后的秘密对窃听者不可用，即使是处于连接中间的攻击者也无法获得)和可靠(任何攻击者在协商期间都不能修改通信而不被检测到)。通信方的身份可以使用公钥密码体制进行身份验证。此身份验证可以是可选的，但通常至少对其中一方(通常是服务器)是必需的。该连接是可靠的，因为所发送的每条消息包括使用消息认证码的消息完整性检查，以防止在传输期间未被检测到的数据丢失或更改。