背景知识

对称加密

加密秘钥和解密秘钥相同，加解密速度比非对称加密快

常用算法： DES ,AES

非对称加密

公钥公开，私钥保密

一方加密，需要用另一方进行解密

常用算法： RSA

https 传输过程

过程如图所示

• 先通过 RSA 交换 AES 口令
• ...

1 客户端发起请求

2 服务端配置

服务端配置了公钥（证书信息），私钥

3 传送证书

包含了证书颁发机构，过期时间等信息

4 解析证书

验证该证书是否有效，

怎么验证？ 如果异常，出现提示；

否则生成一个随机值，并用证书（公钥）对该随机值加密

5 传送加密信息

将加密后的随机值传送给服务端

6 服务端解密

服务端用私钥解出随机值，如果解不出，说明公钥有问题

7 传输加密后的信息

后面的数据将采用对称加密进行传输，密钥为随机值

8 客户端解密信息

客户端使用刚刚生成的随机数解密信息

Q&A

Q: 一共携带几次随机数？为什么需要三次

Q1: 验证安全后，后面的数据传输为什么不能使用非对称加密来做？

因为公钥（证书）大家都有，如果仅用非对称加密的话，服务端用私钥加密，客户端需要用公钥解密，而由于公钥大家都有，所以服务端响应的数据如果被拦截，是可以被解密然后获取到具体信息

当然这种情况下客户端请求的数据不会被拦截

另外一点就是非对称加解密的效率较低

Q2: 什么是中间人攻击

dns 解析被污染，用户访问的地址指向中间人服务器

tls 建联阶段，中间人服务器拿到服务器返回的证书A，返回给浏览器一个伪造证书B

由于各种原因（这里不展开），浏览器信任了中间人服务器发来的证书B

浏览器通过该证书B 对随机字符串进行公钥加密，并发往中间人服务器

由于中间人服务器有证书B对应的私钥，可以解开得到这个随机字符串，于是将该随机字符串又用证书A加密后，返回给服务器

服务器用私钥解密拿到该随机字符串，并把响应内容通过该随机字符串做对称加密返回

由于中间人知道该随机字符串，故

中间人可以解开浏览器的请求内容以及服务器的响应内容

达到了中间人攻击的效果

Q3: 中间人攻击时，返回合法证书会怎么样

返回了原服务器的证书，浏览器是会信任该证书，可是由于没有私钥，中间人服务器并解不出由该证书加密的随机字符串，进而也达不到攻击的效果

Q4: 浏览器怎么验证证书是合法的

• 验证域名，有效期，证书来源

有被篡改的可能呀，所以

• 通过 CA 服务器判断证书是否被篡改

已经验证过了，每次都得验证么？如何优化？所以

• 通过 CRL 和 OCSP 判断证书是否已吊销，OCSP 可减少与 CA 服务器的交互

Q5：为什么抓包工具可以抓取 https 的网络包？

• 抓包工具本身就是一种中间人攻击手段（证书转发，通信拦截）
• 若仅开启抓包工具未信任证书，只能抓取 http 包
• 若再信任了抓包工具的根证书，将其放入受信任根证书存储中，就可以实现 https 包的抓取了

参考

1. https://cloud.tencent.com/developer/article/1335821
2. 你连 HTTPS 原理都不懂，还讲“中间人攻击”？ (opens new window)
3. https://schaepher.github.io/2020/04/25/https-certification/