HTTPS

说道HTTPS，大家通常第一反应它的安全的，内容是加密的，所以安全性值得信赖。但是为什么是安全的？是怎么加密的？等等一些细节都是需要关注和学习的。

全称：

Hypertext Transfer Protocol over Secure Socket Layer。建立在SSL基础上的超文本传输协议。

HTTPS的组成部分是HTTP+SSL。所以HTTPS的安全部分就是由SSL协议来保证的。

原理学习和分析：

对于原理的解析，网上的文章也是一大把，本文也是参考了一篇分析文章来的，尝试通过一些场景分析来探究HTTPS的一个过程。

简单场景：

客户端A发送一个请求到服务端B，内容是Hello。

怎么保证安全呢？

保证安全的结果就是A发送的消息“Hello”只有B能看见，其他任何人都看不见。这样就是保证了安全。那么应该怎么做呢？大家立马肯定会想到，加密啊，A对消息加密，B接收到后解密，这样不就行了？那么解决方案如下：

这个就是一个简单的对称加密的过程，秘钥S充当加密和解密的过程。那么只要A和B不公开这个秘钥，其他人都不知道钥匙是什么的，通信就安全了。

但是问题来了，这只是一个客户端的场景啊，很多客户端呢？比如说下面的场景：

这就尴尬了，，大家都是用的同一个秘钥，等于没有加密啊，万一客户端A2是一个坏的客户端，它只要连接上服务器B就能得到秘钥，那么它能去拦截所以的请求，用秘钥S解密了。

怎么保证秘钥的安全性呢？

大家不能都用同一个秘钥，那么怎么办呢？很简单，大家都用不同的秘钥算了，如下图：

怎么来确保秘钥S1,S2,S3呢？

问题又出现了，怎么保证A1使用S1，A2使用S2，换句话说，服务端B怎么告诉客户端你应该使用哪一个加密算法呢？

服务端可以通过一些手段，比如说“协商”的方式，B和A1沟通一下，告诉A1，你使用S1秘钥，告诉A2，你使用S2秘钥。

怎么保证协商过程中的安全性呢？

问题又来了，一系列都是各种问题....这个协商过程怎么保证安全？A1和A2怎么确保这是B发送过来的秘钥呢？这个时候就出现了非对称加密算法了。非对称加密的特点简单说一下：私钥加密，公钥可以解密。公钥加密，私钥可以解密。只要服务端用私钥将S1，S2，S3进行加密，那么对应的客户端就能拿公钥解密，得到正确的S1，S2，S3（也就是每个客户端所要使用的对称秘钥）。

通过非对称加密算法进行对称加密算法的协商过程，至少保证了客户端A1，A2，A3拿到了安全的对称加密算法秘钥，这样客户端到服务端的请求是安全的，但是服务端向客户端的访问依然不安全（公钥的获取怎么保证安全）？

协商的对称加密算法怎么实现？

此处暂时不讲服务端到客户端的通信怎么保证安全，先来个插曲，对于协商的对称加密的秘钥如S1，S2，S3是怎么实现呢？

简单有效的办法就是随机数，没错，服务端为每一次交互可以生成一个随机数作为对称秘钥，这样有效的解决对称算法中秘钥怎么来的问题。

客户端公钥的获取怎么保证安全？

最近的一副上图中显示了，利用非对称秘钥算法可以保证客户端到服务端的安全性，但是一切都是基于客户端有公钥了，怎么保证这个公钥安全的到达每一个想访问的客户端是个问题？存在如下问题：

鉴于这个问题，HTTPS是怎么解决的？

数字证书？

HTTPS利用的是数字证书来解决公钥的发送问题，因为通过网络发送这个公钥的过程本身就是没法解决安全的问题，如果你说再利用非对称加密？这就是鸡生蛋，蛋生鸡的问题了，无穷无尽。

这个时候就需要利用一个公信平台，就是数字证书，简答来说，就是第三方平台用它们的私钥来加密我们服务器的公钥，然后发给客户端，客户端用第三方的公钥来解密和确认得到服务器的公钥。有点绕口，核心其实再次利用了一次非对称加密，只不过引入了第三方的公信中心。

这样的话不管中间的假服务器怎么使用自己的假私钥去加密，客户端都不能正常解析了。

但是，但是，问题又来了，数字证书你不能保证全给了正常的公司啊，假客户端一样可以去做数字证书啊，shit~~~（这场景其实你可以理解为假如我还是通过网络发送，但是做了2次非对称加密），其实和这种场景一样，只不过换成另一个名词，数字证书。

数字签名？

我们知道非对称加密可以实现两个特质，一个是确认发送内容，另一个就是确认发送者身份，而发送内容就是我们说的数字证书，而发送者身份就是我们说的数字签名。如下图简介：

数字签名的作用其实就是上图中确认身份的。它附属在数字证书中，用来表明身份。但是问题又来了，问题很多啊，客户端怎么去确认这个签名呢？比如类比我们上图的，它用来验证是不是这个数字证书的公钥哪里来？

具体怎么验证数字证书呢？

首先从我们一些工作经验来看，这个第三方的公钥获取一定不是通过网络获取的，我们平时使用微信，支付宝等一些大厂的接口及的时候只是部署过数字证书或者更新过数字证书，但是验证它的公钥从来没有管过。那么它在哪儿？答案在本地。

本地指的就是系统或者浏览器会维护一个权威的第三方机构列表，其中就有它们的公钥。一个简单的数字证书的制作过程和验证过程如下：

名词更正？

上述一些名词都是我们自己构造的。那么证书其实就是HTTPS数字证书，证书编号就是数字签名。第三方机构就是数字证书签发机构（CA）。

有了数字证书和数字签名的保证我们就可以保证上述服务端到客户端A1，A2，A3的通信是安全的。这样就解决了客户端到服务端和服务端到客户端通信的安全。（其实上述一大堆的分析就是解决了如何安全的协商出一个对称加密算法）

以上都是我们自己去尝试分析HTTPS产生的过程，不代表真正的一个过程。注意下，可以帮助理解。

通信图？

图的话我从网上直接copy了一张。

上述的分析都是我们自己假象来分析的，上述的图应该就是真正HTTPS的通信流程，我们再来理解一下：

1.访问网站。

2.服务端准备一套数字证书：其实就是网站的公私钥。

3.传送证书给客户端：这个证书其实就充当我们上面分析的网站的公钥。

4.客户端解析证书：解析的时候需要验证数字签名（这个数字签名就是颁发机构的私钥对网站的公钥进行加密）。浏览器此时会从本地找颁发机构的公钥用来解析数字签名，验证合法性。

5.客户端解析成功后：会用证书（网站的公钥）生成一段随机值，然后传送给服务端，然后服务端和客户端就能通过对称加密算法来解析数据了。

6.服务端解密信息：服务端利用网站的私钥进行随机值的解密，至此，SSL中利用非对称加密实现了身份验证和对称秘钥协商的过程。

7.服务端利用随机值加密数据，传输给客户端。

8.客户端利用随机值来解密刚刚服务端返回的数据。至此，一个对称加密过程结束。

参考文章：

HTTPS分析