HTTP/HTTPS和TCP、TLS/SSL的那些关系

客户端验证证书是否合法，如果不合法则提示告警

（2）数据传输阶段

当证书验证合法后，在本地生成随机数（例如：生成abcde）

通过公钥加密随机数，并把加密后的随机数传输到服务端

服务端通过私钥对随机数进行解密（解密后服务端得到：abcde）

服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

3、TCP——传输层

TCP（ ，传输控制协议）是一种面向连接的、可靠的、基于字节流的通信协议，数据在传输前要建立连接，传输完毕后还要断开连接。

TCP的三次握手：

1、从最开始双方都处于状态。然后服务端开始监听某个端口，进入了状态。

2、然后客户端主动发起连接，这一过程由客户端执行来触发。将标志位 SYN置为1，随机生成一个序号seq=x ， 自己变成了SYN-SENT状态。

3、服务端接收到，将SYN和ACK(对应客户端发来的SYN)都置为1，随机生成一个序号seq=y，还生成一个确认号ack=对方序号+1，自己变成了SYN-RCVD。

4、客户端收到确认后，检查收到的ack是否为自己的序号+1，若没问题则将ACK置为1，将自己的序号值seq设为对方的确认号，将自己的确认号ack置为对方序号+1，发给服务端，将自己变成了状态；服务端收到数据包之后，检查ack是否为自己序号+1，如果没问题也变成了状态。

两方可以开始传输数据了。

用川航举例子：

①四川8633请求建立连接(SYN)，并且发送出序号。

②服务端接受到信号，即有确认号（ACK）,此时并同样返回请求序号Seq

③客户端接受到信号，即有确认号（ACK），连接已经建立。

（小结：三次握手的关键是要确认对方收到了自己的数据包，这个目标就是通过“确认号（Ack）”字段实现的。计算机会记录下自己发送的数据包序号Seq，待收到对方的数据包后，检测“确认号（Ack）”字段，看Ack = Seq + 1是否成立，如果成立说明对方正确收到了自己的数据包。）

为什么需要第三次通信 ？

1、在第一次通信过程中，A向B发送信息之后，B收到信息后可以确认自己的收信能力和A的发信能力没有问题。

2、在第二次通信中，B向A发送信息之后，A可以确认自己的发信能力和B的收信能力没有问题，但是B不知道自己的发信能力到底如何，所以就需要第三次通信。

3、在第三次通信中，A向B发送信息之后，B就可以确认自己的发信能力没有问题。

小结：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

TCP的四次挥手：

四次挥手 指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在编程中，这一过程由客户端或服务端任一方执行close来触发。

由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。

（1）第一次挥手：发送一个FIN，ACK，确认号和序号，用来关闭到的数据传送，进入状态。

（2）第二次挥手：收到FIN后，发送一个ACK给，确认号为对方序号+1，进入状态。

（3）第三次挥手：发送一个FIN和ACK，序号用对方的确认号，确认号为对方序号＋1，关闭到的数据传送，进入状态。

（4）第四次挥手：收到FIN后，进入状态，接着发送一个ACK给，确认号为对方序号+1，进入状态，完成四次挥手。

川航图举例：

①客户端申请断开连接即FIN （我这边准备断开连接了）

②服务端接收信息返回，表示我已经接收到 （收到，请稍等，我这边准备一下）

③服务端发送信息表示可以断开连接 (我准备好了，你可以断开连接了）

④客户端接受信息，同时返回信息通知服务端自己收到信息，开始断开 连接(好的，拜拜！）

上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动关闭的情况:

应用层的进程，同时发出关闭命令，两端均从 变为了 状态，同时发送 FIN 段给对方。

然而发送完 FIN 段后，并未收到对端的 ack 而是对方发来的一个 FIN 段，于是直接进入 状态， 状态是一个新状态，之前我们没有遇到过，只在 TCP 状态机图里看到过。现在你要记住， 状态是由于同时关闭导致的。

又过了一会儿，TCP 接收到 ack 后，进入 状态。

**提问：**为什么连接的时候是三次握手，关闭的时候却是四次握手？

①因为当端收到端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。

②但是关闭连接时，当端收到FIN报文时，很可能并不会立即关闭，所以只能先回复一个ACK报文，告诉端，“你发的FIN报文我收到了”。

③只有等到我端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

4、 TLS/SSL——传输层

TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

散列函数 Hash：常见的有 MD5、SHA1、，该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定，针对数据的任何修改都会改变散列函数的结果，用于防止信息篡改并验证数据的完整性。在信息传输过程中，散列函数不能单独实现信息防篡改，因为明文传输，中间人可以修改信息之后重新计算信息摘要，因此需要对传输的信息以及信息摘要进行加密。

对称加密：常见的有 AES-CBC、DES、3DES、AES-GCM 等，信息的加密和解密用相同的密钥，掌握密钥才能获取信息。在对称加密中，信息安全的基础是保证密钥的安全。

非对称加密：即常见的 RSA 算法，还包括 ECC、DH 等算法，算法特点是，密钥成对出现，一般称为公钥(公开)和私钥(保密)。因此掌握公钥的不同客户端之间不能互相解密信息，只能和掌握私钥的服务器进行加密通信。服务器持有私钥可以实现一对多的通信，而客户端可以用公钥来验证服务器发送的数字签名。服务器只需要维持一个私钥就能够和多个客户端进行加密通信，但该算法的计算复杂，加密速度慢。

结合三类算法的特点，TLS/SSL 的基本工作方式是，客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的密钥，然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取。

SSL / TLS 握手详细过程

1、“ hello” 消息：客户端通过发送 “ hello” 消息向服务器发起握手请求，该消息包含了客户端所支持的 TLS 版本，支持的算法列表和密码组合以供服务器进行选择，还有一个 “ ” 随机字符串。

2、“ hello” 消息：服务器发送 “ hello” 消息对客户端进行回应，该消息包含了服务器选择的加密算法，服务器选择的密码组合，数字证书和 “ ” 随机字符串。

验证：客户端对服务器发来的证书进行验证，确保对方的合法身份，验证过程可以细化为以下几个步骤：

（1）检查数字签名

（2）验证证书链

（3）检查证书的有效期

（4）检查证书的撤回状态 (撤回代表证书已失效)

4、" "字符串：客户端向服务器发送另一个随机字符串 “ (预主密钥)”，这个字符串是经过服务器的公钥加密过的，只有对应的私钥才能解密。

5、使用私钥：服务器使用私钥解密 “ ”。

6、生成共享密钥：客户端和服务器均使用 ， 和 ，并通过相同的算法生成相同的共享密钥 KEY。

7、客户端就绪：客户端发送经过共享密钥 KEY 加密过的 “” 信号，为了防止握手过程遭到篡改，该消息的内容是前一阶段所有握手消息的MAC值。

8、服务器就绪：服务器发送经过共享密钥 KEY 加密过的 “” 信号，该消息的内容是前一阶段所有握手消息的 MAC 值。

9、达成安全通信：握手完成，双方使用对称加密进行安全通信。

第 8 与第 9 步用以防止握手本身遭受篡改。设想一个攻击者想要控制客户端与服务器所使用的算法。客户端提供多种算法的情况相当常见，某些强度弱而某些强度强，以便能够与仅支持弱强度算法的服务器进行通信。攻击者可以删除客户端在第 1 步所提供的所有高强度算法，于是就迫使服务器选择一种弱强度的算法。第 8 步与第 9 步的 MAC 交换就能阻止这种攻击，因为客户端的 MAC 是根据原始消息计算得出的，而服务器的 MAC 是根据攻击者修改过的消息计算得出的，这样经过检查就会发现不匹配。

5、证书校验

记录一个个人引发的问题，为什么窃听者不能有两个公钥和私钥去进行信息截取呢，这样不就完美获取信息了吗。

以下是解答：

1、什么是证书？是用来干嘛的？

证书就是数字化的文件，里面有一个实体(网站，个人等)的公共密钥和其他的属性，如名称、CA信息、加密算法等。该公共密钥只属于某一个特定的实体，它的作用是防止一个实体假装成另外一个实体。

证书主要有两个作用，一个是加密通信，一个是数字签名。

加密通信是保证数据不被别人截获并且不被知道通信内容的，主要是两个层次，一个是通信双方身份确认，避免对方是冒充的，另一个是数据通过公钥加密传输和使用私钥解密。这方面常见的具体应用就是SSL和HTTPS。

数字签名是用于识别签名者身份的，这个从字面就可以理解。你使用你的私钥进行签名，然后用户看到你的签名后用公钥检查，发现的确是你的数字签名，就可以了。这个常见的应用有代码发行商签名，就是签名控件的那种，邮件数字签名，电子公章等。

2、什么是CA，证书只有CA能发吗，我自己不能发证书吗？

CA是 的缩写，即证书颂发机构，他是一个负责发放和维护证书的实体，一般是第三方的。

CA的组织结构跟域名有些相似，有一个根CA，然后它派生了一些子的，子又生孙，孙又生子，子子孙孙无穷匮也。但是给人家当孙子的滋味是不好受的，要交年费的，而且一个证书一年上万块。于是乎，你可以自己当老大，就是自己当根，然后再发放证书，有一个缺陷是要取得别人的认可才行。自己做根CA要有一个根证书，然后自己给自己签名，就行了。然后再用这个根证书和根私钥给你的子机构签发证书就可以了。用户使用你签名的证书之前必须要把你的根证书给用户，让用户安装在受信任的根区域就算认可了。

3、证书校验的过程

证书链 ( chain)：也称为证书路径，是用于认证实体合法身份的证书列表，具体到 HTTPS 通信中，就是为了验证服务器的合法身份。之所以使用证书链，是为了保证根证书 (root CA ) 的安全，中间层可以看做根证书的代理，起到了缓冲的作用，如下图所示：

证书链从根证书开始，并且证书链中的每一级证书所标识的实体都要为其下一级证书签名，而根证书自身则由证书颁发机构签名。客户端在验证证书链时，必须对链中所有证书的数字签名进行验证，直到达到根证书为止。

4、根证书是CA认证中心给自己颁发的证书,是信任链的起始点。安装根证书意味着对这个CA认证中心的信任。

从技术上讲，证书其实包含三部分，用户的信息，用户的公钥，还有CA中心对该证书里面的信息的签名。验证一份证书的真伪（即验证CA中心对该证书信息的签名是否有效），需要用CA 中心的公钥验证，而CA中心的公钥存在于对这份证书进行签名的证书内，故需要下载该证书，但使用该证书验证又需先验证该证书本身的真伪，故又要用签发该证书的证书来验证，这样一来就构成一条证书链的关系，这条证书链在哪里终结呢？答案就是根证书，根证书是一份特殊的证书，它的签发者是它本身，下载根证书就表明您对该根证书以下所签发的证书都表示信任，而技术上则是建立起一个验证证书信息的链条，证书的验证追溯至根证书即为结束。所以说用户在使用自己的数字证书之前必须先下载根证书。

小结：

正如链接5、6、7所看到的，证书的校验需要预先在自己的客户端上安装根证书，用来校验证书的真实性，如果是窃听者自己制作的证书，他的根证书没有安装在我们的客户端上，那么他加密的信息是无法在我们的客户端上进行根证书校验，是无法通过的。而我们自己主动安装窃听者的根证书的话，是默认我们已经信任了窃听者的这种行为了。

以上是各个协议中的握手过程的一些个人记录，他们并不是说有固定的先后顺序，只是所在的协议不同，所产生的不同看法。从不同协议去解释了整个握手的过程，什么是握手，怎么握手，怎么挥手，为什么三次、为什么四次、怎么加密、为什么选择这种捂手的方式、以及证书的一个信任传递的问题。