HTTPS，Hyper Text Transfer Protocol over SecureSocket Layer，超文本传输安全协议。

在 TCP 和 HTTP 之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。

SSL代表安全套接字层。它是一种用于加密和验证应用程序（如浏览器）和Web服务器之间发送的数据的协议。 身份验证 ， 加密Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

SSL/TLS协议作用：认证用户和服务，加密数据，维护数据的完整性的应用层协议加密和解密需要两个不同的密钥，故被称为非对称加密；加密和解密都使用同一个密钥的 对称加密。 优点在于加密、解密效率 通常比较高HTTPS 是基于非对称加密的， 公钥是公开的， （1）客户端向服务器端发起SSL连接请求； （2） 服务器把公钥发送给客户端，并且服务器端保存着唯一的私钥 （3）客户端用公钥对双方通信的对称秘钥进行加密，并发送给服务器端 （4）服务器利用自己唯一的私钥对客户端发来的对称秘钥进行解密， （5）进行数据传输，服务器和客户端双方用公有的相同的对称秘钥对数据进行加密解密，可以保证在数据收发过程中的安全，即是第三方获得数据包，也无法对其进行加密，解密和篡改。

因为数字签名、摘要是证书防伪非常关键的武器。 “摘要”就是对传输的内容，通过hash算法计算出一段固定长度的串。然后，在通过CA的私钥对这段摘要进行加密，加密后得到的结果就是“数字签名”。

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密

因为 HTTP 是明文传输，所以会存在以下三个风险，使用起来极其不安全，所以就诞生了 HTTPS，也就是在 HTTP 之上加入了 SSL/TLS 安全协议，来解决 HTTP 的安全问题。

混合加密

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

采用「混合加密」的方式的原因：

对称加密只使用一个密钥，运算速度快，但密钥必须保密，无法做到安全的密钥交换。 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

校验机制：摘要算法+数字签名

在发送内容前，对传输的内容进行摘要算法（哈希函数）计算，得到一个唯一且无法推导的哈希值，即内容的指纹，将哈希值与内容一同发送出去，在接收后再次进行哈希计算，校验哈希值，从而保证内容是完整且未被篡改的。

但是仍然无法保证内容和哈希值都被中间替换过，所以需要再使用私钥加密，公钥解密的非对称加密来解决。

数字证书 通过摘要算法，我们能保证数据的完整性；通过数字签名，我们能保证数据的来源一定是私钥持有者。

但是还缺少了身份验证环节，万一公私钥被替换过，校验仍然可以通过。所以需要对公私钥进行身份验证，HTTPS 规定只有权威机构能够颁发证书，而且拿到证书后也需要进行权威机构的认证。

CA，Certification Authority，数字证书认证机构。数字证书的工作流程如下图所示。

TLS 建立连接的过程，就是客户端向服务器索要并验证 CA公钥，随后双方协商产生会话密钥的过程。

整个过程可以分为七个部分，其中 TLS 的握手过程涉及四次通信。接下来将根据 Wireshark 的抓包结果进行过程的拆分和分析。

TLS 层是在 TCP 层之上的，所以在建立 TLS 连接之前，需要先建立 TCP 连接。

第一次握手: 客户端发送syn标志位和seq num，向服务器申请建立连接，客户端状态由closed变为syn_send

第二次握手: 服务端返回 syn和ack标志位，ack num以及seq num，确认第一次握手的报文段，返回ack num=seq num(第一次握手发送的)+1，同意建立连接，服务器状态由listen变为syn_received

第三次握手: 发送确认报文段，返回ack以及ack num=seq num(第二次握手发送的)+1，客户端状态变为：established(完成连接)

最后: 服务器收到确认报文段，服务器状态由syn_received变为established(完成连接)

三次握手原因 (1) TCP连接的特性决定，一次RT(往返)完成一次TCP的动作。 即客户端一次请求携带的seq num必须得到服务端的ack num才会完成。如果没有返回确认报文段，由于重发机制，定时器经过了一次RTO，客户端就会重发报文。那为什么客户端最后一次发送之后，没有等待服务端发回ack报文段？ 这是因为服务端第二次发送的报文段里 包含ack以及请求syc报文，相当于把确认报文和请求报文合并了，所以最后客户端回复一个ack报文即可。

(2) 防止失效的报文创建连接。 因为互联网链路是非常复杂的，发送的报文可能会被互联中的网络设备阻塞，经过了一段时间才到达服务器，时间大于了RTO(Retransmission TimeOut)时间，导致客户端重发syc报文(重新创建新的连接，并丢失超时的连接)。如果只有两次握手，那么服务器每接收到syc报文(包括重发的syc报文)，就会创建多余的连接，造成服务器的资源浪费。如果有第三次握手，那么客户端就能够识别出服务端发出的syc和ack报文对应的请求连接在客户端是否存活，如果存活则发送第三次握手ack报文，确认建立连接。

由客户端向服务器发起建立 TLS 请求，请求的内容包括以下等信息：

服务器收到客户端的建立请求后，向客户端发出响应，回应的内容包括以下等信息：

客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送以下信息：

5.1 Client Key Exchange：基于前面提到的两个随机数（client random+server random），再生成第 3 个随机数 pre-master，然后通过CA证书中的公钥，对 pre-master 加密，得到 pre-master key，发送给服务器。

5.2 Change Cipher Spec：加密通信算法改变通知，表示客户端随后的信息都将用会话秘钥加密通信。

5.3 Encrypted handshake message：这一步对应的是 Cleint 的 Finish 消息，client 将前面握手的消息生成摘要，再用协商好的会话秘钥进行加密，这是客户端发出的第一条加密消息， 服务端接收后会用会话秘钥解密，能解出来说明前面协商的秘钥是一致的，至此客户端的握手完成。

会话密钥是用双方协商的加密算法和三个随机数：client random、server random、pre-master key 生成的。

服务器使用自己的 CA证书私钥对 pre-master key 解密得到 pre-master，再计算出会话密钥，随后向客户端发送以下信息：

6.1 Change Cipher Spec：加密通信算法改变通知，表示服务端随后的信息都将用会话秘钥加密通信。

6.2 Encrypted handshake message：这一步对应的是 Server 的 Finish 消息，服务端会将握手过程消息生成摘要，然后再用会话密钥加密，这是服务器发出的第一条加密消息，客户端接收后会用会话密钥解密，能解出来就说明协商成功。

四次挥手过程描述 第一次挥手: 客户端的应用说要关闭连接，给服务端发送一个含fin标志位的报文，客户端状态由established变为fin-wait-1

第二次挥手: 服务端收到客户端发来的fin报文，回复ack报文，告知服务端的应用要关闭连接，服务端状态由established变为close-wait，而客户端收到ack报文后，状态由fin-wait-1变为fin-wait-2

第三次挥手: 服务端应用说可以关闭连接了，给客户端发送fin报文，服务端状态由close-wait变为last-ack

第四次挥手: 客户端收到服务端发来的fin报文，回复ack报文，客户端状态由fin-wait-2变为time-wait，服务端收到ack报文后，直接关闭连接，状态由last-ack变为closed

客户端经过两次最大的报文存活时间后，关闭连接，状态由time-wait变为closed

四次挥手原因 (1) 假设只有二次挥手 客户端发送fin报文，服务端接收fin后，返回ack报文。客户端接收到ack报文后，断开连接。然而服务器还有没有发送完成的报文，当发送数据报文给客户端，发现客户端已经断开连接。比如说你在浏览器输入一个地址后会跟服务端建立连接，服务端会根据TCP把数据分成很多的报文段一一地发送给客户端，在没有全部发送完成之前，客户端在完成二次挥手就断开连接，服务端还没发送完的报文段就会抛客户端失去连接的异常。

(2) 假设只有三次挥手， 服务端就不能及时地关闭连接，导致连接空闲一段时间，浪费资源。

至此，整个 SSL/TLS 的握手阶段全部结束，TCP 四次挥手断开连接。

接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用会话秘钥加密内容