HTTPS的工作原理及DNS的工作过程

HTTPS

HTTP协议安全上存在以下三个风险：完整性可用性保密性

窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
冒充风险，比如冒充淘宝网站，用户钱容易没。

HTTPS 在 HTTP 与 TCP 层之间加入了 TLS 协议，来解决上述的风险。

TLS 协议是如何解决 HTTP 的风险的呢？

TLS能够加密交互信息，如果信息泄露被篡改则会有警告提示，并且拥有身份证书证明发送端非伪造。

TLS 握手

上述每个框都是一个记录，多个记录可组合为一个tcp包，通常四个包就可以完成TCP握手

因为需要先完成TCP连接，然后通过TLS握手才建立安全通信链接，所以可以发现HTTPS是应用层协议。

密钥交换算法

因为在传输过程中想要保证加密密钥的安全性，所以采用了非对称加密的方法来保护对称加密的加密密钥。

RSA密钥协商握手过程

TLS 第一次握手

客户端发起握手请求（ClientHello）

客户端向服务器发送第一个消息，包含以下关键信息：

支持的 TLS 版本（如 TLS 1.2）。
支持的加密套件列表（需包含以 RSA 为密钥交换方式的套件，如TLS_RSA_WITH_AES_256_CBC_SHA）。
客户端生成的随机数（Client Random）：16 字节，用于后续密钥计算。
其他可选信息（如压缩方法、扩展字段等）。

TLS 第二次握手

服务器回应（ServerHello）

服务器根据客户端的请求，选择合适的配置并返回消息：

确认使用的 TLS 版本和加密套件（必须是客户端支持的 RSA 类套件）。
服务器生成的随机数（Server Random）：16 字节，同样用于密钥计算。
（可选）会话 ID：用于复用已有会话，减少握手次数。

客户端验证证书

服务器发送证书及相关信息（Certificate + ServerHelloDone）

Certificate 消息：服务器向客户端发送自己的数字证书（包含服务器 RSA 公钥），证书链可能包含多级 CA 证书（从服务器证书到根 CA 证书）。
（可选）CertificateRequest：若服务器需要验证客户端身份（如双向认证），会请求客户端证书。
ServerHelloDone 消息：表示服务器已完成初始消息发送，等待客户端回应。

TLS 第三次握手

客户端发送加密的预主密钥（ClientKeyExchange）

客户端将加密后的 PMS 通过ClientKeyExchange 消息发送给服务器。由于 PMS 用服务器公钥加密，中途被窃听也无法解密。

客户端和服务器计算会话密钥（Master Secret + Session Keys）

服务器解密 PMS ：服务器收到加密的 PMS 后，用自己的RSA 私钥解密，得到原始的 Pre-Master Secret。
计算主密钥（Master Secret）：客户端和服务器分别使用相同的算法，结合以下三个参数计算 Master Secret：

plaintext
复制代码
```
Master Secret = PRF(Pre-Master Secret, "master secret", Client Random + Server Random)
```
其中，PRF是伪随机函数（Pseudorandom Function），用于将输入转换为固定长度的密钥材料。
生成会话密钥：再用 Master Secret、Client Random、Server Random 通过 PRF 生成用于实际通信的对称密钥（如 AES 密钥、HMAC 密钥等），包括：
- 客户端加密密钥、服务器加密密钥（对称加密，用于数据加密）。
- 客户端 MAC 密钥、服务器 MAC 密钥（用于数据完整性校验）。

客户端验证握手完整性（Finished 消息）

客户端用生成的会话密钥，对之前握手过程中的所有消息（ClientHello 到 ClientKeyExchange）计算摘要（通过 MAC 算法），并加密后通过Finished 消息发送给服务器。
目的：证明客户端已正确生成会话密钥，且握手过程未被篡改。

TLS 第四次握手

服务器验证握手完整性并回应（Finished 消息）

服务器用自己生成的会话密钥，对相同的握手消息计算摘要，与客户端发送的 Finished 消息解密后的值对比，验证客户端是否正确生成密钥。
验证通过后，服务器同样生成Finished 消息（加密握手消息摘要）并发送给客户端，证明服务器也已正确生成密钥。

握手完成，开始加密通信

客户端和服务器均验证通过后，握手结束。后续所有通信数据均使用协商出的对称密钥进行加密和校验，确保机密性和完整性。

DNS域名解析的过程

DNS解析方式
正向解析：将FQDN----->IP
反向解析：将IP----->FQDN
1、在浏览器中输入www . qq .com 域名，操作系统会先检查自己本地的hosts文件是否有这个网
址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
2、如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，
如果有，直接返回，完成域名解析。
3、如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/IP参数中设置的
首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包
含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
4、如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则
调用这个IP地址映射，完成域名解析，此解析不具有权威性。
5、如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设
置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收
到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。
本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理qq.com的DNS服务器地址给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找qq.com域服务器，重复上面的动作，进行查询，直至找到www . qq .com主机。
6、如果用的是转发模式，本地DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器
进行解析，上一级服务器如果不能解析，或找根DNS或把请求转至上上级，以此循环。找到最后
把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。
注：从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间使用的交互查询就是迭代查
询。 114.114.114.114是国内移动、电信和联通通用的DNS，手机和电脑端都可以使用，干净无广告，解析成功率相对来说更高，国内用户使用的比较多，而且速度相对快、稳定，是国内用户上网常用的DNS。
8.8.8.8是GOOGLE公司提供的DNS，该地址是全球通用的，相对来说，更适合国外以及访问国外
网站的用户使用。