目录

🐼今日良言:心无旁骛 万事可破

🐳一、HTTPS协议介绍

🐳二、HTTPS协议的加密流程

🐼今日良言:心无旁骛 万事可破

🐳一、HTTPS协议介绍

 HTTPS (Hyper Text Transfer Protocol over SecureSocket Layer),超文本传输安全协议.

HTTPS 也是一个应用层协议,是在HTTP协议的基础上引入了一个加密层(SSL/TLS协议).

SSL/TLS 协议最初叫做SSL协议.SSL是一种安全套接层协议，是用来加密的协议,是Web浏览器与Web服务器之间安全交换信息的协议，提供两个基本的安全服务：鉴别与保密。

SSL协议共推出了3个版本:SSL1.0  SSL2.0  SSL3.0

由于1.0 和 2.0版本的SSL协议存在严重问题,这两个版本逐渐被SSL3.0版本所替代,后来ETF组织将SSL3.0协议进行了标准化,就成了TLS协议.不过,由于SSL3.0和TLS之间存在加密算法上的差异,因此不能互相操作.

人们将这两个协议统称为SSL/TLS协议.

提到HTTPS协议,不得不提臭名昭著的"运营商劫持":

下载一个天天动听音乐播放器:

没有被劫持的情况:点击下载,就会弹出天天动听的下载链接.

 被劫持的情况:点击下载,弹出别的下载链接.

由于HTTP协议是明文传输,任何数据报都会经过运营商的网络设备(交换机/路由器),因此,运营商的网络设备就可以解析出传输的 数据内容,然后进行篡改.

点击下载按钮,其实就是给服务器发送一个HTTP请求,获取到的HTTP响应就包含了该APP的下载链接.运营商劫持以后,就会将这个APP的下载链接给篡改成下载"QQ浏览器"的链接.

为什么会发生运营商劫持呢?

假如用户在搜狗浏览器中输入:不孕不育,然后搜索,结果如下:

 当用户点击广告之后,就会跳转到广告对应网站,此时,广告主就要给搜狗这个平台发广告费.

广告主的这个广告可能投放了很多个平台,于是,本来是来自搜狗的http请求,被运营商劫持以后,运营商篡改http请求中的内容,将用户跳转界面由搜狗改为自己,然后广告主就会给运营商发广告费.

由于运营商劫持太过猖獗,于是https应运而生.

🐳二、HTTPS协议的加密流程

通过前面介绍,会发现:在互联网上,明文传输是非常危险的.

所以说需要保证用户的信息安全,对传输的数据进行"加密".

加密就是把 明文 ( 要传输的信息 ) 进行一系列变换 , 生成 密文 .

解密就是把 密文 再进行一系列变换 , 还原成 明文 .

在这个加密和解密的过程中 , 往往需要一个或者多个中间的数据 , 辅助进行这个过程 , 这样的数据称为 密钥

明文  ---> 密文     加密

密文  ---> 明文     解密

是一种最简单有效的加密办法.

同一个密钥既可以用来加密,也可以用来解密,称为"对称密钥".

a(明文) + key(对称密钥)  ---> b(密文)

b(密文) + key(对称密钥)  ---> a (密文)   

对称密钥可以认为是一串数字/字符串.加密的过程,就是把明文和字符串进行一系列的数学变换(其中最简单的就是 ^)

对称加密安全的前提是:密钥不能被黑客知道

 由于黑客不知道密钥是什么,即使黑客截获了加密的数据,也不知道是什么.

对称密钥首先要让客户端和服务器都拿到.

假设客户端生成一个对称密钥,客户端就需要将密钥告诉服务器:

 客户端生成密钥,然后发给服务器:

由于密钥刚刚生成,服务器还不知道,所以需要明文传输,将密钥告诉服务器,但是明文传输就很容易被黑客截获密钥.

所以说,如何安全的将对称密钥传输过去呢?

使用非对称加密

服务器生成一对密钥:公钥和私钥.

明文 + 公钥  ---> 密文    使用公钥加密

密文 + 私钥  ---> 明文    使用私钥解密

公钥可以是公开的,私钥不公开(私藏)

假设服务器生成了一对公钥和私钥,客户端已经持有公钥,服务器持有私钥:

 黑客入侵网络设备后,拿到服务器的公钥(和客户端持有的公钥一样),但是黑客不知道私钥,私钥只有服务器有.

客户端通过公钥对请求加密(对称密钥使用aaabbb行,黑客即使截获了这个请求,但是没有私钥,无法解密这个请求,然后当请求到达服务器以后,服务器使用私钥对这个请求进行解密,得到了对称密钥,后续操作都使用对称密钥进行加密.

非对称密钥只用来传输对称密钥,一旦服务器拿到对称密钥后,后续的传输都使用对称密钥来加密了.

为什么有了非对称加密,还要保留对称加密呢?全部使用非对称加密不可以吗?

不行,因为对称加密速度快,非对称加密速度慢,需要尽可能提高整体的速度.

了解了上述流程,看似好像已经天衣无缝了,整个加密已经完成,传输非常的安全,但是,实际上并非这样,传输过程还是不够安全,信息还是会被黑客截获,这就不得不引入"中间人攻击"问题.

什么是中间人攻击问题呢?

之前有部电影<毒战>:

 电影情节大概如下,有一个警察:C,一个犯罪分子:D,两个毒枭: A  B.

D 被 C 抓捕以后,供出了 A 和 B要见面,但是 A 和 B 互相不认识,A 和 B 都只认识 C,于是,D先伪装成A带着 C 去见B,然后 D 又伪装成 B带着 C 去见A,最后将A 和 B以及背后的集团都一网打尽了.

这里的 D 就是中间人,通过扮演A 和 B的角色,最后完成了任务.

假设服务器生成一对公钥(pub1) 和 私钥(pri1),然后客户端向服务器发送请求,获取公钥,但是这个请求被黑客截获了:

 黑客这里也生成了一对公钥(pub2) 和 私钥(pri2)

 当请求到达服务器以后,服务器返回响应(公钥 pub1),但是这个响应被黑客截获了,黑客篡改了响应内容,将服务器的公钥(pub1) 修改为自己的公钥(pub2),同时保存了服务器的公钥(pub1):

此时,站在客户端角度来看,不知道拿到的这个公钥(pub2)是被黑客篡改后的公钥,然后客户端使用公钥(pub2) 来对生成的对称密钥进行加密传输.

当客户端的这个请求被黑客截获以后,黑客使用自己的私钥(pri2)对内容进行解密,拿到对称密钥key,然后使用之前保存下的服务器的公钥(pub1)来对内容进行重新加密,再将篡改后的请求发给服务器.

 此时,黑客和服务器都知道了对称密钥key,接下来,只要是通过对称密钥加密的内容,黑客截获以后使用对称密钥key解密以后,就可以进行篡改.

上述就是中间人攻击问题.

解决中间人攻击的关键,就在于让客户端客户端能够分辨收到的公钥是不是服务器真实的公钥.

具体解决方案:引入一个"证书"(本质上是引入第三方的公证机构)

服务器(网站)在设立之初,就需要去专门的认证机构,申请证书(需要服务器提供一些资质,包括自己生成的公钥),当审核通过以后,就会给服务器颁发一个证书(包含服务器生成的公钥):

 此时,服务器就是一个有证书的服务器了,然后客户端向服务器发送请求就不再是只申请服务器的公钥了,而是申请整个证书.

 客户端拿到证书以后,就可以对证书进行校验.

证书上面会带有一个特定的字段,叫做证书的签名.

认证机构也有一对公钥和私钥,私钥用来加密hash值得到签名了,客户端可以使用使用公钥解密签名获取hash值.

假设证书包含的的属性如下:

 客户端使用认证机构提供的公钥对这个加密的字符串进行解密,得到的结果相当于是一个hash值(类似于tcp udp 里的校验和,根据证书的其它字段综合计算出来的结果),将这个值设为hash1.

客户端可以使用相同的hash算法,针对其它的字段再算一次hash值,将这个值设为hash2,然后客户端比较 hash1 和 hash2 是不是值相同,如果相同,说明证书是有效的,如果不同,说明证书被篡改过.

黑客如果将证书给篡改了,比如:将服务器的公钥替换了,这就意味着客户端算出来的hash2 和 签名解密出来的 hash1 值就不同了,客户端就知道了这个证书无效.

由于黑客不知道认证机构的私钥,即使黑客算好了新的篡改后的hash 值,也无法加密生成签名.

然后客户端就可以使用这个证书中服务器的公钥对要传输的对称密钥进行加密,请求到达服务器以后,服务器进行解密,得到对称密钥,后续操作就可以使用对称密钥进行加密.

这样就保证了信息传输的安全性.

以上就是HTTP协议的加密流程了.