未加密的 SSL 协议？
是否可以通过未加密的 https 发送消息？例如，要求进行证书验证和授权，但不加密通过套接字发送的实际数据？
Is it possible to send a message over https that isn't encrypted? For example, require that certificate validation and authorization occur, but not encrypt the actual data being sent over the socket?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，TLS 和 SSL 支持“无加密”模式。所讨论的特定客户端和服务器是否配置为启用是一个单独的问题。
服务器有可能默认启用这些密码套件之一，尽管可能性不大。更有可能的是，服务器默认启用弱密码套件（如“导出”级基于 DES 的套件）。这就是为什么您应该仔细检查服务器的密码套件白名单，并只留下一些可信的、广泛支持的算法。
可以使用 TLS_RSA_WITH_NULL_SHA 密码套件等来保护流量的真实性和完整性，而无需加密。
在这种情况下，“RSA”指的是密钥交换算法，而“SHA”指的是用于保护流量不被更改的消息认证算法。 “NULL”是加密算法，或者在本例中是缺乏加密。
重要的是要认识到流量虽然没有加密，但却捆绑在 SSL 记录中。客户端和服务器必须启用 SSL。
如果您正在寻找一种降级解决方案，其中一些数据通过 SSL 进行交换，那么 SSL 将被关闭，但应用程序流量仍在继续，这也是可能的，但请记住，它绝对不会为明文流量提供任何安全性；它可以被攻击者篡改。因此，例如，使用 SSL 进行身份验证，然后降级到“明文”协议来接收使用通过 SSL 协商的身份验证的命令，这是不安全的。
Yes, TLS and SSL support "no-encryption" modes. Whether the particular client and server in question are configured to enable is a separate issue.
It's possible, though unlikely, that a server could enable one of these cipher suites by default. What is more likely is that a server would enable weak cipher suites (like the "export"-grade DES-based suites) by default. That's why you should carefully review the server's whitelist of cipher suites, and leave only a few trusted, widely-supported algorithms.
You can use the TLS_RSA_WITH_NULL_SHA cipher suite, among others, to protect the authenticity and integrity of traffic, without encryption.
The "RSA" in this case refers to the key exchange algorithm, while "SHA" refers to the message authentication algorithm used to protect the traffic from being altered. "NULL" is the encryption algorithm, or, in this case, the lack of encryption.
It's important to realize that the traffic, though it's not encrypted, is bundled up in SSL records. The client and server must be SSL-enabled.
If you are looking for a step-down solution where some data is exchanged over SSL, then SSL is turned off but the application traffic continues, that's possible too, but keep in mind that it offers absolutely no security for the cleartext traffic; it can be tampered with by an attacker. So, for example, authenticating with SSL, then stepping down to an "in-the-clear" protocol to receive commands that use the authentication negotiated via SSL would unsafe.
SSL/TLS 规范定义了一个“NULL 密码”，您可以使用它来实现此目的。大多数客户端和服务器软件出于明显的原因禁用它。
但是，如果您正在编写自己的软件，您也许可以说服您的图书馆进行协商。
The SSL/TLS specs define a "NULL cipher" which you could use for this. Most client and server software disable it for obvious reasons.
However, if you are writing your own software, you may be able to convince your library to negotiate it.
我想你可以。
但这是愚蠢的，您将失去身份验证的重点，并使自己暴露在可以拦截和更改您的数据包的攻击者面前。
I think you can.
but it would be stupid, you will loose the point of the authentication, and leave yourself exposed to attackers that can intercept and alter your packets.
不，协议不允许这样做。
您可以采取的一种解决方案是通过 https 连接，验证连接，然后使用会话 cookie 删除与 HTTP 的后续连接。如果没有该 cookie，请重定向回 https，以便客户端始终通过它进行连接。
不过，这可能与您无关，因此如果您提供有关您要解决的问题的更多信息，我们可能会提供更多帮助。
No, the protocol doesn't allow for that.
One solution you could do is connect over https, verify the connection, then drop subsequent connections to HTTP with a session cookie. Without that cookie, redirect back to https so that the client always connects over it.
This might not be relevant to you, though, so if you provide more information about the problem you're trying to solve we could be of more help.