HTTPS 是 SSL 内的 HTTP。SSL是一种隧道协议：它在现有的双向数据流上工作，并为数据提供双向流。SSL 涉及的两方是客户端和服务器，它们是 SSL 协议中的两个角色；这些角色不需要映射到底层传输协议的“客户端”和“服务器”的概念。

例如，可以想象一个设置，其中客户端系统 (C) 发起与服务器 (S) 的 TCP 连接，然后服务器发起 SSL 握手，充当SSL 客户端（即发送ClientHello消息，而不是等待传入ClientHello）。这颠倒了两台机器的角色以及安全保证：机器 S 将很好地了解连接的客户端 C 的身份，但客户端 C 不确定它正在与哪个服务器 S 通信（攻击者可能已经拦截并重定向了通信）。根据上下文，这可能合适也可能不合适。

但是，这与HTTPS不同，其中 TCP 客户端也是 SSL 客户端，并且该客户端希望服务器显示一个证书，客户端将根据其已知的、受信任的 CA 验证该证书，并且该证书包含预期的服务器名称（如从 URL 中提取，参见第 3.1 节）。相应地，现有客户端（Web 浏览器）不支持 SSL 角色反转。如果您的情况需要使用浏览器，那么您当然必须只使用浏览器中可用的功能。

SSL 确实支持一些无证书密码套件。“DH_anon”密码套件被认为很弱，因为它们根本没有身份验证（因此，中间人攻击是可能的）。PSK密码套件意味着客户端和服务器在共享密钥方面的相互身份验证。当共享密钥具有低熵（例如，它是一个密码）时，SRP密码套件会更好。

再说一次，这些密码套件（还）在主流浏览器中不可用（尽管有些人正在研究它）。他们需要一个共享的秘密（密钥或密码），在您的特定环境中可能会或可能不会容易实现的条件。

如果服务器身份的知识并不重要，那么您可以为服务器提供一个自签名证书，并为客户端提供有关如何让他们的浏览器接受服务器证书而不会太大声的说明（请参阅此问题作为起点）。这将映射到“普通 SSL”，它有两个好处：

• 现有的浏览器支持这一点。
• 当服务器提供证书时，无论多么虚假，它都可以请求客户端证书作为回报，从而产生您正在寻找的身份验证类型。Web 浏览器确实支持 SSL 的客户端证书。

请注意，自签名证书包含服务器公钥。尽管不会验证此公钥，但它仍将用于为密钥交换提供动力，因此您必须使用适当的密钥类型和长度（例如 RSA 2048）。或者，使用“DHE”密码套件之一，在这种情况下，服务器公钥仅用于签名，而不是实际保护数据，因此（在您的特定情况下），它的大小和保密性变得不重要。

不可以。根据HTTPS 的规范，需要证书，因为这是服务器向客户端标识自己的方式。证书不需要有效，即证书不必由浏览器默认信任的 CA 颁发和签名。

HTTPS（HTTP over TLS）建立在我们需要确保我们实际上连接到我们尝试连接的同一个 Web 服务器的想法之上。事实上，您会看到许多 Web 服务器软件甚至不支持双向 HTTPS 身份验证。

当然，也有例外（匿名密码套件、预共享密钥等），但它们都有自己的问题。例如， Mozilla在其产品中不支持匿名密码套件。Chrome 最近也走了同样的路。预共享密钥具有常规部署问题，这确实需要公钥加密的便利。

底线是：您需要 HTTPS 的服务器证书。

不可以。在您开始 TLS 交换的那一刻，您需要提供自己的公钥。

此外，这永远不会奏效。几乎没有任何 MITM 攻击只是“被动”的，只要他/她能够嗅探数据，攻击者就可以修改数据。

并且攻击者可以简单地通过在 TLS 启动之前拦截连接来伪装成客户端（在普通 HTTPS 中，这不起作用，因为无法建立伪造的网络服务器证书的信任），并将他自己的证书作为客户端证书.

此外，RSA 需要两个密钥。您需要使用您的私钥和客户端的公钥加密文本。公钥与证书齐头并进，因此您将需要一个。

你必须有一个证书，但它可以是你自己制作的。

SSL（这是 HTTPS 提供的）需要用于安全通信的证书，因为这是加密的基础，也是用于验证服务器是他们声称的身份的基础。

如果您自己制作证书，您的用户将没有任何理由信任该证书，除非他们已经知道它是准确的（因为它没有对您的身份进行任何独立验证），但它会很好地提供加密并且将向第二次连接的人确认他们正在连接到与以前相同的服务器。