通俗易懂的TCP，SSL以及HTTPS的连接建立过程详解

可以参考B站的一个视频，把TLS/SSL的连接建立过程降解的非常透彻。配合这篇博客食用更佳。一遍不懂请多看几遍，很有用！

1 说明

1.1 对称加密的和非对称加密

在数字加密算法中，通过可划分为对称加密和非对称加密。

什么是对称加密？

1. 在对称加密算法中，加密和解密使用的是同一把钥匙，即：使用相同的密匙对同一密码进行加密和解密；

2. 加密过程如下：

加密：原文 + 密匙 = 密文

解密：密文 - 密匙 = 原文

3. HTTPS是建立在SSL/TCL协议之上，而SSL/TLS是建立在TCP协议之上。
   所以HTTPS的建立过程可以分解为TCP + SSL/TLS + HTTP协议依次建立连接的过程
4. 优点：算法简单，加密解密容易，效率高，执行快。
5. 缺点：相对来说不算特别安全，只有一把钥匙，密文如果被拦截，且密钥也被劫持，那么，信息很容易被破译。

非对称加密

1. 对称加密是使用的同一把密匙进行加密和解密。那么，非对称加密自然是使用不同的密钥进行加密和解密。非对称加密有两个钥匙，及公钥（Public Key）和私钥（Private Key）。公钥和私钥是成对的存在，如果对原文使用公钥加密，则只能使用对应的私钥才能解密；因为加密和解密使用的不是同一把密钥，所以这种算法称之为非对称加密算法。 非对称加密算法的密匙是通过一系列算法获取到的一长串随机数，通常随机数的长度越长，加密信息越安全。通过私钥经过一系列算法是可以推导出公钥的，也就是说，公钥是基于私钥而存在的。但是无法通过公钥反向推倒出私钥，这个过程的单向的。

2. 优点：安全，即使密文被拦截、公钥被获取，但是无法获取到私钥，也就无法破译密文。作为接收方，务必要保管好自己的密钥。

3. 缺点：加密算法非常复杂，安全性依赖算法与密钥，而且加密和解密效率很低，一般用于网站的SSL证书的验证

2 SSL和TLS

2.1 什么是数字证书？

数字证书有点类似于我们的居民身份证，只是数字证书是基于互联网通信的，用于标记通信双方身份的一种方式。

数字证书绑定了公钥及其持有者的真实身份，它类似于现实生活中的居民身份证，所不同的是数字证书不再是纸质的证照，而是一段含有证书持有者身份信息并经过认证中心审核签发的电子数据，广泛用在电子商务和移动互联网中。

服务端可以向证书颁发机构CA申请证书，以避免中间人攻击（防止证书被篡改）。证书包含三部分内容：tbsCertificate（to be signed certificate）待签名证书内容、证书签名算法和CA给的数字签名（使用证书签名算法对tbsCertificate进行哈希运算得到哈希值，CA会用它的私钥对此哈希值进行签名，并放在签名部分）。签名是为了验证身份。

2.2 SSL和TLS的关系

SSL是TLS的前身。由于HTTPS的推出受到了很多人的欢迎，在SSL更新到3.0时，IETF（The Internet Engineering Task Force - 互联网工程任务组）对SSL3.0进行了标准化，并添加了少数机制(但是几乎和SSL3.0无差异)，标准化后的IETF更名为TLS1.0(Transport Layer Security 安全传输层协议)，可以说TLS就是SSL的新版本3.1，并同时发布“RFC2246-TLS加密协议详解”，如果想更深层次的了解TLS的工作原理可以去RFC的官方网站：http://www.rfc-editor.org，搜索RFC2246即可找到RFC文档！ ——以上就是历史背景

因为SSL名气更大，所以我们就经常把他们混着用；
目前绝大部分浏览器都不支持SSL，而支持TLS

3 HTTPS建立连接的过程

3.1 首先正常的TCP三次握手是不变的

1. 第一次握手：客户端向服务端发起建立连接请求，客户端会随机生成一个起始序列号x，客户端向服务端发送的字段中包含标志位SYN=1，序列号seq=x。第一次握手前客户端的状态为CLOSE，第一次握手后客户端的状态为SYN-SENT。此时服务端的状态为LISTEN
2. 第二次握手：服务端在收到客户端发来的报文后，会随机生成一个服务端的起始序列号y，然后给客户端回复一段报文，其中包括标志位SYN=1，ACK=1，序列号seq=y，确认号ack=x+1。第二次握手前服务端的状态为LISTEN，第二次握手后服务端的状态为SYN-RCVD，此时客户端的状态为SYN-SENT。（其中SYN=1表示要和客户端建立一个连接，ACK=1表示确认序号有效）
3. 第三次握手：客户端收到服务端发来的报文后，会再向服务端发送报文，其中包含标志位ACK=1，序列号seq=x+1，确认号ack=y+1。第三次握手前客户端的状态为SYN-SENT，第三次握手后客户端和服务端的状态都为ESTABLISHED。

3.2 建立TLS/SSL连接

协商加密算法阶段：

1. 客户端会在第三次TCP握手或者在新发送的TCP报文段中发送一个 client hello报文给服务端，报文段中包含客户端支持的所有SSL加密算法(也称加密套件)和TLS/SSL版本以及所要访问的域名(服务器需要通过域名返回域名对应的TSL证书)，同时会包含一个生成的第一随机数

[外链图片转存中…(img-eGCUj5eV-1639744405270)]

2. 服务端收到SSL的hello报文后，会发送server hello报文进行响应，报文段中包含选中的加密算法和TSL版本，同时也包括随机生成的第二随机数

证书验证阶段(使用非对称加密)：
3. 接着服务器会再依次发送两个报文给客户端，第一个报文中包含了服务端证书的相关信息，第二个报文中包含公钥信息；如果服务器也需要客户端的证书则会在第二个报文中声明，比如在登录网上银行的场景中则有这个需求
这样客户端浏览器就可以根据自己的证书列表来确认这个服务器是否可信

第一个报文

[外链图片转存中…(img-8PZxv59M-1639744405277)]

第二个报文

4. 客户端使用证书的认证机构CA公开发布的RSA公钥对该证书进行验证，下图表明证书认证成功。
   
   首先，要想了解清楚解密过程，就必须先搞懂数字签名的制作过程，数字签名的制作过程：

• 使用CA证书签名算法对证书内容（待签名证书内容）进行hash。
• 对hash后的值用CA自己的私钥加密，得到数字签名。

浏览器验证过程：

• 拿到证书，得到证书内容、证书签名算法和数字签名。
• 用CA机构的公钥对数字签名解密（由于是浏览器信任的机构，所以浏览器会保存它的公钥）。
• 用证书里的签名算法对证书内容进行hash。
• 比较解密后的数字签名和对证书内容hash后的哈希值，相等则表明证书可信，否则即不可信，拒绝对该服务器的访问。自此便完成了网站的安全认证工作

5. 服务端发送server hello done报文给客户端，表示服务器已经把公钥和证书信息传送完毕
   

建立会话密钥阶段（为使用对称加密传输数据做做铺垫）：

6. 客户端发送client key exchange报文给服务端，报文中包含随机生成的第三个随机数，也称为预主密钥，在装入报文之前，会用公钥加密；同时客户端也会利用第一，第二和第三随机数生成会话密钥。
   

• 服务端收到客户端的报文后，会使用私钥进行解密，这样就得到了预主密钥，而且只有客户端和服务端知道这个预主密钥，没有其他人知道(因为预主密钥一旦被公钥加密，只能由私钥加密，反之同理，所以除非私钥泄露了，否则没有人会知道预主密钥)。
• 得到预主密钥后，服务端会使用第一随机数，第二随机数和预主密钥也生成一个会话密钥，这个会话密钥和客户端生成的会话密钥是一样的

8. 至此TSL连接建立完成，可以开始传输数据，并且使用同一个私钥密钥来加解密(也称为对称加密)。

3.3 建立HTTPS连接

浏览器和服务端只需要根据响应的HTTP连接规则(包括长连接还是短连接，流水线和非流水线连接)实现数据的加密传输

为什么整个SSL的连接建立过程不全部使用非对称加密？

结合1.1的解析，可知非对称加密算法十分复杂，加密解密时间长，效率低，因此我们只在TSL连接建立时才使用，后面的数据传输环节统一使用对称加密，这样既能保证效率，又能极大的增强安全性。