SSL 通过加密来保护传输中的数据。对于客户端而言，它仅确保数据不会被截获或更改从他们的计算机传输到您的服务器（加密的数据可以被截获但没有解密就没有意义）。也就是说，客户端有责任在从服务器发送任何数据或信任输出之前确保 SSL 正常运行。有些攻击会从连接中删除 SSL，但不会拦截或更改通过安全 SSL 连接发送的数据。

一旦数据在服务器上，SSL 就不会提供任何安全性。如果您想保护静态数据免受服务器本身的破坏，仍然需要使用散列和服务器端加密。

HTTPS 是通过 SSL 加密连接发送的 HTTP。它涵盖了 GET 和 POST 以及任何其他 HTTP 操作，因为整个 HTTP 流原样发生，但通过 SSL 隧道传递到客户端浏览器。

HTTPS操作原理

HTTP 协议建立在 TCP 之上。TCP保证数据将被传递，或者无法传递（目标不可达等）。您打开一个 TCP 连接并通过它发送 HTTP 消息。

但是 TCP 不保证任何级别的安全性。因此，在 TCP 和 HTTP 之间放置了一个名为 SSL 的中间层，您就得到了所谓的 HTTPS。这种工作方式称为隧道——您将数据转储到 (SSL) 隧道的一端并在另一端收集。SSL 获取 HTTP 消息，对其进行加密，通过 TCP 发送它们并在另一端再次解密它们。加密保护您免受窃听和透明 MITM 攻击（更改消息）。

但 SSL 不仅提供加密，还提供身份验证。服务器必须具有由知名证书颁发机构 (CA) 签署的证书，以证明其身份。没有身份验证，加密是无用的，因为 MITM 攻击仍然可能。攻击者可能会诱使您认为他是您要连​​接的服务器。与魔鬼私聊不是你想要的，你想要验证你正在连接的服务器确实是你想要连接的服务器。身份验证可保护您免受 MITM 的侵害。

弱点

那么弱点在哪里呢？

• 安全连接的端点。传输可能是安全的，但服务器本身呢？还是客户端？他们可能不会。
• 不使用 HTTPS。可以通过各种方式诱骗用户不使用该方案。
• 不可信的 CA。他们破坏了身份验证部分，允许 MITM 攻击。
• 弱加密机制。加密技术以两种方式老化：可能会在其设计中发现严重缺陷，导致攻击比蛮力更有效，或者由于摩尔定律而增加的参数和处理能力可能允许进行可行的蛮力攻击。
• 方案的实施。好吧，如果您指定 A 并实现 B，则 A 的属性可能不适用于 B。

直接回答

• 您似乎说您保护了传输（使用 SSL）。这还不够，您的服务器的安全性可能会受到损害——您不应该将密码以纯文本形式存储在那里，使用它们的散列形式，添加盐，......

• SSL 在发送和接收数据时都对数据进行加密。实际上，只有当攻击者拥有由客户端信任的权威机构签署的证书时，MITM 攻击才可能发生。除非客户端被欺骗不使用 HTTPS，否则没有人可以读取或修改正在发送的消息。

• GET 和 POST 只是发出 HTTP 请求的两种方法。还有其他几个。方法只是 HTTP 请求的一个属性。无论使用何种 HTTP 方法，所有消息（请求和响应）都是安全的。

SSL 仅保护客户端和服务器之间的连接。从理论上讲，它做得很好（好吧，有一些问题 - 但与所有其他问题相比，这些问题都很小：）只要您在浏览器中信任的大约 150 个 CA 没有受到损害或与某些机构合作，并且给他们中间 CA 来进行中间人攻击。

而且，就像我说的，它只保护客户端和服务器之间的连接。因此，即使连接已加密，您的 Web 应用程序中的任何问题（如跨站点脚本、跨站点请求伪造、SQL 注入、不安全的 Session-ID 等）大部分仍然有效。此外，服务器可能会受到损害等。

总之，SSL 是保护数据所必需的，但它并不是保证数据安全所需做的唯一事情。

你试图从谁那里保护通信？如果是 NSA 或任何其他州级安全机构，答案是否定的：他们拥有成功实施针对 SSL 的中间人攻击的资源和技术。如果是大规模犯罪网络，答案仍然是否定的：它们不能像 NSA 等人那样危及证书颁发机构。可以，但他们可以很容易地破坏机器本身，并在加密之前查看传出数据和传入数据。但是，如果您只是托管服务器，那么您就不必担心，因为妥协很可能会发生在最终用户的机器上，然后是他们的问题。如果它是试图窃取和利用数据的随机数据包嗅探器，那么是的——尽管如此，它'