什么是https（加密）协议，彻底搞懂https

Posted 2023-04-11 qzwzsl

HTTPS（SSL/TLS）是计算机网络的知识，主要用来对HTTP协议传输的文本进行加密，提高安全性的一种协议。

因为HTTP是明文传输，所以会很有可能产生中间人攻击（获取并篡改传输在客户端及服务端的信息并不被人发觉），HTTPS加密应运而生。

什么是对称加密？

简单的说，就是用一个密钥，可以对一段信息进行加密，也可以使用其本身对这段信息进行解密，这就叫做对称加密。

所以对称加密能防止中间人攻击吗？

很难。

首先，如果能做到客户端和服务端都拥有这个密钥并且没有第三者知道，那理论上对称加密是可以的，但是如何做到不可能让别人知道呢？

无论这个密钥是客户端生成发送给服务端，还是服务端生成发送给客户端，此时如果有中间人窃取了该密钥的信息，那往后传输的所谓“加密”数据，中间人也都可以将其解密并加密继续传输下去而不被人发现。

显然，本来我们就想要防范中间人攻击，而对称加密想实施的前提就是保证没有中间人窃取密钥才可以。这是不是有点像“问：我们如何将房价降下来呢？答：把房子的价格降下来，房价自然降下来”

非对称加密

简单说就是有两把密钥，一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

所以非对称加密可以防范中间人攻击吗？

鉴于非对称加密的机制，我们可能会有这种思路：服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了！因为只有服务器有相应的私钥能解开公钥加密的数据。

然而反过来由服务器到浏览器的这条路怎么保障安全？如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息了。所以目前似乎只能保证由浏览器向服务器传输数据的安全性

所以我们证明了一组公钥私钥，至少可以确保单向的数据安全，那么我可不可以合理推断如果我有两组公钥私钥，那我就可以保证双向数据传输的安全了呢？

• 某网站服务器拥有公钥A与对应的私钥A’；浏览器拥有公钥B与对应的私钥B’。
• 浏览器把公钥B明文传输给服务器。
• 服务器把公钥A明文给传输浏览器。
• 之后浏览器向服务器传输的内容都用公钥A加密，服务器收到后用私钥A’解密。由于只有服务器拥有私钥A’，所以能保证这条数据的安全。
• 同理，服务器向浏览器传输的内容都用公钥B加密，浏览器收到后用私钥B’解密。同上也可以保证这条数据的安全。

bingo！好像成功了！但是这个方法并没有被大范围推广，并且也不可能被大范围推广。很重要的原因是非对称加密算法非常耗时，而对称加密快很多。

好家伙，说来说去又回到对称加密了，合着你就非得用对称加密是吗？

对！就是要找一个方法，让客户端和服务端都知道那个公共密钥并且确保第三方不会获取，那我就是可以放心的使用对称加密传输数据了

对称加密和非对称加密的综合版本

1. 某网站拥有用于非对称加密的公钥A、私钥A’。
2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
3. 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
4. 服务器拿到后用私钥A’解密得到密钥X。
5. 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。

成功！HTTPS基本就是采用了这种方案。

但是这并不是完美的，这仍然有漏洞喔！

对称加密和非对称加密的综合版本的漏洞

如果在数据传输过程中，中间人劫持到了数据，此时他的确无法得到浏览器生成的密钥X，这个密钥本身被公钥A加密了，只有服务器才有私钥A’解开它，然而中间人却完全不需要拿到私钥A’就能干坏事了。请看：

1. 某网站有用于非对称加密的公钥A、私钥A’。
2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
3. 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
4. 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器以为是公钥A）加密后传给服务器。
5. 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
6. 服务器拿到后用私钥A’解密得到密钥X。

这样在双方都不会发现异常的情况下，中间人通过一套“狸猫换太子”的操作，掉包了服务器传来的公钥，进而得到了密钥X。根本原因是浏览器无法确认收到的公钥是不是网站自己的，因为公钥本身是明文传输的。

所以！我们只剩下最后一个问题，那就是怎么确保浏览器收到的公钥是网站的，而不是中间人的！

数字证书

网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。而这里又有一个显而易见的问题，“证书本身的传输过程中，如何防止被篡改”？即如何证明证书本身的真实性？身份证运用了一些防伪技术，而数字证书怎么防伪呢？解决这个问题我们就真的接近胜利了！

如何防止数字证书被篡改？

数字签名

简单理解就是用签名者的私钥加密一串信息，将这串信息以及这串信息的加密版以及公钥都传给客户端，客户端收到信息后用公钥解密，如果解密的结果和明文传过来的数据相符合，那自然可以证明该公钥是真的。

故事到此为止就讲完了。但是好像遗留了一点性能问题

每次发送HTTPS请求都需要在TLS/SSL层进行握手传输密钥吗？

如果是的话，那也太浪费资源和时间了吧。

服务器会为每个浏览器（或客户端软件）维护一个session ID，在TLS握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！

至此我们的故事就真的讲完了！

故事一定会有结尾，但你我却没有结果～

 

图文彻底搞懂非对称加密（公钥密钥）

参考技术A 前文详细讲解了对称加密及算法原理。那么是不是对称加密就万无一失了呢？对称加密有一个天然的缺点，就是加密方和解密方都要持有同样的密钥。你可以能会提出疑问：既然要加、解密，当然双方都要持有密钥，这有什么问题呢？别急，我们继续往下看。

我们先看一个例子，小明和小红要进行通信，但是不想被其他人知道通信的内容，所以双方决定采用对称加密的方式。他们做了下面的事情：

1、双方商定了加密和解密的算法

2、双方确定密钥

3、通信过程中采用这个密钥进行加密和解密

这是不是一个看似完美的方案？但其中有一个步骤存在漏洞！

问题出在步骤2：双方确定密钥！

你肯定会问，双方不确定密钥，后面的加、解密怎么做？

问题在于确定下来的密钥如何让双方都知道。密钥在传递过程中也是可能被盗取的！这里引出了一个经典问题：密钥配送问题。

小明和小红在商定密钥的过程中肯定会多次沟通密钥是什么。即使单方一次确定下来，也要发给对方。加密是为了保证信息传输的安全，但密钥本身也是信息，密钥的传输安全又该如何保证呢？难不成还要为密钥的传输再做一次加密？这样不就陷入了死循环？

你是不是在想，密钥即使被盗取，不还有加密算法保证信息安全吗？如果你真的有这个想法，那么赶紧复习一下上一篇文章讲的杜绝隐蔽式安全性。任何算法最终都会被破译，所以不能依赖算法的复杂度来保证安全。

小明和小红现在左右为难，想加密就要给对方发密钥，但发密钥又不能保证密钥的安全。他们应该怎么办呢？

有如下几种解决密钥配送问题的方案：

非对称加密也称为公钥密码。我更愿意用非对称加密这种叫法。因为可以体现出加密和解密使用不同的密钥。

对称加密中，我们只需要一个密钥，通信双方同时持有。而非对称加密需要4个密钥。通信双方各自准备一对公钥和私钥。其中公钥是公开的，由信息接受方提供给信息发送方。公钥用来对信息加密。私钥由信息接受方保留，用来解密。既然公钥是公开的，就不存在保密问题。也就是说非对称加密完全不存在密钥配送问题！你看，是不是完美解决了密钥配送问题？

回到刚才的例子，小明和下红经过研究发现非对称加密能解决他们通信的安全问题，于是做了下面的事情：

1、小明确定了自己的私钥 mPrivateKey，公钥 mPublicKey。自己保留私钥，将公钥mPublicKey发给了小红

2、小红确定了自己的私钥 hPrivateKey，公钥 hPublicKey。自己保留私钥，将公钥 hPublicKey 发给了小明

3、小明发送信息 “周六早10点soho T1楼下见”，并且用小红的公钥 hPublicKey 进行加密。

4、小红收到信息后用自己的私钥 hPrivateKey 进行解密。然后回复 “收到，不要迟到” 并用小明的公钥mPublicKey加密。

5、小明收到信息后用自己的私钥 mPrivateKey 进行解密。读取信息后心里暗想：还提醒我不迟到？每次迟到的都是你吧？

以上过程是一次完整的request和response。通过这个例子我们梳理出一次信息传输的非对称加、解密过程：

1、消息接收方准备好公钥和私钥

2、私钥接收方自己留存、公钥发布给消息发送方

3、消息发送方使用接收方公钥对消息进行加密

4、消息接收方用自己的私钥对消息解密

公钥只能用做数据加密。公钥加密的数据，只能用对应的私钥才能解密。这是非对称加密的核心概念。

下面我用一个更为形象的例子来帮助大家理解。

我有下图这样一个信箱。

由于我只想接收我期望与之通信的朋友信件。于是我在投递口加了一把锁，这把锁的钥匙（公钥）我可以复制n份，发给我想接受其信件的人。只有这些人可以用这把钥匙打开寄信口，把信件投入。

相信通过这个例子，可以帮助大家彻底理解公钥和私钥的概念。

RSA 是现在使用最为广泛的非对称加密算法，本节我们来简单介绍 RSA 加解密的过程。

RSA 加解密算法其实很简单：

密文=明文^E mod N

明文=密文^D mod N

RSA 算法并不会像对称加密一样，用玩魔方的方式来打乱原始信息。RSA 加、解密中使用了是同样的数 N。公钥是公开的，意味着 N 也是公开的。所以私钥也可以认为只是 D。

我们接下来看一看 N、E、D 是如何计算的。

1、求 N

首先需要准备两个很大质数 a 和 b。太小容易破解，太大计算成本太高。我们可以用 512 bit 的数字，安全性要求高的可以使用 1024，2048 bit。

N=a*b

2、求 L

L 只是生成密钥对过程中产生的数，并不参与加解密。L 是 (a-1) 和 (b-1) 的最小公倍数

3、求 E（公钥）

E 有两个限制：

1<E<

E和L的最大公约数为1

第一个条件限制了 E 的取值范围，第二个条件是为了保证有与 E 对应的解密时用到的 D。

4、求 D（私钥）

D 也有两个限制条件：

1<D<L

E*D mod L = 1

第二个条件确保密文解密时能够成功得到原来的明文。

由于原理涉及很多数学知识，这里就不展开细讲，我们只需要了解这个过程中用到这几个数字及公式。这是理解RSA 安全性的基础。

由于 N 在公钥中是公开的，那么只需要破解 D，就可以解密得到明文。

在实际使用场景中，质数 a,b 一般至少1024 bit，那么 N 的长度在 2048 bit 以上。D 的长度和 N 接近。以现在计算机的算力，暴力破解 D 是非常困难的。

公钥是公开的，也就是说 E 和 N 是公开的，那么是否可以通过 E 和 N 推断出 D 呢？

E*D mod L = 1

想要推算出 D 就需要先推算出 L。L 是 (a-1) 和 (b-1) 的最小公倍数。想知道 L 就需要知道质数 a 和 b。破解者并不知道这两个质数，想要破解也只能通过暴力破解。这和直接破解 D 的难度是一样的。

等等，N 是公开的，而 N = a*b。那么是否可以对 N 进行质因数分解求得 a 和 b 呢？好在人类还未发现高效进行质因数分解的方法，因此可以认为做质因数分解非常困难。

但是一旦某一天发现了快速做质因数分解的算法，那么 RSA 就不再安全

我们可以看出大质数 a 和 b 在 RSA 算法中的重要性。保证 a 和 b 的安全也就确保了 RSA 算法的安全性。a 和 b 是通过伪随机生成器生成的。一旦伪随机数生成器的算法有问题，导致随机性很差或者可以被推断出来。那么 RSA 的安全性将被彻底破坏。

中间人攻击指的是在通信双方的通道上，混入攻击者。他对接收方伪装成发送者，对放送放伪装成接收者。

他监听到双方发送公钥时，偷偷将消息篡改，发送自己的公钥给双方。然后自己则保存下来双方的公钥。

如此操作后，双方加密使用的都是攻击者的公钥，那么后面所有的通信，攻击者都可以在拦截后进行解密，并且篡改信息内容再用接收方公钥加密。而接收方拿到的将会是篡改后的信息。实际上，发送和接收方都是在和中间人通信。

要防范中间人，我们需要使用公钥证书。这部分内容在下一篇文章里会做介绍。

和对称加密相比较，非对称加密有如下特点：

1、非对称加密解决了密码配送问题

2、非对称加密的处理速度只有对称加密的几百分之一。不适合对很长的消息做加密。

3、1024 bit 的 RSA不应该在被新的应用使用。至少要 2048 bit 的 RSA。

RSA 解决了密码配送问题，但是效率更低。所以有些时候，根据需求可能会配合使用对称和非对称加密，形成混合密码系统，各取所长。

最后提醒大家，RSA 还可以用于签名，但要注意是私钥签名，公钥验签。发信方用自己的私钥签名，收信方用对方公钥验签。关于签名，后面的文章会再详细讲解。