https

Wed, 02 Oct 2024 00:00:00 +0800

阅读本文之前，咱们先来看几道面试题:

什么是HTTPS？
HTTPS改进HTTP存在的哪些问题？
HTTPS加密原理是什么？
什么是对称加密和非对称加密？
HTTPS传输过程?
什么是数字证书？为什么需要数字证书?
为什么需要数字签名？

…

如果你能准确无误的回答以上问题，你可以不用继续往下面看了，如果不能，通过阅读这篇文章，我相信你肯定能完全掌握HTTPS。好了废话不多说，我们开始。

什么是 HTTPS

当我们在访问一个地址采用HTTPS协议的Web网站时，浏览器的地址栏内会出现一个带锁的标记，就像这样：

我们想要了解一个东西之前，我们得先知道它是什么，那么HTTPS是什么呢？

可能很多同学都能说道说道：“HTTPS就是能够给我们的请求加密的一个东西”。的确，我们都知道，HTTPS可以加密，但是很多同学的理解仅限于此，无法深层次的理解HTTPS。那么到底什么是HTTPS？

HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版。说得再简单一点，HTTPS就是 HTTP + SSL:

哦明白了，原来HTTPS就是“披着羊皮的狼”啊。HTTP你肯定是理解的，如果不理解，建议先去阅读HTTP相关知识。

那SSL又是什么呢？

我们都知道，HTTP是应用层的协议，HTTP是直接和TCP通信的，当我们更换为HTTPS的时候，它就演变成了，先和SSL通信、然后再由SSL和TCP通信了。知道了这一流程，我们思考一下，加密过程是在哪个过程进行的？结果很显然，加密过程就是在HTTP->SSL这一阶段实现的，所以SSL简单来说，就是实现HTTP的加密过程:

对称加密和非对称加密、散列函数这些又是啥啊？没事后面会讲，这些概念你先记住咯。

HTTPS 有什么用

在讲明HTTPS的作用之前，我们先来看看HTTP有哪些弊端：

和服务器通信时，直接采用明文传输，那么明文内容有可能被挟持监听和篡改

由于HTTP本身不具备加密的功能，所以无法做到对通信内容进行加密。也就是说，我们传输的方式，都是直接以明文的形式进行传输，这些明文数据会经过中间代理服务器、路由器、wifi热点、通信服务运营商等多个物理节点，相当于所有通信的数据都在网络中裸奔，想想都刺激。

那么显而易见，明文传输有什么缺陷呢？明文传输可能会导致数据泄露、数据篡改、流量劫持、钓鱼攻击等一系列危险。假设有这么一个场景，某一天，你的另一个女朋友过生日，于是你用浏览器登录了你的邮箱，想给她发送一封生日祝福的邮件。假如这个邮箱网站使用的是HTTP协议，当你点击发送的时候，你的“祝福内容”（注意：是明文），被某个黑客拦截到，然后将这份“祝福内容”直接转发到你的“现任女朋友”，那后果简直不堪设想。

和服务器通信时，无法验证身份

使用HTTP发起请求时，服务器不会验证请求方的身份，响应请求时，请求方也不会验证服务方的身份。说简单点就是，任何人都可以发起请求，同时，服务器只要接收到请求，不管对方是谁都会返回一个响应。所以任何人都可以伪造虚假服务器欺骗用户，实现“钓鱼欺诈”，用户无法察觉，这也是为啥以前我们的qq号老是被盗的原因。

了解到HTTP这些缺陷之后，我们就自然知道了HTTPS到底有什么用：

保证数据的安全性（加密我们的明文数据）
保证数据的完整性
身份认证

HTTPS如何加密（SSL过程）

通过上面的内容，我们知道了HTTPS能够对数据进行加密，那么它具体是如何加密的呢？

这里我们需要先了解两种加密方式：

对称加密
非对称加密

别觉得它们会有多么难理解，心中坚信，一切计算机网络的知识都是纸老虎。

什么是对称加密

那么什么是对称加密呢？

简单说就是有一个密钥，它可以加密数据，也可以对加密后的数据进行解密。试想有这样一个场景：两个港口需要运送一批货物，发货方发货时，将货物装进集装箱并用一把锁将集装箱锁起来，收货方收到货物时，需要用同样的钥匙（不一定是同一把）将集装箱打开，从而取出货物。

所以简单来说，对称加密就是通信双方都有一把同样的钥匙，用于打开同一个集装箱（解密），从而获取数据的一种方式:

HTTPS用对称加密可行吗

如果通信双方（浏览器和服务器）都各自拥有同样的私钥，在发送方发送数据之前，将数据锁（加密）起来，然后接收方再用私钥解锁（解密），这样就能完美的保证通信的安全。但是关键的问题就在于，在通信之前，服务器或者浏览器如何同时拥有一把同样的私钥呢？我们来想想办法：

1、服务器给浏览器传输私钥

当浏览器发起请求到服务器时，服务器生成一个私钥，然后传输给浏览器，浏览器拿到之后，他们正式通信就开始用这一个私钥进行加密通信，不就行了？那么问题又来了，假设在传输私钥本身的过程中，被中间人挟持了怎么办？中间人拿到私钥之后，就可以解密通信双方的加密内容了，所以这样做肯定是不可行的。

2、在浏览器里面预留服务器提供的私钥。如果我们浏览器一开始就预留了目标网站的私钥，那这样通信的时候，就只有天知地知你知我知了，这不就行了？但是问题的关键是，世界上的网站千千万，浏览器要预留全部HTTPS协议网站的私钥，这显然不可能啊。

很显然，以上两种假设，都不能实现我们想要的加密效果，所以对称加密暂时被我们 pass.

什么是非对称加密

既然对称加密不行，那么我们就需要考虑非对称加密了，那非对称加密又是什么呢？

我们还是来看看还是刚刚上面👆那个运送货物的例子：

两个港口需要运送一批货物，发货方发货时，将货物装进集装箱并用一把锁（我们将其称为公钥）将集装箱锁起来，收货方收到货物时，需要用另外一把钥匙（我们将其称为私钥）将集装箱打开，从而取出货物。

注意这里的关键是：当通信的一方使用公钥时，另外一方只能使用私钥，反之亦然。

简单的来说就是有两把密钥，一把叫做公钥、一把叫私钥。用公钥加密的内容必须用私钥才能解开，同理，私钥加密的内容只有公钥能解开。公钥对于私钥来说是非对称的，所以我们把这种加密方式称为非对称加密：

HTTPS用非对称加密可行吗

我们利用非对称加密来模拟一下浏览器和服务器通信的过程。

浏览器向服务器发起请求，服务器收到请求之后，将公钥传输给浏览器，然后在接下来的通信中，浏览器要向服务器发送数据时，先用公钥将数据加密，然后发送给服务器，服务器收到之后，再用对应的私钥进行解密，这样就保证了浏览器->服务器这条路的数据安全。因为浏览器发送给服务器的数据，只有服务器有私钥能够解密它。那么反过来，服务器->浏览器这条路的通信是否安全呢？

捋一捋刚刚的过程，我们就会发现，一开始我们的服务器将公钥传输给浏览器这一步骤，显然是在明文形式下进行传输的。假设这一过程，我们的公钥被中间人挟持了，想想会发生什么情况？显然有了这个公钥，中间人就能解密由服务器利用私钥加密的数据了，虽然他不能解密浏览器端的数据，但是此时他可以伪造请求，服务器收到请求之后，利用私钥解密请求数据，之后响应请求，并用私钥对响应数据加密，接着返回给请求方，由于此时这个中间人是有对应的公钥的，所以他就能直接解密服务器返回的数据。

Https on Last Stand