也许我过于偏执，但在阅读了有关网络安全的最新消息后，我开始相信SSL 已不足以用于敏感数据的传输。
参考：
我是一名 Web 开发人员，正在研究构建一些新的 API，主要用于私人用途（公司机器相互通信）。某些系统可能位于公司网络之外。我的问题是围绕与 API 本身有关的额外安全性。
有没有人想过或已经实现了 PGP 或 AES 之类的东西来真正加密所有在 API 通信中来回传输的数据？
我说的是仍然使用 SSL作为外部的总括包装器，但通过加密整个有效负载更进一步。显然，这在两端的加密/解密中产生了一些巨大的开销。问题是，我在概念上对此表示同意。硬件便宜。
我不是特别喜欢只是以明文形式发送我的数据并将我所有的鸡蛋都放在 SSL 篮子中。
想法？
是的，在某些情况下，加密层是有意义的。 这是一个具体的例子：
SSL 可以在中间点被合法解密；它并不总是端到端的：
有人会跳到这里说“你不应该那样使用 SSL！” 同意。出于合理的原因，它恰好在现实世界中发生了相当长的一段时间。
我的公司有一个 API 可以满足您的描述。XML-over-HTTPS 事务具有使用公钥加密加密的特定敏感字段。SSL 可以由临时主机出于我上面列出的原因而解密，而不会暴露敏感信息。这是解决实际问题的聪明方法。
几年前，我和一位同事在 AppSec USA 就这个主题做了一次演讲。（我承认一开始有点干，但中途变得更有趣:)
http://www.youtube.com/watch?v=4s0rZgcATrg
答案取决于您的威胁模型是什么。
如果您的威胁模型包含恶意最终用户，那么不，SSL 是不够的。最终用户可以轻松地 MITM 他/她自己的机器并查看或修改 API 流量。在我们的演讲中，我们展示了一个假设场景
如果您的威胁模型包括执行中间人攻击的国家/地区，那么带有第 3 方 CA 的 SSL 也不是很安全。（这就是 Rook 在上面所指的。）证书固定是一种可能的解决方法——我们在演讲中讨论了这一点——但有一些缺点，例如证书过期时更难滚动。
我们的演讲涉及一些可能的缓解措施，但信任不受您控制的设备的潜在问题通常不会得到解决。
加密数据，然后使用 SSL/TLS 流传输此密文提供零安全优势，只是浪费资源。SSL/TLS 提供的不仅仅是机密性，使用 SSL/TLS 传输密文是多余的。已被证明可以防止 MITM 攻击（BGP 或 DNS）和其他形式的政府胁迫的是证书固定。阅读： 您的应用程序不应遭受 SSL 的问题。我期待使用 HTTP-Strict-Transport Security (HSTS) 进行证书固定，因为这将提供有用的工具来改进 HTTPS。
SSL/TLS 非常高效且设计稳固，但另一方面，我们的 PKI 永远被破坏，不应该被所有人信任。如果损坏的 PKI 影响您的威胁模型，请使用证书固定。如果您不想使用特定算法，请定义您自己的允许密码套件列表。