我注意到我们在工作中以编程方式使用了一个第三方 Web 服务来传输一些敏感信息，我很惊讶地看到端点只使用 http，而不是 https。经过进一步调查，该网络服务似乎正在使用一个whilelist，这意味着理论上只有实际使用该服务的我们的服务器才能访问。
我想知道使用白名单是否足以防止嗅探/中间人攻击？作为我们团队中具有安全意识的成员，我显然支持在传输潜在敏感数据的任何地方使用 https，但我不确定与受控白名单结合使用是否会过度杀伤或不必要。
显然，与我们服务器位于同一网段的恶意内部人员可能能够清楚地观察到这种通信。但为了争论，我想假设这种情况不太可能发生。
嗅探问题是关于“机密性”，白名单不包括在内，因为流量可以被拦截和读取。
MitM 问题是关于“真实性”的，白名单也不包括在内，因为截获的数据包可以在没有篡改证据的情况下进行修改。我假设白名单使用 IP 地址，可以任意强制进入 TCP/IP 数据包。
如果数据未加密，任何在您的服务器和他们的服务器之间嗅探数据包的人都可以看到它。白名单只允许他们的服务器验证数据的来源。它不能保证在传输过程中没有人嗅到它，或者它在过程中的任何时候都没有被拦截和操纵。
简而言之，加密数据，保留白名单，并设置校验和验证，以确保发送的内容与接收的内容相同。
在谈论安全性（一般而言）时，重要的是要考虑您正在尝试解决哪些问题，以及您使用哪些工具来解决这些问题。这些必须对齐。
如果您试图解决的问题是来自 Internet 的一般攻击，那么白名单可能是一个有用的工具 - 要克服白名单，您必须位于源和目标之间的网络上的某个位置，或者您必须妥协（可能只有部分）源和目标之间的网络的某些部分（这可能是但不限于中间人攻击）。
加密（取决于特定协议）解决了一个不同的问题，通常是流量嗅探。与此相结合，它可以用作身份验证（通过对称加密的共享密钥、TLS 使用的公钥加密 {可能由证书支持}），但不一定是这种情况 - 如果我通过 TLS 连接到我的银行， TLS 协议为我提供了一种对它们进行身份验证的方法（通过他们的证书），但它们无法以相同的方式对我进行身份验证 - 身份验证是通过 webforms 或其他方法完成的。客户端证书也是可能的，可以发给我，这意味着我们都通过 TLS 相互验证，我根本不需要登录。或者，如果网络服务器使用自签名证书，则可能根本没有身份验证。
我个人永远不会相信白名单本身，并且当与 TLS 结合使用时，它的用途非常有限 - 每一方（希望！）已经对另一方进行了身份验证，并且经过验证的真实用户的位置是使用非常有限。弱密码可以从 IP 地址白名单中受益，但实际上您应该解决问题，即弱密码。
白名单在技术上将您可能面临的威胁缩小到实际专门针对您的威胁。通过通过白名单拒绝大量更一般的威胁，您可以让您的加密充分发挥作用，以对抗可以通过白名单的小得多的威胁。