我们本文主要来介绍https,主要来介绍https的加密原理。
大家应该都知道http和https的区别,区别很简单,主要就是在https是采用了加密协议的,而http完全是在网络上裸奔的。而我们现在几乎所有的连接都用的是https
我们首先需要明白的是,我们现阶段的加密,本质上,是在应用层和传输层之间进行加密的。加密的算法有很多,比如SSL/TLS等。
![](https://i-blog.csdnimg.cn/blog_migrate/7b5e57069684621b193f3978e27df444.png)
为了防止报文在传输的过程中被别人劫走而造成信息泄露,我们想出了一系列加密、认证的方式。
我们循序渐进,一级一级来讲解。
对称加密和非对称加密
对称加密:加密和解密用的是同一个密码或者同一套逻辑的加密方式。常见的对称加密算法有DES,AES,3DES等等。.
非对称加密就不是同一个。所以实际上是否对称即加密和解密的密钥是不是同一个。常见的非对称加密算法:RSA,ECC
我们一般称加密或者解密的为密钥。
在对称加密中,加密和解密用的是同一个密钥;
而在非对称加密中,加密和解密用的不是同一个密钥。有公钥(public key)和私钥(private key)之分。一般一个用于加密,另一个 用于解密。
一代目
一般情况下,由于非对称加密比较复杂,所以自然效率就没有对称加密高。也就是说,我们在https报文传输的时候,采用的都是对称加密。
这样即存在这样一种情形了:
如果服务器和客户端都有这样一个密钥,那么对于一个报文(不论其是Request还是Response),我在一端用密钥将此报文加密,在另一端将此密钥解密。
这样的话,我是不是就达到了数据加密的目的了呢?因为这样的话,即便别人拿到了我的报文,也做不了什么事情。因为它是加密的。别人没有我的密钥,就无法解密,得到的只能是加密后的数据。而我的密钥是不会发送到网络上传输的,所以密钥是安全的,一般别人也是得不到的。
这样有没有道理?很有道理。
那这样就行了吗?当然不是。
有没有想过一个问题:这样密钥是从哪里来的?最一开始传输的时候,比如从Cilent发送有一个Request给Server,那服务器怎么知道你的密钥是什么?你的密钥是由哈希算法随机生成的,而且你的密钥在传输的时候是不会放在网络上的(要不然别人拿到了你的密钥,不就相当于没有加密了么)。
那现在就有一个问题了。在第一次传输的时候,对方怎么知道你的密钥是什么?
这就需要结合着非对称加密来进行了。
二代目
于是,就衍生出了非对称加密的方式:公钥和私钥。
通常情况,公钥是用来进行加密的,私钥是用来解密的。
第一次,我们进行非对称加密:
加密和解密使用不同的秘钥,一把作为公开的公钥,另一把作为私钥。公钥加密的信息,只有私钥才能解密。私钥加密的信息,只有公钥才能解密。
这样的话,我们先将我们刚刚的C/S模型加密通信的模型再来模拟一下:
1. 服务端计算出一对秘钥public/private。将私钥保密,将公钥公开。(注意这里的公钥是公开的)
2. 客户端请求服务端时,拿到服务端的公钥public。
3. 客户端通过AES或者其他加密算法计算出一个对称加密的秘钥XY(注意,这里的密钥一般来说是随机生成的字符串)。 然后使用公钥将XY进行加密。
---这里即使被黑客劫持也没有用,因为黑客拿不到私钥,无法加密。所以只能拿到被加密后的密钥,拿不到密钥
4. 客户端将加密后的密文发送给服务端。服务端通过私钥解密获得XY。
5. 这个时候,客户端有了这个XY,服务端也有了这个XY,然后两边的通讯内容就通过对称密钥X以对称加密算法来加解密。
图示一下:
三代目
现在就万事大吉了吗?解决一切问题了?
nonono
思考这样一种情况:
当服务器给客户端发送公钥的时候,被我(黑客)劫持。
然后我将我自己的公钥发送给客户端,这个时候,客户端就会拿着我的这个公钥
来对自己的对称密钥x进行加密。在回来的过程中,再被我劫持。
这个时候,由于客户端是用我的公钥来进行加密的,而我自然也有自己的一份对应公钥的私钥来进行解密。这样,客户端的对称密钥x就被我拿到了,那么他所有发送的数据我也就都拿到了。然后又由于我自己也相当于一台服务器,所以我可以继续给服务器发回用服务器公钥加密密钥x的密钥。这样,我便神不知鬼不觉地获得了客户端发送的信息。
注意到,这里同时还存在一个问题:我作为中间者,我有可能将中间的信息篡改。举个例子:client->server 小花我爱你 ,server->client 小明我也很爱你
我很不爽,从中间截获之后,将server->client改为小明我不爱你,滚吧
那这岂不是凉凉了?
那该怎么办呢?这样的问题有解决的方式吗?
实际上,我们主要解决两个问题就可以了。一个是远端服务器的身份认证问题;还有一个中间信息被篡改的问题。
如何解决身份认证问题?
我们引入CA证书这么一个概念
证书里面包含的内容(至少):
- 网站域名
- 证书持有者
- 证书有效期
- 证书颁发机构
- 服务器公钥(最主要)
- 接下来要说的签名时用的hash算法
简而言之,证书的作用就是为了证明这个公钥是你想要连的服务器的,不是我黑客的。
所以,这个证书可以理解为就是公钥+一串东西
那证书如何安全的送达给浏览器,如何防止被篡改呢?给证书盖个章(防伪标记)不就好了,这就又引出另外一个概念:数字签名
签名的过程其实也很简单:
- CA机构拥有非对称加密的公钥
- CA对证书明文信息进行hash
- 对hash后的值用CA私钥加密,得到数字签名
所以呢,另一种方式总结一下:CA机构颁发的证书包含证书内容的明文(公钥等)+签名
我们通过这样一个东西,实际上能把上面两个问题一块给解决了。(具体解决的过程讲解如下:)
大家知道,私钥签名,公钥验签。证书里面的签名是CA机构用私钥签名的,所以我只要用CA机构的公钥验证一下签名不就好了,怎么验证呢?
- 拿到证书里面明文的hash算法并对明文内容进行hash运算,得到A
- 用CA的公钥解密签名得到B
- 比较A 和 B,如果相等,说明没有被篡改,否则浏览器提示证书不可信
那么总结一下,整个过程:
1、服务器给客户端发数据的时候先发一个证书。
2、客户端拿到证书里的明文和哈希算法,然后用该哈希算法对明文进行哈希,得到数据a。
3、用自己浏览器中内置的CA公钥对签名进行解密,得到数据b。
4、如果a == b,则证明证书合法有效,公钥是合法未被篡改过的。
5、客户端将自己的密钥c用服务器的公钥加密,发送给服务器。
6、服务器用自己的私钥对其进行解密,拿到密钥c。
7、双方通过密钥c进行对称加密传输。
注意点出来的是,CA私钥自始至终都没有在网络中传输,它是用来加密CA证书的(即得到CA签名),而CA公钥本身就包含在证书中,其是公开的,所以不用担心泄露的问题。如果CA证书被黑客劫持,是没有用的,因为它拿到了证书,实际上也只是拿到了这样一个签名,对于黑客来说,也是只能验证对方的身份,没有用。而证书本身黑客是伪造不了的(因为证书是由正规的政府机构颁发授予的)。
所以这样子的话,就相对来说,整个传输过程就是比较安全的了。
更多的内容,也可以参考参考这两篇内容,写的也挺不错(拓展视野了):
CA证书扫盲,https讲解。 - handsomeBoys - 博客园 (cnblogs.com)
HTTPS 建立连接的详细过程 - cccc_hi - 博客园 (cnblogs.com)
原创不易,如果觉得写的不错,就点个赞呗~~~笔芯~~~~