目录

1. TLS协议概述

2. 为什么要握手

2.1 Hello

2.2 协商

2.3 同意 

3.总共握了几次手？

---

1. TLS协议概述

车内各ECU间基于CAN的安全通讯--SecOC，想必现目前多数通信工程师们都已经搞的差不多了（不要再问FvM了）；但是在车云通信时，保证数据的信息安全则常用TLS，搞懂它，加深加深运管端各自的网络安全机制理解。

TLS(Transport Layer Security)前身叫做SSL(Secure Sockets Layer)，位于TCP之上，但仍旧属于传输层，作用很明确，就是为了保证车云通信时数据的CIA。

目前，TLS协议版本已经来到了1.3，具体可以搜版本号RFC 8446，在标准中详细描述了握手协议，如下图：

RFC 5246 : TLS v1.2；RFC 4346 : TLS v1.1 ； RFC 2246 TLS v1.0

那么就从最基础的通信双方如何建立连接开始，入门TLS。

2. 为什么要握手

握手这个词很形象，就像相亲双方之前互不认识，但因为家里要求见面，那首先肯定是先握手，握手成功，双方来电，接下来对话才有戏；握手失败，闲聊两句，就各回各家。

握手期间的对话就很讲究了，对话如能找到共同话题，那相亲双方就可以围绕这个话题继续进行加密通信，这也就是TLS要先握手的本质：协商出一个密钥（共同话题），让双方基于这个密钥进行加密通信。 

这个协议中定义握手消息名字也很有意思，“Hello”，包括了Client Hello和Server Hello等。

我们以TLS1.2流程为例（因为抓包只抓到TLSV1.2），总结流程如下：

我用Wireshark抓了一个和https网页沟通的包，过程和上图很像有么有？

以这个为例来具体分析分析：

2.1 Hello

第一条消息，Client(我)向Server(知乎某专栏)发送Hello请求，得到数据包如下：

该消息体现了当前TLS版本协议、会话ID、随机数1（很重要记住它）、能够使用的密码套件、压缩算法还有很多扩展内容，特别是有个server_name，就像相亲两人见面第一句一定是，你就是xxx吧？

Client打了招呼，那Server应该要进行回复，不然就没得聊了，它话很多，打一声招呼Server Hello，紧接着陆陆续续发送了自己的证书、密钥交换参数，最终以Hello Done结尾，

Server Hello

格式如下：

Server首先会进行响应，并且从Client能够使用的密码套件中选择一种，在这里，它选择了0xc02f，满足第一条消息中提供的密码套件，这条消息确认了TLS版本1.2，选择了套件，并且承诺不会压缩后续对话，注意，这里Server还传递了一个随机数2。

密码套件名字很长：TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，但其实得拆开来看：

ECDHE指的是密钥交换算法 Elliptic Curve Diffie-Hellman Ephemeral，签名就使用RSA算法；

AES_128_GCM是指后续加密通信使用AES128-GCM，既定义了密钥长度，也定义了密码工作模式；SHA256就很简单了，做Hash都用它。

Server Certificate

还是以相亲为例，两人见面后的第二句话一定是：我是某某阿姨(中间人)介绍的xxx。

这句话很关键，因为相亲双方都是基于中间人的介绍，ta的介绍就像是一个证书，是相亲双方能够继续往下聊的一个前提。

但这个中间人只是双方认可的，如果需要再进一步确认信息，身份证就是最好的证明，这是最权威的机构颁发的证书。

因此，Server Certificate提供证书的目的也很明确，就是证明自己的合法身份，这条消息格式如下：

证书主要包含了如下信息：

证书里包含了一个非常关键的内容：Server的公钥，其他关于证书的问题我们后面单独再谈。

有兴趣的可以搜一搜中国电子银行网的《六问六答》。

Server Key Exchange

前面我们已经知道了，双方要写上一个密钥，使用算法为ECDHE，这个算法要求双方首先交换公钥，因此需要这条消息 Key Exchange，格式如下：

这里面包括了握手类型、算法所选曲线采用x25519、用于协商密钥的公钥，以及用上述证书中公钥对应的私钥进行的签名，算法为RSA-PSS-SHA256（这些算法填充格式之前已经聊过了）。

Server Hello Done

Hello Done的信息量很少，如下：

 就是Server告诉Client，自我介绍完毕，看你怎么回应。

事实上，通过Wireshark抓包，我们可以看到，Server回应的消息实际是在一个包内，如下图所示：

2.2 协商

在第一步里，Client收到了Server发来的证书、密钥交换的参数等等，就需要对一步一步来验证Server的身份和数据完整性，并向Server发送密钥协商的参数，同样一包中可以封装了不同的消息，如下图：

Client Key Exchange

首先Client使用CA的公钥对证书进行验签（过程暂不讲），通过后取出Server的公钥备用。

这时候Client就拥有了四个参数：自己的协商公钥、Server的协商公钥、随机数1、随机数2。

那么神奇的就来了，预协商密钥 = c_priv * s_pub = c_priv * (s_priv * G)；

G是椭圆曲线的基点G，是公开的，唯有私钥是各自保护，所以Client也要把协商公钥发给Server，

Server拿到后，计算预协商密钥 = s_priv * c_pub = s_priv * （c_priv * G）。

这不就妥了吗？两边预协商密钥都一样了，这个密钥一般叫预主密钥。 

还记得之前两个随机数吗，Client和Server会使用相同算法对这三个参数进行操作，得到最终会话密钥 = Algo(随机数1 + 随机数2 + 预主密钥)

Change Cipher Spec

这个消息就是告诉Server，咱们密钥都已经协商好了，那就用它开始进行对话吧，截图如下：

Encrypted Handshake Message

这个时候就使用了协商好的对称密钥对握手消息进行加密传输，如下：

之后就是加密后的应用数据了。 

2.3 同意 

当Client发送经过对称加密的消息后，Server当然也需要进行确认，因此会回复三个消息：

New Session Ticket

该消息主要是为了快速恢复会话，防止重复握手

Change Cipher Spec 

表示Server接收到了使用协商好的共享密钥，并且确认后续都使用该密钥进行加密通话。

Encrypted Handshake Message

3.总共握了几次手？

最后总结一下， TLS建立连接时总共进行了几次握手？

第一次：Client向Server发送 Client Hello，包括协议的版本信息、密码套件、随机数(Client Random)等；

第二次：Server向Client发送 Server Hello，包括所选密码套件、协议版本、数字证书、随机数(Server Random)；

第三次：Client向Server发送协商密钥的参数、更新加密协议、发送密文等；

第四次：Server向Client发送新建会话Tickets、发送密文以验证对称加解密通道；

这就是TLS的四次握手成功。