背景
- 服务端(3.205)是开启 SASL_SSL 协议的9094端口的Kafka 服务器
- 客户端(77.20)连接 9094 端口的生产者。
- 此为单向 SSL 认证
在客户端使用 Wireshark 抓包，抓包的结果如下图所示：
1、2、3 条数据包是客户端和服务端之间建立 TCP 三次握手，
从序号为4的数据包开始进入TLS握手阶段，直到序号为17的数据包开始传输应用数据，说明TLS握手已经完成。
分析数据包
下面展开几个关键数据包（报文），进行详细分析。
Client Hello
方向： 客户端 -> 服务器发送Client Hello报文
TLS 记录层
TLS 首部
- 内容类型Content Type: Handshake(22) 握手
- 版本： TLS1.2
- 长度： 167
内容：握手协议
- 握手类型： Client Hello（1）
- Cipher Suites: 客户端所支持的各种算法(29种)
- Compress Methods: 由于是握手协议，提供的压缩算法为空 null
- Random: 一个随机数（32字节），这个随机数由一个时间戳（4字节）加上部分随机序列号（28字节）组成，随后将应用于各种密钥的推导，并可以防止重播攻击。
最后要交付到传输层，目的端口号为9094.
序号为5的数据包为对方发过来ACK确认报文，序号为6的数据包为对方重复发送的ACK确认报文。后续此类数据包不再说明。
Multiple Handshake Messages
将多个握手报文集成封装到一个 TLS 记录层中发送
方向: 服务端 -> 客户端
Server Hello
内容：握手协议
- 握手类型： Server Hello（2）
- Cipher Suites: 服务器从客户端提供的密码组选择的密码算法 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- Compress Methods: 选择的压缩算法为空 null
- Random: 一个随机数（32字节），这个随机数由一个时间戳（4字节）加上部分随机序列号（28字节）组成，这个随机数的功能与客户端发送的随机数功能相同。
- Session ID: 会话编号
Certificate
Certificate中包含了服务器的证书，以便客户端认证服务器的身份，并从中获取其公钥。展开其中的“certificates”节点，可以查看有关服务器证书的详细信息，如下图所示：
Server Key Exchange 和 Server Hello Done
Server Key Exchange包含服务器的证书签名， Server Hello Done 表示本阶段的报文发送结束，具体信息如下图所示：
Client Key Exchange
方向： 客户端 -> 服务端
Client Key Exchange中包含了客户端生成的预主密钥，并使用服务器的公钥进行加密处理，此过程并没有通过网络进行传输，没有在数据包中体现出来。
如果是双向验证，不仅是传输 Client Key Exchange，还有 Certificate （客户端证书，如果没有证书将发送 No Certificate 告警）以及 Certificate Verify 用于验证客户端证书，签名。
拓展: Encrypted Alert
如果服务端解密客户端发来的数据，解密失败时会发送解密失败的告警,如下图所示：
Change Cipher Spec 和 Encrypted Handshake Message
方向： 双向奔赴
Change Cipher Spec
客户端通告启用协商好的各项参数，其内容类型（Content Type）值为20。
服务端 同样发送 Change Cipher Spec，将挂起的密码规约改为当前密码规约
Encrypted Handshake Message（加密握手报文）就是Finished报文
客户端用新的算法、密钥和密文加密发送一个报文，检查密钥交换和认证过程是否已经成功。
服务端同样发送Encrypted Handshake Message（Finished）报文回复客户端
至此，握手过程完成，
Application Data
握手完成后，客户端和服务器可以开始交换应用数据（Application Data）这是客户端向服务器发送的应用数据。整个报文封装在TLS记录层中，其内容类型（Content Type）值为23，版本为TLS 1.2，主体部分是已经加密的应用数据，这些加密数据都是双方使用协商好的参数进行安全处理，如下图所示：
总结
握手大概可以分为四个阶段:
- 第一个阶段是客户端发给服务端请求连接 Client Hello
- 第二个阶段就是服务端回复客户端对应的证书、公钥信息、加密压缩算法
- 第三个阶段是客户端告诉服务端自己的证书和公钥信息
- 第四个阶段确认好对应的对称密钥后，让其生效测试下好不好使。
握手的目的是协商对称加密密钥，由于加密前数据包都是明文，所以如果一开始就亮出密钥就不安全，所以握手期间是通过非对称加密的方式进行协商密钥。
单向认证握手流程 如下图所示：
双向认证握手流程 如下图所示：
单向认证比双向认证少了 服务端对客户端进行认证的阶段。
