HTTPS | Code Prose

type

status

date

slug

summary

定义

HTTP over SSL 的简称，即⼯作在 SSL（或 TLS）上的 HTTP。说⽩了就是加密通信的 HTTP。

SSL：Secure Socket Layer → TLS：Transport Layer Security 在 HTTP 之下，TCP 之上增加一个安全层，用于保障 HTTP 的加密传输

工作原理

在客户端和服务器之间协商出⼀套对称密钥，每次发送信息之前将内容加密，收到之后解密，达到内容的加密传输。

💡

为什么不直接⽤⾮对称加密？

⾮对称加密由于使⽤了复杂了数学原理，因此计算相当复杂，如果完全使⽤⾮对称加密来加密通信内容，会严重影响⽹络通信的性能

HTTPS连接建立过程

大致流程

Client Hello

Server Hello

通过 Wireshark 抓包也可以看到

服务器证书信任建⽴

实际流程图如下：

💡

为什么要这么麻烦，为什么不直接发送服务器的公钥？

在不安全网络环境下，假设我们只发送服务器公钥

服务器发送公钥的途中，公钥可能会被篡改，如何确认服务器公钥的合法性？

我们可以想到之前的非对称算法的签名功能。对服务器公钥进行一次 Hash计算再通过证书颁发机构 A 的私钥对 Hash 字符串进行一次计算，就能得到证书颁发机构 A 签名后服务器公钥（这里称为【服务器公钥的签名】），然后只需要再带上服务器公钥的签名和证书颁发机构 A 的公钥就可以解决服务器公钥的合法性。

但是这里又会有同样的问题，证书颁发机构A的公钥的合法性也无法判断，如果再对证书颁发机构 A 的公钥进行签名，这样就循环反复没有实际解决问题，该怎么办呢？实际上循环签名的问题时不存在的，操作系统自带（用户也可以自己手动添加）一些根证书，这些根证书的公钥，是用户无条件必须信任的。那么就可以使用根证书机构的私钥对证书颁发机构的的公钥进签名。得到证书颁发机构 A 的公钥的签名，然后把证书颁发机构 A 的公钥的签名一起发送给客户端，变成这样：

那么客户端拿到数据后，通过系统自带的根证书的公钥对证书颁发机构 A 的公钥的签名进行转换，验证后，得到可信任的证书颁发机构 A 的公钥，然后，又可以通过证书颁发机构 A 的公钥对服务器公钥的签名进行转换，验证后，就得到了可信任的服务器公钥

通过 Wireshark 也可以看到：

浏览器也可查看证书的关系：

系统也可以看到证书的位置：

💡

另外说一下证书颁发机构的证书指的是什么？通过上面的流程图和 Wireshark 的分析：

客户端验证服务器证书

验证服务器公钥的合法性。
验证证书中的域名和实际访问的域名是否一致，不一致就验证不通过。

Pre-master Secret

💡

为什么需要客户端随机数，服务端随机数和 Pre Secret 随机数三个随机数？首先客户端随机数和服务端随机数是未加密通信时互相传输的。Pre-master Secret 是加密时传输的。服务器随机数是未了防止重放攻击（replay sttack，指的是抓取到用户请求，原封不动的发给服务端），如果没有服务端随机数，那么服务端会正常处理这个请求。

💡

为什么服务端和客户端通信需要使用两个不同的密钥？为了防止黑客把客户端发送给服务端的信息返回给客户端，或者把服务端发送给客户端的信息，发送给服务端。如果采用同一个密钥，那么双方在接收到自己的消息，任然会进行解密读取。

💡

什么是 Mac secret？ Mac secret 本质是 HMAC（hash-based message authenticate code：基于 Hash 的消息认证码）原理：把一段数据加上一个密码进行 Hash 计算。作用：既可以保证消息的可靠性，又可以确认消息的来源（只有拥有密码的人才能计算出同样的 Hash 值）案例： A 想给 B 发送一段消息（ABCD），A 和 B 约定了一个密码（Xxxx），A 发消息是吧ABCDXxxx 进行一次 Hash 计算得到 jflasjdl，然后把消息内容 ABCD 和 Hash 值 jflasjdl 一起发送给 B，B 拿到消息后，如果直接消息内容 ABCD，但是网络因素可能导致消息内容不正确，所以B通过读取到消息内容加上约定的密码，进行一次 Hash 计算，与读取到的 Hash 进行比较，就既可以确认消息内容的正确性又可以确认消息是由 A 发送的这里 A 和 B 约定的密码就是 HMAC