HTTPS趣解

为什么

在HTTP刚被发明出来的时候，网页都是没有加密的，这就意味着你在浏览器中填写的所有信息，都有可能被其他人所窃取以及篡改。

想象一个场景，韩梅梅和李雷上课偷偷的传纸条，小刚坐在两人中间位置。由于韩梅梅和李雷互相不认识对方的签名和字迹，小刚不仅可以偷偷的看纸条的内容，还可以自己对内容进行篡改，甚至假冒李雷给韩梅梅写情书。

在这种情况下，我们肯定是没办法通过HTTP进行金融转账，聊天，甚至都没法玩网络游戏。

在1994年，网景公司(NetScape)推出了SSL 1.0版本，随后又进行了版本升级。现在最新的版本是SSL3.0，TLS1.2等。而HTTPS，我们可以理解为经过SSL/TLS加持的HTTP(HTTP Over SSL/TLS)。

加密方式

那么SSL/TLS是怎么实现的呢？这里我们要引入对称加密和非对称加密两种加密方式。这两类算法是实现HTTPS的核心算法。

我之前写过文章介绍过最常见的非对称加密算法RSA，里面详细讲解了非对称加密的实现原理。今天我们不再详细介绍算法，只谈各种算法在HTTPS中有什么用处。

非对称加密算法的特征是有两个秘钥，一个是公钥，一个是私钥。公钥加密的信息只有私钥能解，私钥加密的信息只有公钥能解开。

我们想象一个场景，假设杨过和小龙女失去联系十多年，不幸小龙女在绝情谷呆久了变成了脸盲，这导致他们见面却无法彼此相认。但是聪明的小龙女发现他们有一个玉佩，当年刚好摔成2半，一半(私钥)在杨过身上，一半(公钥)在小龙女那里。只要杨过和小龙女的半块玉佩能严丝合缝合在一起，他们就可以确认彼此的身份。

从这个特征我们可以得知，非对称加密主要用于身份认证，这在HTTPS起到一个非常重要的作用，普通用户可以据此确认网站(例如银行、电商)不是假冒的，不会把我们的钱骗走。

既然上面都解决了认证问题，那么我们为什么还需要对称加密呢？这个主要的原因就是非对称加密算法性能不太好，当彼此确认身份之后，后面的通信就可以通过对称加密来完成。

对称加密算法更好理解一点，它只有一个密钥，既能加密信息也能解密信息。就好像一个钥匙对应一把锁，钥匙是密钥，锁是加密的信息。在HTTPS通信会话中，服务器和浏览器持有相同的钥匙(秘钥)，他们之间的传递的消息就是锁(加密信息)。

好了，我们可以总结一下HTTPS加密的过程。

浏览器和服务器互相确认身份。

浏览器确认了服务器身份后，交换秘钥，开始通信。

好了，聪明一点的同学肯定就开始疑惑了，因为在上面假设的场景中，杨过还是可以骗小龙女的。假如杨过和人比武输了，玉佩被人抢了，那小龙女岂不是被别人骗走了？但是小龙女聪明啊，她在对比玉佩之前，先找来欧阳锋来认一下他干儿子，在欧阳锋确认无误之后，她才可以确定眼前这个糙汉子是真的杨过。

上面这个场景里的欧阳锋，其实就是HTTPS场景里的证书。

证书

又有聪明的同学问问题了，小龙女不是脸盲吗？她怎么会认得欧阳锋呢？

这个问题其实小龙女也会考虑，她虽然脸盲，但是她不蠢啊。她为了确定欧阳锋的身份，她可以一直查下去，这样她就可以孤独终老了。

故事虽然荒谬，但是真实世界就是这样的。在HTTPS的场景中，用户的电脑其实已经预装了很多根证书，这些是用户可以无条件信任的。

证书上面会有其它证书对其进行签名，最上面就是根证书，根证书自己证明自己是真的。

我们可以理解欧阳锋是一个证书，那么根证书就是金庸本人，金庸可以对所有武侠人物进行认证，但是他自己的身份就不用再证明了。

所以正版操作系统的信任链条的终点是微软和苹果这些信誉良好的巨头公司以及他们信任的证书颁发机构，而盗版操作系统的信任链条，随时可以被人植入非法的证书。

证书的作用我们已经知道了。那么证书和网站之间的关系也很容易理解啦，证书颁发机构(CA)用自己的私钥，对网站信息(网站地址，公钥)进行签名之后，发给网站。网站拿到签名之后再给浏览器，浏览器将签名和自己电脑上的根证书对比一看就能确认网站信息是否是伪造。

说的简单一点，就是欧阳锋和杨过之间，金庸和欧阳锋之间，他们两两也有一对玉佩，他们3个能对上，那么小龙女和杨过也能对上啦。

握手过程

好了，杨过和小龙女总算确认了彼此的身份，这个过程我们称之为握手，虽然这个握手很麻烦，但是还是很形象的。

下面干货来了，我们详细展开SSL的握手过程：

上图是CloudFlare博客的SSL握手示意图，左边是浏览器，右边是网站服务器，虽然是英文，但是过程很好理解：

浏览器发送一个随机数clientRandom到浏览器，同时还有支持的非对称加密算法(这里是RSA)

服务器拿到了clientRandom，生成了serverRandom和自己的公钥证书等信息发给了浏览器

浏览器拿到了serverRandom之后，通过公钥证书等信息确认服务器的身份，生成一个新的随机数parameterSecret，并通过服务器公钥加密，再发给服务器

服务器用自己的私钥解密得到parameterSecret

现在服务器和浏览器同时有用三个一样的随机数，clientRandom, serverRandom, paramterSecret，通过这3个数生成一个对称加密的秘钥，开始了愉快的加密会话过程

为什么在之前的故事上，再加上3个随机数呢，那是因为握手的过程是不加密的，这么做是为了防止第三方突然跑进来篡改数据。一旦有一个随机数不对，最后加密会话就无法建立，因为秘钥不对。

会话秘钥

因为浏览器和服务器有相同的秘钥，它们建立相互信任的通信会话就很好理解了。

如果会话中断，那么会话怎么恢复呢？在上图中，服务器还向浏览器发送了一个会话ID(Session ID)。不同的会话(Session)的ID是不一样的，当浏览器发送的请求带有这个ID，服务器确认之后，就可以恢复会话。

一般服务器的会话ID是有时间限制的，中断时间过长，再次通信就需要重新握手。

HTTPS中间人

理解了第一部分的根证书原理之后，我们就很容易理解Charles等软件如何监听HTTPS数据了。Chales会新建一个根证书以及一对公钥私钥，充当一个中间人身份，当用户信任了这个根证书之后，Charles就可以监听所有的加密会话了，详细过程见下图：

图片来自 @rushjs https://www.jianshu.com/p/405f9d76f8c4

所以，既不要轻易安装盗版操作系统，也不要轻易信任第三方给你的根证书。

总结

总的来说，HTTPS的过程可以分为两部分：

握手建立信任，主要利用非对称加密算法(如RSA)以及第三方机构颁发的信任证书

建立信任后开始的加密会话

握手过程比较复杂，我们通过小龙女和杨过的相认过程来进行解释。他们相认的过程不是无缘无故建立起来的，小龙女必须通过一个权威的第三方才能确认杨过的身份。

这也说明，在真实的陌生人世界中，建立信任是一个多么难的事情，这个世界永远也没有100%的信任方案，但是我们还是可以建立正确的安全意识，只要操作得当，安全还是有保障的。