HTTPS 是如何保证安全的

众所周知,HTTP 协议是明文传输的,在网络世界里用 HTTP 协议发送报文相当于裸奔,于是就有了 HTTPS
这个 S 是什么呢,是如何保证我们发送的报文就不被窃取和篡改了呢,让我们慢慢道来

其实这个 S 指的就是 SSL/TLS
我们知道 HTTP 在网络协议中属于应用层,在发送报文时会将报文交给 TCP 进行传输,而 TCP 层面则是明文的,于是 HTTPS 在将报文发给 TCP 之前,通过 TLS 将报文进行加密后再通过 TCP 进行传输

那么 HTTPS 是如何进行加密的呢

说到这里,我们需要先来了解一下加密算法

对称加密

所谓对称加密,就是用来加密和解密的密钥都是同一个, 当我们使用对称加密的时候,就是用密钥将元数据通过加密算法,转变成密文,当另一方需要将密文转成原文的时候,需要用同一个密钥和相对应的解密算法,将密文给还原成原文。
但对称加密的缺陷在于,如何保证密钥的安全性,如何保证只有通信的双方才持有该密钥而不被其他人窃取,而非对称加密就是来解决这个问题的

非对称加密

非对称加密,是因为数学家们研究出了一种算法,这种算法两个不同的密钥,通过密钥 A 对原文进行加密后,只能通过密钥 B 进行解密。和对称加密不同的是,非对称加密只有一个算法,不需要『加密算法』和『解密算法』,也就是说同一个算法,经过密钥 A 加密过的密文只能由密钥 B 解密。

但所谓的『原文』和『密文』只是相对的,我们也可以将所谓的『原文』当做被加密过的数据,而把『密文』当做加密前的数据,所以从下图看,密钥 A 和密钥 B 其实也是可以相互交换的,密钥 B 可以用来当做加密用的密钥,而让密钥 A 当做解密用的密钥。

但一般来说不会这么做,这是因为非对称加密的算法是有很多种的,而密钥 A 和密钥 B 是成对存在的,一般来说是不能相互推导的,即我不能通过密钥 A 计算出密钥 B,也不能通过密钥 B 计算出密钥 A,但也不是绝对的,其实也是可以推导出来的,只不过对于如今的计算运力来说不足以在短时间内推导出来,可能需要上百年上千年,所以我们姑且认为是无法推导出来的。
但也有一些非对称加密算法是例外的,有些非对称加密的算法是可以通过密钥 A 计算出来密钥 B 的。
所以这个时候,我们就不能用密钥 B 进行加密而把密钥 A 公开了。因为这样的话,就相当于所有人都知道了密钥 A 和 密钥 B 是什么,就相当于没有加密了。

而密钥 A ,我们把它称为私钥,密钥 B 称为公钥。
所谓私钥,就是要对信息进行加密的持有者所持有的密钥,这个密钥只能自己持有,不能公开,而公钥是可以在任何地方公开的,只有持有私钥的一方才可以将被公钥加密过的信息解密得到原文。

也就是说,假如我要发送一个消息给对方,我需要先得到对方的公钥,然后用对方的公钥对信息进行加密后再发送给对方,而只有对方(公钥对应的私钥拥有者)才能将信息还原成原文

在消息的发送前,发送方需要获取到接收方的公钥,而在这个过程中,发送方是如何确定这个公钥就真的是接收方的公钥而不是被篡改过的呢。
且听我娓娓道来。
让我们先来看一个知识点(敲黑板)

非对称加密的应用

数字签名

所谓数字签名,就是证明这个东西是我发出的
在网络世界里,所有的数据包都有可能被截获篡改,所以当我们收到某个消息时,如何确定这条消息就是我认为的那个人发出的呢,这就需要用到『非对称加密』的一个应用–『数字签名』了。

通过上图可见,当接收方对比 摘要摘要’ 相同时,就可以认为这条消息是没有被篡改过的,是来自于这个公钥所对应的私钥的拥有者发出的。

但在我们的消息发送的过程中还有个问题,接收方怎么就知道这个公钥就是我认为的消息的发送者的呢。万一中间有人把所有的信息(公钥修改了,同时用新的公钥计算出密文和 hash)都修改了,那接收方通过这种方式验证出来的结果都是正确的,那怎么办。

于是问题的痛点就落在了我们需要保证公钥的正确性上

这就需要证书了

数字证书

为了解决无法证明公钥的正确性的问题,有了数字证书。
数字证书是由数字证书认证机构(CA,Certificate Authority)和其相关机关颁发的。数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。

要得到一份数字证书,需要由服务器端的(或者说是信息的发送方)到数字证书认证机构去申请,而 CA 确认该身份后通过申请,则会给该申请者一个包含经过 CA 签名的公钥的数字证书。

在发送数据的时候,会将数字证书也带上,数字证书中包含了该服务端(信息发送方)的公钥,以及其他信息,接收方在拿到数字证书时,先通过证书的签发方看该证书是否有效可信任,接下来就拿其证书机构的公钥(2)做数字签名验证,验证通过则可以证明该证书公钥(1)是正确的。
这样就达到了公钥交换的正确性保障

下面再来讲讲 HTTPS 是如何交换公钥后进行加密的。

Client Hello(客户端支持的 TLS 版本,加密算法,压缩算法等,以及一个随机数 A)

Server 证书
Server 决定的双方通信所用的 TLS 版本,对称加密算法
一个随机数 B
Hello Done

客户端校验证书
Client Key Exchange 客户端生成 pre-master key,使用公钥进行加密
Change Cipher Spec(编码通知改变,告知服务端后面的通信内容都使用双方商定的加密方式和加密密钥进行对称加密)
生成 Hash 值,Client Finish

Server 通过私钥计算出 pre-master key
校验 Hash 是否正确
Change Cipher Spec(编码通知改变,告知客户但后面的通信内容都使用双方商定的加密方式和加密密钥进行对称加密)
生成 Hash 值,Server Finish

后面的通信则使用 A、B、以及 pre-master key 以及双方约定好的算法生成 session-key 进行对称加密