【创作赢红包】网络安全——传输层安全协议（2）

• **作者简介：一名云计算网络运维人员、每天分享网络与运维的技术与干货。 **
• ** 座右铭：低头赶路，敬事如仪**
• 个人主页：网络豆的主页​​​​​​

前言

通过之前文章我们对于SSL协议进行了一定了解网络安全——传输层安全协议

本章将会继续讲解SSL握手协议与SSL记录协议。

一. SSL握手协议

1.SSL握手协议概述

SSL握手协议工作在SSL记录协议层之上，用于协商产生会话状态的加密参数。当SSL客户端和服务器首次开始通信时，它们就协议版本、加密算法的选择、是否互相认证进行协商，并使用公钥加密技术产生共享秘密。所有这些工作都是由握手协议完成的，大致可以分为以下两个阶段。

（1)第一阶段——“密钥等信息交换阶段”

通信双方通过相互发送Hello消息进行初始化。

• 通过Hello消息，双方就能够确定是否需要为本次会话产生一个新密钥。
• 如果本次会话是一个新会话，则需要产生新的密钥，双方需要进入密钥交换过程。
• 如果本次会话建立在一个已有的连接上，则不需要产生新的密钥，双方立即进入握手协议的第二阶段。

（2)第二阶段——“用户身份认证阶段”

• 对用户身份进行认证，通常服务器方要求客户方提供经过签名的客户证书进行认证，并将认证结果返回给客户。

2.SSL握手协议的具体工作过程

（1）客户端首先发出客户问候消息（ClientHelloMessage)，服务器收到后，或者发出服务器问候消息，或者发出终止错误，并中断连接，客户端和服务器的问候消息将协商产生下列属性：协议版本、会话标识符、加密算法及压缩方法.此外还将产生和交换两个随机数。

（2）客户问候消息发送完后，如果Server端需要进行认证，会发送它的证书。另外，如果需要的话(例如，如果它们的服务器没有证书，或者其证书仅用来进行签名)，将发出一个Server Key Exchange消息。如果Server端已经被认证，而且所选的加密算法支持的话，可以向客户端请求证书。在验证以后，服务器就发送服务器问候结束消息，以示达成了握手协议。

（3）如果服务器发出一个CertificateRequest消息客户端必须发出证书消息或者一个NoCertificate报警。此时，客户端密钥交换消息准备发送，消息的内容将依赖于客户端问候消息和服务器问候消息所协商选择的公钥算法。如果客户端已经发出了一个具备签名能力的证书，一个数字签名后的证书验证消息将被发送，以确认此证书的合法性。

（4）此时，客户端可以发送密钥更改消息，客户端将尚未协商确定的加密算法复制加入到当前加密算法。然后，客户端立即用新的算法、密钥和密钥素材发出结束消息。服务器将发出自己的改变加密规范消息作为回应，同时将尚未协商确定加密规范复制加人到当前加密规范，并用新的加密规范发出结束消息。

（5）此时，握手过程结束，客户端和服务器可以开始交换应用加密数据，应用数据加密一般是用第（2）步密钥协商时确定的对称加/解密密钥，如DES、3DES等。目前，商用加密强度为128位，非对称密钥一般为RAS，商用强度为1024位，用于证书的验证。完整的SSL握手协议消息交换过程如图4-5所示。

图中，带*号的步骤是可选的，或依据状态而发的消息，而密钥更改(Change CipherSpec)用于客户端与服务器协商新的加密数据包时而改变原先的加密算法。

如果双方是在已有连接上重建一个会话，则不需要协商密钥以及有关会话参数，可以简化握手协商过程，内容如下。

（1）客户方使用一个已有的会话标识符（Session ID）发出Client Hello消息。

（2）服务方在会话队列中查找相匹配的会话标示识符(SessionID)，如果有相匹配的会话，服务器方在该会话状态下重新建立连接，并使用相同的会话标示识符(SessionID)，向客户方发出一个ServerHello消息。如果没有相匹配的会话，则服务方产生一个新的会话标识符(SessionID)，并且客户方和服务方之间必须进行一次完整的握手协商过程。

（3）在会话标识符(SessionID)匹配的情况下，客户方和服务方必须分别发送Change Cipher Spec消息,然后发送Finished 消息。

（4)此时，重建一个会话结束。客户方和服务方进入数据交换阶段。简化的SSL握手协议消息交换过程如图4-6所示。

3.SSL握手消息格式

SSL.握手协议由一系列握手消息的交互组成。SSl.握手协议定义了若干握手消息，用于在通信双方之间建立会话和协商安全属性。握手消息将提交给SSL.记录层，由记录层封装一个或多个SSL_Plaintext结构。

二.SSL 记录协议

1. SSL记录协议概述

SSL是层次化协议。在每一层，消息均可以包含描述长度、消息及消息内容的域。SSL在传输消息时，首先将消息分为可处理的数据块，可以进行压缩，将其封装为一带消息验证（MAC)的包，随后进行加密，并进行传输。收到消息时，首先解密，然后验证、解压缩并重新组合得到原有的消息，将此消息发向高层协议。SSL.记录层从更高层接收未加解释的任意长度的非空块数据块。

2.打包过程

记录层将数据块分裂为小于或等于214字节的SSL.PlainText记录。客户端消息的分界限并不反映至记录层中，也就是说，具有同样内容类型(ContentType)的多个客户端消息可能会合并为一个SSLPlaintext记录。

3.记录的压缩和解压缩

• 所有的记录均应用在当前的对话状态中定义的压缩算法进行压缩。
• 压缩算法初始化定义为CompressionMethod.null，随后通过用户握手协议协商更改。压缩算法将SSL.Plaintext结构转换为SSL.Compressed结构，当CipherSpee变换后，压缩函数将删除其状态信息。
• 压缩必须是无损压缩，且对原文长度的增加不超过1024比特。如果解压缩函数遇到一待解的超过214比特的SSL.Compressed.fragment,它将产生decompression_failure报警。

** 创作不易，求关注，点赞，收藏，谢谢~ **