未加密的SSL协议？

本文介绍了未加密的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?

推荐答案

是的， TLS和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.

默认情况下，服务器可能启用其中一个密码套件。更有可能的是，默认情况下，服务器将启用弱密码套件（如导出级基于DES的套件）。这就是为什么您应该仔细检查服务器的密码套件白名单，并只留下一些值得信赖，广泛支持的算法。

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.

您可以使用TLS_RSA_WITH_NULL_SHA加密套件来保护流量的真实性和完整性，而无需加密。

You can use the TLS_RSA_WITH_NULL_SHA cipher suite, among others, to protect the authenticity and integrity of traffic, without encryption.

在这种情况下，RSA是指密钥交换算法，而SHA是指用于保护业务不被改变的消息认证算法。 NULL是加密算法，或者在这种情况下，缺少加密。

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.

重要的是意识到流量，虽然它没有加密，在SSL记录中。客户端和服务器必须启用SSL。

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.

如果您正在寻找一个降级解决方案，其中一些数据通过SSL交换，则SSL将关闭，但是应用程序流量继续，这是可能的，但请记住，它提供绝对没有安全的明文流量;它可以被攻击者篡改。因此，例如，使用SSL进行身份验证，然后降级到清除协议以接收使用通过SSL协商的身份验证的命令将不安全。

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.