目录
前言
一、HTTPS协议
1、加密是什么
2、为什么要加密
二、常见加密方式
1、对称加密
2、非对称加密
三、数据摘要与数据指纹
1、数据摘要
2、数据指纹
四、HTTPS加密策略探究
1、只使用对称加密
2、只使用非对称加密
3、双方都使用非对称加密
4、对称加密+非对称加密
5、知识补充
(1)CA证书
(2)证书形成过程
(3)验证证书的过程
6、证书认证+对称加密+非对称加密
7、常见问题
(1)中间人有没有可能篡改证书
(2)中间人有没有可能掉包整个证书
(3)为什么CA形成证书时要形成数字签名
(4)为什么不直接将数据进行加密,而是先进行哈希散列
前言
本章主要介绍关于HTTPS协议,以及HTTPS协议加密解密整个过程,这也是面试中常考的一个话题,接下来我们一起进入网络的世界吧!
一、HTTPS协议
HTTPS协议仅仅只是在HTTP协议上增加了一个加密层,可以说HTTPS协议是HTTP协议的升级版;
1、加密是什么
所谓加密就是将HTTP报文通过某种手段,由明文变为密文,比如我们之前可能都做过一道题目;如何不创建变量来交换两个整型;如有下面两个变量;
int a = 10;
int b = 20;
可能在没有学习异或运算符前,这题确实很困难,但是在我们学习完异或运算符后,可以巧妙利用异或运算符的特性来解决这道题目;异或运算符有如下特性;
a ^ a = 0;
a ^ 0 = a;
利用如上特性,我们不难解出上题;
a = a ^ b; ---> int c = a ^ b;
b = a ^ b; ---> b = c ^ b -> a ^ b ^ b;
a = a ^ b; ---> a = c ^ c ^ b;
我们可以将上面a与b异或的结果看作一个加密过程;只有通过特定的解密才可得到真正的结果;
2、为什么要加密
前面我们提过,HTTP协议无论是通过GET请求提交参数或是POST请求提交参数都可能会被别看看到;因为它们是明文显示的,这会造成私人信息泄漏的风险;除了私人信息泄漏风险,同时在互联网早期时,经常由于HTTP协议的不私密导致,用户在发送HTTP请求时,在传输过程中,可能遇到中间人,这个中间人可能会篡改HTTP请求内容;导致出现各种情况,如我们在网上发送一个下载QQ音乐的请求,可能会被运营商等中间人劫持,给我们发送一个下来网易云音乐的连接,而普通用户并无法区分连接,一股脑下载后发现下载的是另一个软件,这种类似问题频频出现,因此我们必须给我们的HTTP请求进行加密,所以HTTPS协议因此诞生了;
二、常见加密方式
1、对称加密
所谓对称加密就是采用单密钥的方式生成一对密钥对,其中的每一个密钥都可以进行加密与解密的操作;
特点:算法公开、计算量小、加密速度快、效率高;
常见对称加密算法:DES、RC2等
2、非对称加密
这种通常需要两个密钥来进行加密解密,其中这两个密钥一把叫做公钥,这把密钥是可以被公开的,另一把叫私钥,这把密钥通常私密保存;
特点:算法强度复杂、加密解密速度对比对称加密慢很多;
公钥加密只能通过私钥解密
私钥加密只能通过公钥解密
三、数据摘要与数据指纹
1、数据摘要
所谓数据摘要指的是将数据通过单散列哈希函数生成一串固定长度的字符串,我们称其为数据摘要;
特点:唯一性很强,通常不会发生冲突;
数据摘要 VS 加密
数据摘要是单向的,无法逆向还原原数据;而加密可以通过解密来进行还原原数据;
2、数据指纹
数据指纹指的是将我们的数据摘要再次进行加密,形成的便是数据指纹,也可以称作数字签名;
四、HTTPS加密策略探究
1、只使用对称加密
如果通信双方各持有一对密钥X,双方即可通过密钥X来进行通信;
看着似乎合理,双方各持有一个密钥,客户端发送前将hello通过密钥X加密成加密报文,然后服务端收到加密报文后将加密报文通过X进行解密成hello;
那么问题来了,如何让双方看到同一对密钥呢?通过服务端生成后发送给客户端吗?那样在发送密钥时也可能被截获吗?截获后双方又不就不是加密通信了吗?那样不就又回到了最开始的问题吗?因此这种方案显然是不行的;
2、只使用非对称加密
若只使用非对称加密策略,此时假设我们服务端生成一把公钥Y和一把私钥X;
当我们将公钥Y通过网络发送给客户端后,公钥Y不怕被别人截获,此时客户端可通过公钥Y进行加密,通过公钥Y发送的信息只能由私钥X来进行解密,因此即使中间人得到了公钥Y也无法进行解密,这样看起来好像很合理,实际上漏洞百出;
我们如何保证服务端到客户端的安全呢?这种只使用非对称加密的方式显然只能保证一端的安全性;
3、双方都使用非对称加密
若双方都拥有一对非对称密钥对,如客户端拥有公钥X与私钥X',服务端拥有公钥Y与私钥Y'。
客户端和服务端分别把自己的公钥给对方,自己持有私钥,此时每次进行通信时使用对端的公钥进行加密,由于中间人没有双反私钥,因此此时无法获取双方加密密文了;这种方案看着似乎也可以,实际上也存在漏洞;上面的安全通信假设都是建立在双方已经建立好安全通信的准备了;若是双方在交换公钥时,中间人就已经开始出手了呢?关于这个我们后面再继续讲解中间人是如何进行攻击的。
4、对称加密+非对称加密
假设服务端拥有一对非对称密钥,公钥X与私钥X’,客户端拥有对称密钥Y;
当服务端将公钥X传输给客户端时,客户端将自己的对称密钥Y经过公钥X进行加密,发送给服务端,服务端收到后用自己的私钥X‘对客户端的对称密钥进行解密,此后双方使用对称密钥Y进行通信;
这种方案看起来似乎也没有多大问题,可这一切都建立在双方已经成功建立好加密通信信道后,若是在它们交换密钥过程中同样也会出现问题,就如同上面那种情况一样,关于如何破解,同样,我们将在下面进行介绍;
当服务端将自己的公钥X发送给服务端时,被中间人劫持,获得了公钥X,并且中间人也生成一对非对称密钥对,将公钥Z给客户端,此时客户端并不知道这个公钥Z是来自中间人的,他认为他收到了来自服务端的公钥Z,因此他将自己的对称密钥Y通过公钥Z进行加密,并发送给服务端,此时也被中间人劫持,并用自己的私钥Z‘对其进行解密,得到了客户端的对称密钥Y,然后中间人还将Y用服务端的公钥X进行加密,发送给服务端,服务端也不知道这个来自于中间人,也对其进行解密得到了客户端的对称密钥Y,此后它们通过对称密钥Y进行通信时,由于中间人也有对称密钥Y,此时它们之间的通信都可以被中间人轻松获取,这样就破解了上述方式,第三种加密方式也可以通过该方法进行破解;
5、知识补充
(1)CA证书
服务端使用HTTPS协议前都需要向CA机构申请一份CA证书,证书就像身份证具有权威性;证书中里最少包含如下信息
(1)证书发布机构
(2)证书有效期
(3)公钥
(4)证书所有者
(5)签名
(6)域名
等等信息
(2)证书形成过程
公司想要CA证书需要向CA机构提交申请资料,CA机构会拿公司提供的资料的原文件内容经过哈希散列形成数据摘要,再拿数据摘要使用CA私钥进行加密形成数字签名,最后拿数字签名和证书资料合起来,变成了我们一份完整的证书;
(3)验证证书的过程
如何验证一份证书是否合法呢?如下所示;
我们拿到一份证书后,取出其数据部分,使用CA同样的哈希函数进行散列形成数据摘要,然后拿着数字签名使用CA的公钥进行解密,也得到一份数据摘要,如果这两份数据摘要相同则表示这份证书没有任何问题;因此若是对证书中的信息进行任何修改,得到的两个数据摘要都不会相同;
6、证书认证+对称加密+非对称加密
这种加密策略也就是HTTPS采用的加密策略,
首先需要服务端向CA机构申请CA证书,得到CA证书后,每次有客户端发送连接请求时,服务端首先都会给客户端发送一份自己的证书,客户端拿到证书后,对证书进行验证,若验证通过,客户端会取出证书中数据,如域名、服务端公钥等,若域名与我要访问的服务端域名匹配,说明证书没有被完整掉包过,然后生成自己的一对对称密钥,然后用服务端的公钥对对称密钥进行加密,接着将加密报文发送给服务端,由于只有服务端有私钥,因此只有服务端可以获得客户端的对称密钥,服务端获得客户端的对称密钥后,双方就可以使用这个对称密钥进行后续的通信了;
7、常见问题
(1)中间人有没有可能篡改证书
若篡改证书数据内容,在验证证书合法性时,由于数据被修改,形成的数据摘要与数字指纹形成的数据摘要不同,因此可以判断出证书不合法;
又由于中间人没有CA机构的私钥,因此也不可能再用修改后的数据形成一份数字指纹,因为大家都只使用CA机构的公钥,而私钥和公钥是配对的,因此中间人也不可能在生成一份修改数据后的数字指纹;
(2)中间人有没有可能掉包整个证书
若中间人也想CA机构申请了一份证书,在服务端发送证书给客户端时,中间人直接掉包整个证书,此时客户端在验证证书时,发现证书数据中的域名与自己访问的域名不一致,也会发现有问题,因此防止了中间人掉包整个证书的可能;
(3)为什么CA形成证书时要形成数字签名
数字签名是为了防止中间人对数据进行篡改,若没有数字签名验证,中间人可以修改证书中的数据,此时客户端收到证书后,也不知道证书内容是否被修改,证书内的公钥一旦被修改,又回到了之前的问题了;形成数字签名可以确保服务端提供公钥的合法性;
(4)为什么不直接将数据进行加密,而是先进行哈希散列
因为哈希散列后的数据大小是固定的,这样可以大大减小签名密文的长度,加快验证数字签名的运算速度;