MQIPT 中的 SSL/TLS 握手

在执行 CipherSuites 的认证和协商时， SSL/TLS 客户机与服务器之间的初始连接请求期间发生 SSL/TLS 握手过程。

所有受支持的SSL/TLS CipherSuites （见 MQIPT支持SSL/TLS ），除了匿名 CipherSuites, ，都需要服务器验证并允许客户端验证；服务器可以被配置为请求客户端验证。您应该避免使用匿名 CipherSuite，因为它们不保证远程同级的身份。中间人攻击可能在您不知情的情况下拦截匿名 SSL/TLS 连接。只在值得信任的内部网络上并且您准备好接受数据拦截风险时，使用匿名 CipherSuite。

SSL/TLS 中的通信对等认证基于公用密钥密码术和 X.509v3 数字证书。应该在 SSL/TLS 协议中进行认证的站点需要专用密钥和数字证书 (其中包含相应的公用密钥以及有关站点身份的信息) ，证书的有效期。证书由证书颁发机构签署，此类机构的证书称为签署者证书。证书后面跟着一个或多个签署者证书，则构成证书链。证书链的特点是，从第一个证书（站点证书）开始，可以使用下一个签署者证书中包含的公用密钥，验证链中每一个证书的签署。

正在建立需要服务器认证的安全连接时，服务器将向客户机发送证书链以证明其身份。仅当 SSL/TLS 客户机可以对服务器进行认证 (例如，验证服务器站点证书的签名) 时，它才会继续建立与服务器的连接。为了验证签名， SSL/TLS 客户机需要信任服务器站点本身或服务器提供的证书链中的至少一个签署者。必须在客户机端维护信任站点和签署者的证书以执行此验证。

SSL/TLS 客户机从站点证书开始检查服务器的证书链。在以下情况下，客户机认为站点证书的签名有效：

站点证书在信任站点或签署者证书的存储库中
可以根据信任签署者证书的存储库验证链中的签署者证书

在后一种情况下， SSL/TLS 客户机会检查证书链是否确实正确签名，从可信签署者证书到服务器的站点证书。还会检查此过程中每个证书的格式是否正确以及日期的有效性。如果其中任何一项检查没有通过，那么服务器连接将被拒绝。验证服务器证书后，客户机将在 SSL/TLS 协议的后续步骤中使用该证书中嵌入的公用密钥。仅当服务器确实具有相应的专用密钥时，才能建立 SSL/TLS 连接。

客户机认证遵循相同的过程: 如果 SSL/TLS 服务器需要客户机认证，那么客户机会向服务器发送证书链以证明其身份。服务器根据信任站点和签署者证书的存储库验证链。验证客户机的证书后，服务器将在 SSL/TLS 协议的后续步骤中使用该证书中嵌入的公用密钥。仅当客户机确实具有相应的专用密钥时，才能建立 SSL/TLS 连接。

TLS 协议的最新版本提供高安全性通信 (SSL 和较旧的 TLS 协议被视为不安全)。然而，协议根据应用程序提供的信息操作。只有当该信息库也得到安全维护，才能实现安全通信的总体目标。例如，如果您的信任站点和签署者证书的存储库陷入危险，您可能与非常不安全的通信合作伙伴建立了安全连接。