#1 楼
这并不少见，但可能不是必需的。许多开发人员似乎忘记了HTTPS流量已经被加密-仅查看有关在此网站上实施客户端加密的问题数量-或由于联想SSL等众所周知的问题而感到无法信任MitM混乱。但是，大多数人并没有受到此影响，并且目前没有针对TLSv1.2的特别可行的攻击，因此它并没有增加太多。 br />
另一方面，在某些情况下，有合理的理由在传输之前对数据进行加密。例如，如果您正在开发存储应用程序，则可能需要使用客户端上只有用户才知道的密钥的应用程序进行加密-这意味着服务器将完全无法解密数据，但它仍然可以存储它。通过HTTPS发送将意味着攻击者也将无法获取客户端加密的数据，但是即使它们能够捕获，也没有关系。这种模式通常由基于云的密码管理器使用。
本质上，它取决于您要防御的内容-如果您不信任SSL / TLS，则可能无法信任您正在发送的加密代码（在Web应用程序的情况下）！
评论
想到这一点，就有理由不抛弃所有涉及JavaScript客户端Web浏览器加密的stackoverflow问题。它们使超级鱼和朋友变得毫无用处，并且打包的公司拦截器容易被击败（问题转化为军备竞赛）。
–约书亚
16-3-15在18:06
如果HTTPS层受到MITM攻击的威胁，则肯定会使得客户端JavaScript加密...安全性降低。
– wizzwizz4
16-3-15在22:22
如果您在一家大公司工作，您的IT部门可能有意对您的SSL连接进行MITM-多家公司出售“ SSL检查”代理-这通常涉及在公司设备上安装“受损的”根证书。但是，这些“检查”工具将无法采取任何措施来破坏自定义的按应用程序加密。
–坦率的农夫
16 Mar 17 '16 at 22:34
如果您在一家大公司工作，并且绕过过滤器或流量检查，则IT部门可能会紧随其后。
–Traubenfuchs
16年3月21日在9:54
基于@FrankFarmer，现在还具有恶意浏览器插件的功能，可以通过在本机浏览器版本的顶部替换自己的浏览器中的XMLHttpRequest或Fetch Prototypes来执行MITM，并捕获所有输入，然后发送给浏览器HTTPS处理程序或HTTPS处理程序解密数据后。
–马丁·巴克（Martin Barker）
20-04-22在18:26
#2 楼
HTTPS仅在消息通过网络/ Internet传输时提供加密。如果消息是在客户端和服务器之间的某个点上由中介（例如消息队列）存储或处理的，则最终处理它，然后它在中间层时就不会保持加密。
此外，如果TLS / SSL在服务边界终止（例如，在负载平衡器上），则可能未加密在内部网络上。这可能是一个需要高安全性的问题，例如在某些受监管的环境中。
在这两种情况下，消息级加密都将确保在客户端与客户端之间的所有点处对数据进行加密。最终接收者。
@honze所说，这称为纵深防御，它旨在确保即使系统受到部分破坏（例如，他们设法做一个人为干预）中间攻击以破坏SSL / TLS，或利用消息队列中的漏洞获取静态数据）攻击者无法获取受保护的数据。
评论
对于您为什么要加密SSL发送的内容，这似乎是一个更清晰的答案。
– Steve Sether
16 Mar 15 '16在19:37
需要注意的是：这还允许客户端控制允许谁解密最终程序包。例如，使用发送到云的备份。您无需与云提供者共享解密密钥，这意味着即使云提供者被“黑客入侵”或法律强制泄露其数据，客户端仍是唯一拥有密钥的人。
–NotMe
16 Mar 17 '16 at 16:49
#3 楼
我想分享我在标题问题上的经验。它与完整的问题本身并没有真正的关系，但这回答了“为什么有人会双重加密？”的问题。过去，我曾在一个处理护理提供者（医生，医院等）和保险组织（共同体）。我们有点像路由器。
该模式大致如下：
care provider 1 \ / insuring organization 1
care provider 2 ---- router (us) ---- insuring organization 2
care provider 3 / \ insuring organization 3
我们具有以下保护：
端到端加密：护理提供者1需要将患者信息发送给保险公司1。此信息对隐私敏感，因此需要进行加密。在我们这一级别，我们无权知道要向保险公司发送哪些数据。
护理提供者-路由器加密：护理提供者将信息作为元数据发送给我们，以便我们能够处理它。此信息需要加密。合同规定，即使在我们的网络内部，仍然必须对消息进行加密，以使我们的服务器中只有一台知道所发送信息的元数据。由于我们有多个管道（负载平衡器，防火墙等），因此在此级别也需要加密。
HTTPS可以避免MITM攻击：不仅需要保护我们的数据，还需要保护数据。 HTTP元数据也需要受到保护，因此也需要HTTPS。
我希望这可以阐明为什么需要多层加密的原因。
#4 楼
你是对的。这是一个称为深度防御的多层安全概念。加密的消息很可能解决端到端加密，而SSL / TLS则解决元数据的加密。这是一个有用的模式。
评论
它的确回答了这个问题，但对于我在答案中寻找的内容来说却有点薄...仍然是+1。
–轻盈
16 Mar 15 '16 at 9:21
#5 楼
HTTPS在传输过程中被加密，并在末尾解密。因此，您可能希望进行双重加密的明显情况是，您不希望一端（或可能两者都有）看到明文。我的头上：通过网络邮件提供商加密的电子邮件。如果我通过通过HTTPS连接访问的Gmail发送GPG加密邮件，则该邮件将被加密两次。因为我不想gmail读取内容。
加密的备份服务。我想使用HTTPS阻止我的登录凭据被盗，但我不希望备份服务看到备份的“内部”。
支付网关。您可以想象一个在其中通过用户的不安全设备和商人站点在安全支付硬件令牌和银行之间发送加密消息的情况。中间的链接应该是HTTPS，但这还不够：需要在不安全的PC和不太安全的商人网站上对其进行加密。
请注意，S / MIME提供了“三重包装”（签名/加密/签名）：https://tools.ietf.org/html/rfc2634，因此，如果您既考虑签名又考虑加密，那么可能还有更多可能性。
#6 楼
我想给出一个附加的理由：标准化。我有一个应用程序，出于安全原因，所有流入和流出其中的数据都必须加密。因为已经被加密一次，所以数据可以通过http（旧版）和https（当前）连接传输。加密两次比创建一个版本的应用程序要有意义得多，该版本的应用程序可以不通过https运行，而可以通过http运行。
评论
可以为不支持http协议而争论不休，但是，对于我们的环境，维护ssl证书和当前的ssl软件非常棘手，并且可靠性低于http。
– DKATyler
16 Mar 16 '16 at 5:39
我理解您的意思，但是如果有人提出将安全性放在重要方面的应用程序，则会强制使用HTTPS并禁用HTTP，或者在使用Web应用程序的情况下，HTTP pub将为空，仅支持HTTPS。
–轻盈
16 Mar 16 '16 at 8:23
@Lighty相信我，现实世界不会按照这样的明智原则运作。现实导致情况更加严峻。
–克里斯·海斯（Chris Hayes）
16 Mar 17 '16 at 0:42
#7 楼
在处理高度敏感的信息（例如财务，医疗，军事或心理数据）时，这是最佳做法。多重加密的基本思想是防止任何未经授权的用户检索数据。假设加密方法的初始可能组合为10亿个。通过在其之上应用另一种加密方法，我们可以将可能性增加到1b ^3。这将需要未经授权的用户花费更长的时间来解密数据。虽然加密仍不完美，但效果更好。在我工作过的一家组织中，我们使用了多种加密。这是先前流程的简化：
对客户端和服务器设备以及组件进行审核，以检查是否通过软件
加密存储中的数据/>使用专有软件加密数据
开始与服务器连接
审核客户端和服务器设备以及组件以通过连接清除
压缩传输
通过加密连接发送数据；如果连接断开，请重新启动整个过程。
成功完成文件后，审核数据的一致性
如果您不处理网络中敏感数据密集的环境，则这是overkill。
此方法背后的策略可确保对设备，组件（MAC）和IP进行身份验证。加密数据是标准过程，因此通过HTTPS发送也是如此。一些组织超越了基本安全性，还需要利用Freenet，I2P，IPsec / VPN或Tor进行类似暗网的网络连接。不管加密如何，数据压缩都会减少所需的存储和网络资源；但是，这会将您的性能抵消到RAM或处理上。最后，我们在断开连接后重新启动连接的原因是，我们发现了一种通过中间人劫持数据流的方法。
最终，没有永远完美的数据加密方法，而是将精力集中在加密上，直到数据或信息变得无关紧要，或者您产生了一种高级的数据加密方法。
评论
或者，您可以只使用两倍大的密钥。
– PyRulez
16-3-17的1:15
#8 楼
通过加密连接发送加密数据的原因很多：传输的所有数据中），数据仍处于加密状态HTTPS服务器可能不受信任，并且负责将数据中继到另一台服务器
类似，HTTPS服务器可能会通过以下方式将数据中继到另一台服务器未加密的连接，并且让客户端在传输之前对数据进行加密可以减少HTTPS服务器上的负载，否则该HTTPS服务器必须对来自所有客户端的数据进行加密，而不是直接将其传递给
#9 楼
API混淆即使所有通信都通过HTTPS加密，客户端仍然可以选择使用各种调试工具在加密之前查看其流量。特别是如果您使用浏览器环境或基础系统提供的具有https的应用程序。
在这种情况下，您可以使用静态密钥加密数据，因此客户端无法轻松读取和操纵流量。当然，这只是混淆，因为密钥需要存储在客户端计算机上的某个位置（至少在RAM中），但是对于软件源代码，它始终只是混淆。用户将不得不花费相当大的精力来恢复您的密钥并解密您的访问量以读取对他的请求的操纵。
示例可能是基于网络的游戏，该游戏为玩家带来了高分。
评论
或弄清楚如何访问游戏的管理员/超级用户方法。
–脚掌
16 Mar 17 '16 at 12:10
保护API的更好方法是身份验证。如果必须先使用强大的身份验证系统（例如公钥）对用户进行身份验证，然后才能使用管理功能，则无需混淆API。同样，分数提交等功能可以使用临时的“签名”（YouTube使用类似的东西），该签名必须至少生成一次并随每个请求传递-尽管可以始终对其进行逆向工程，但会使它非常复杂（甚至可能基于请求的内容，因此每个请求的请求都不同）。
–米歇尔·约翰逊（Micheal Johnson）
16 Mar 17 '16 at 14:03
@MichealJohnson，这根本无济于事，如果您发送authId = 746788553 score = 200，则用户仅需要通过中间的人来更改分数值（在自己的设备上很容易），如果您混淆了，他将很难
– Falco
16 Mar 17 '16 at 18:14
您还发送了signature = 21a87c7b0a6005df838b17b9aafd0dc1，其中签名是由混淆算法（最好每几周更改一次）根据authId，得分和当前时间生成的。您不必通过第二层加密来混淆签名的传输，因为即使用户知道它是一个签名并且知道它的价值，但是如果用户更改了分数，则该签名将不再有效（因为分数用于计算），到他们对混淆进行逆向工程时，该算法有望被更改。
–米歇尔·约翰逊（Micheal Johnson）
16-3-18在14:44
@MichealJohnson这是一个很好的观点，并且将获得相同的好处。 -但是您之前的陈述不符合要求，必须至少生成一次并随每个请求传递，听起来更像每个会话的静态值，您的第二条评论要好得多
– Falco
16年3月18日在16:09
#10 楼
多级加密的主要原因是关注点分离。通常，一组服务器可能会处理一组数据，这些服务器可能会受到多个组织的控制，并非所有人都完全信任整个数据。在大多数情况下，这些中间服务器中的大多数只需要对数据的一部分进行操作，因此，如果它们不需要查看数据的某些部分，则可以对该部分进行加密。您将获得对他们需要的数据进行中间访问的权限，以查看他们拥有的密钥中已加密的数据以及可以传递给其他服务器进行进一步处理的已加密blob。具有GPG和TLS加密的电子邮件。邮件传输代理（电子邮件中继）的主要工作是将电子邮件从一跳传输到下一跳。他们需要查看邮件路由信息才能完成工作，但是他们不需要查看邮件本身。因此，您将使用邮件传输代理可以理解的一个密钥和仅收件人可以理解的另一个密钥对邮件连接进行双重加密。
另一个示例是日历/通知调度服务。您将事件放入日历中，以便日历应用程序通知在特定时间发生了某些事件。日历不需要知道事件是什么，事件中涉及的人，也不知道事件在哪里。
进行多次加密的第二个原因是作为保护，以防加密层之一被打破。 IMO，这是一个较弱的原因，因为您需要考虑每个不必要的附加层都会增加实现复杂性，而复杂性是安全性的大敌。
#11 楼
我在这里没有看到此内容，但我认为它比评论要重要得多。他们可能这样做是为了完善前向保密性。攻击者可能不知道您的HTTPS连接的密钥，但是他们可能会记录每个字节并将其存储多年。然后，他们可能会黑客入侵您，发现漏洞或稍后迫使您透露服务器的私钥，然后返回历史记录并解密您的消息。通过在HTTPS连接下使用临时的临时密钥对消息进行加密，攻击者仍将无法读取消息，或者至少会明显延迟。评论
但是，这并不是真正的双重加密。 （主要是）关于会话密钥是如何派生，同意或共享的。基本上，如果以某种方式派生会话密钥，使得拥有密钥交换期间来回传输的所有数据的纯文本的完整记录的人以后无法再创建会话密钥，则您拥有PFS；否则，您将拥有PFS。如果拥有此类记录的人可以重新创建会话密钥，那么您就不能。 PFS非常好，但它（潜在地）解决了一个非常不同的问题，如不受信任的中间端点的示例所示。
–用户
17-10-7在10:51
#12 楼
如果我理解正确，那么Tor网络就是这样工作的：爱丽丝给戴夫写了一封信，并对其加密了三遍：首先用戴夫的钥匙，然后加上戴夫的地址，用克雷格的钥匙加密包裹，再加上克雷格（Craig）的地址并用鲍勃（Bob）的密钥对包裹进行加密。
然后，她将信件发送给鲍勃（Bob），鲍勃将其解密，找到克雷格（Craig）的地址，然后将其转发给他。
克雷格（Craig）解密，找到戴夫的地址，并将其转发给他。戴夫解密后发现这封信是给他的。
在一个完美的世界中，除了爱丽丝和戴夫之外，没有人可以说戴夫确实是那封信的收件人，因为它可能是他有在信封内找到Emily的地址并将其转发。
第二个应用程序是您使用私钥和收件人的公钥对邮件进行加密。收件人使用您的公共密钥和他的私钥对消息解密，从而可以获取消息是来自您和他的信息。但是通常，使用HMAC来确保邮件确实来自某个发件人，并且未被篡改。
#13 楼
算法和实现中的缺陷可能现在都存在，但尚未发现。理想情况下，这些缺陷将不存在，但它们确实存在。如果您使用两种不同的算法进行加密，而其中只有一种存在缺陷，则您仍然可以，而且您的数据是安全的。如果第一层被破坏，则攻击者只能获取密文。如果第二层被破坏，则攻击者将无法通过第一层。
双重加密（或三重或四重或..）可以是避免将所有内容都放入的一种好方法。一个篮子里放鸡蛋。
评论
您假设双重加密不会以某种方式交互，这意味着组合比单独使用任何一种算法都更容易破解。你有证明吗？
–马丁·邦纳（Martin Bonner）支持莫妮卡（Monica）
16年3月18日在9:02
@MartinBonner不，我不
– Shelvacu
16年3月18日在9:25
对我来说，这似乎是一个合理的假设-但有可能开发出自己的加密算法（即使它来自受人尊敬的构件）。
–马丁·邦纳（Martin Bonner）支持莫妮卡（Monica）
16 Mar 18 '16 at 10:15
是的，事实证明，正确组合两个密码至少要与两者中的更好者一样强。如果通道是分开的（未组合），则可以使用中间条件通道来防止来自外部密码的“已知明文”数据包元数据。
–JDługosz
16-3-21在6:27
@JDługosz您对密码的定义是什么？ ROT13算在内吗？
– Shelvacu
16-3-21在6:52
#14 楼
为了避免PCI合规性问题，开发人员希望使用支付网关并将合规性放在第三方。表单发布中的字段可以在客户端进行加密，因此开发人员不需要没有任何未加密的卡详细信息通过它们的系统（因此要比不存储它们更进一步）。
值得注意的是，这是在HTTPS之上。因此，该网站甚至看不到未加密的数据，只有用户和支付网关。
Brain Tree支付网关的示例：https://www.braintreepayments.com/blog/client-侧面加密/
评论
为什么是-1？我添加了一个示例文档来备份我的案子。
– Alex KeySmith
16年3月18日在18:58
表单数据仍可以视为“消息”。
– Alex KeySmith
16年3月18日在19:00
我当然不建议仅使用客户端加密！这是在HTTPS之上！
– Alex KeySmith
16年3月18日在19:00
实际上，这是一个相当合理的应用示例。
– Xander
16年3月18日在19:08
谢谢@Xander，是的，我猜我的答案起初可能是人们误以为只是客户端加密（这显然是很糟糕的事情！）
– Alex KeySmith
16年3月18日在19:20
#15 楼
并非完全是HTTPS问题，但是Tor中经常使用另一种双重加密的有效用例，以防“我不相信交付人员，并希望通过使用更多步骤来保持匿名”。每个“送货员”仅解密信封以找出另一个送货员。这种情况下的通信在SOCKS代理中被封装和加密。
评论
原因之一是要利用高效的双重ROT13加密算法。您可能需要不同级别的加密-您希望对用户的文本消息进行加密，以便只有收件人才能阅读它，并且还希望对携带该文本消息的协议消息进行加密，以便只有您的服务器才能阅读它。
与TLS相比，某些旧版应用程序可能已经在与TLS不同的通道上使用了自己的加密。当开发人员将其转换为TLS时，他们可能不想通过删除旧的加密层来引入新的错误可能性。
@immibis如何两次应用ROT13并假装文本已加密？
@DmitryGrigoryev-正是出于您所问的原因，这是关于无效的安全性的一个老笑话-听起来不错，但完全没有用。