"Echo"
作者:Mylvzi
文章主要内容:网络原理(5)–HTTPS是如何进行加密的
在网络原理(4)中介绍了HTTP协议的相关内容,HTTP协议在传输的过程中存在着安全问题,实际上现在的网络中基本不再使用HTTP,而是使用一种更加安全的协议HTTPS
HTTPS是基于HTTP,之前学习过的有关HTTP协议的相关内容在HTTPS上都是同样适用的,HTTPS是在HTTP的基础之上引入了加密机制
之所以会有HTTPS的出现,主要还是因为HTTP协议在传输的过程中遇到了安全问题,比如随便连接公共WiFi就有可能导致数据的丢失,黑客可以对公共WIFI所在的路由器进行抓包分析,获得你上网的一些相关信息(比如支付宝密码),甚至说黑客都可以伪装成公共WiFi的路由器
如果一些敏感数据不进行加密,就相当于数据在网络中裸奔传输,被黑客获取到就会带来风险.实际上,像支付宝密码这样的敏感数据,支付宝的官方都是进行了加密,黑客拿到的数据是加密过后的密文,黑客无法进行解密~
为了解决HTTP在传输过程中的不安全性,HTTPS中就引入了加密机制,保证数据在传输的过程中不是裸奔传输
要了解HTTPS的加密机制,需要先了解是哪个基本概念:密文,明文,密钥
明文:要传输的原始数据,比如你要发送"你好",你好这两个字就是明文
密钥:对明文加密,对密文解密的工具
密文:对明文进行密钥加密过后的数据 比如将原始数据"你好"加密为"nh","nh"就是密文,传输过程中密文在网络中进行传输
明文 + 密钥 => 密文
密文 + 密钥 =>明文
HTTPS中进行加密的机制主要有两种:对称加密和非对称加密
对称加密就是在加密的过程中使用同一把密钥进行加密解密的过程
假设密钥是 key
,那么;
明文 + key => 密文
密文 + 可以=> 明文
非对称加密就是在加密的过程中使用两把不同的密钥进行加密解密的过程,一把被称为公钥(可以被公开出来的),一把被称为私钥(自己单独享有的),使用那一把加密/解密都是相同的,比如假设公钥是key1
,私钥是key2
,使用公钥进行加密,使用私钥进行解密
明文 + key1 => 密文
密文 + key2 => 明文
HTTPS的加密主要是对HTTP报文中的头部和body进行加密
对称加密在加密解密的过程中使用的是同一把密钥进行加密解密
加密的具体过程如下:
想一个问题,服务器不是只和一个客户端进行通信,是和很多客户端进行通信,每一个客户端的对称密钥是否都相同呢?肯定是不同的,如果相同,黑客就可以作为客户端得到对称密钥,就可以利用这个对称密钥进行解密了
实际上,对称密钥是客户端再和服务器连接时就要提前产生的,这个对称密钥利用随机数的相关机制产生,保证每个客户端的对称密钥都不相同
上述机制真的没有问题么?其实存在一个致命缺陷,对称密钥是通过客户端利用随机数机制产生的,服务器也要持有相同的对称密钥,客户端通过网络传输
传输给服务器,黑客就可能把对称密钥也给截获,就可以利用截获的密钥进行解密,此时不就加密了个寂寞么?
有人可能会说,那我就对产生的对称密钥进行加密不就行了么?但是对对称密钥加密的密钥不也得通过网络传输给服务器么?这个方法肯定是行不通的,再仔细想想,对称加密存在安全问题的关键在于对称密钥是赤裸裸的在网络中进行传输的,密钥就像是秘密,秘密很关键,很重要,所以应该自己持有,不应该公布出去,这样的密钥就是私钥,这也是非对称加密的关键!
非对称加密在加密解密的过程中使用的是一套密钥,公钥和私钥进行加密解密
公钥私钥由服务器产生,公钥通过网络传输给客户端,私钥只有服务器自己持有,不在网络中进行传输,此时就可以使用公钥进行加密,使用私钥解密
加密的具体过程如下:
在这个过程中,黑客由于不持有私钥,就无法获取到对称密钥,进而无法进行解密
注意:为什么有非对称密钥了还要使用对称密钥,直接把所有的数据通过非对称密钥进行传输不行么?其实也可以,但是效率太低,成本也太高
非对称密钥由于其复杂性,在传输的过程中传输成本高,运算效率低,而对称密钥传输成本低,运算效率高,为了保证传输的效率,使用非对称密钥传输关键数据
(如密钥),剩余的大量的业务数据通过更加快速的对称密钥进行传输
可以说,非对称密钥引入安全性,必然要降低传输效率(就和TCP引入可靠性效率降低一样)
以上就是非对称加密机制保证数据传输安全的机制,核心在于:黑客不持有私钥,无法对由客户端传输过来的通过公钥加密的对称密钥进行解密
但就算这样做还是存在安全漏洞(你不得不佩服黑客):黑客要想办法能够对对称密钥
进行解密,怎么解密呢?让对称密钥的密钥不是服务器生成的公钥,自己产生一对公钥和私钥,让客户端通过自己产生的公钥对对称密钥进行加密,这样黑客就能拿到对称密钥,紧接着,再使用服务器产生的公钥对数据进行加密,传输给服务器,服务器收到数据也能解密,整个过程看起来没有被解密过,实际上被黑客瞒天过海了
,但是~服务器产生的公钥根本没有传输到客户端,而是被黑客截取了!
这种机制也被叫做"中间人攻击问题"!
整个过程黑客成功实现了瞒天过海,服务器收到经pub1加密的数据,就认为传输的过程中没有发生解密的过程,实际上黑客利用自己产生的一对密钥进行了调包
那如何解决中间人问题呢–引入公正机构
中间人问题产生的原因在于客户端没有判别能力,他不知道传输过来的公钥属于黑客还是属于服务器,第三方机构就让客户端拥有了判别能力
首先,网站的开发者在搭建网站时,生成一对服务器的公钥和私钥,并向公正机构申请一个证书,服务器需要提供一些服务器相关的数据(网站域名/服务器公钥等),公正机构根据这些信息进行审核,审核通过产生一个证书,证书不是纸质的,而是一段结构化数据
,证书内部有很多属性,比如网站域名,公钥,证书的过期时间等,其中最重要
的属性是数字签名
,数字签名是一个被加密过的校验和
,通过证书中的属性计算出一个校验和,再利用公正机构自己产生的私钥
进行加密,就得到了数字签名,这个属性,将是客户端验证公钥的关键!公正机构产生的公钥一般都是内置在客户端的操作系统之中
客户端在和服务器进行通信时,也会向服务器申请服务器的证书,证书中包含服务器产生的公钥
客户端收到传输过来的公钥(服务器产生),就可以利用数字签名来校验公钥是否被替换过,这个过程也被称作证书的校验,核心就是计算这里面的校验和
客户端利用操作系统内置的公正机构的公钥对数字签名进行解密,得到证书的校验和
,客户端重新对证书进行校验和的计算,得到一个新的校验和,将这个计算出的校验和和解密得到的校验和进行对比,如果相同,就证明服务器的公钥没有被篡改,证书是可信的
如果黑客使用自己的公钥替换了服务器的公钥,那么客户端计算出的校验和就会解密出的校验和不一致,此时就会警告客户端(往往是弹出一个小框,显示有风险)
同时,黑客也无法修改证书之中的数字签名,数字签名的解密需要通过公正机构的公钥,但是这个公钥是客户端操作系统内置的,黑客无法获取
那黑客不能自己申请一个证书么?不能,如果要申请证书,就要向公正机构提供服务器的域名和持有者信息,黑客不是服务器的持有者,从而就无法申请证书
上述就是HTTPS加密的整个过程,看得出来攻击和防御
是"相辅相成"的,网络安全在现在也是一个巨大的挑战!
总结:HTTPS的加密
以上就是<<网络原理(5)–HTTPS是如何进行加密的>>的所有内容,至此,网络原理章节完结撒花!