目录
1、概念准备
1.1、HTTPS是什么
1.2、什么是加密
1.3、为什么要进行加密
1.4、常见的加密方式
对称加密
非对称加密
1.5、数据摘要&&数据指纹
1.6、数字签名
2、HTTPS的工作过程探究
2.1、方案1 - 只使用对称加密
2.2、方案2 - 只使用非对称加密
2.3、方案三 - 双方都使用非对称加密
2.4、方案四 - 非对称加密 + 对称加密
2.5、引入证书
CA认证
理解数据签名
2.6、方案5 - 非对称加密 + 对称加密 + 证书认证
客户端进行认证
中间人有没有可能篡改该证书?
中间人整个掉包证书?
2.7、完整流程
1、概念准备
1.1、HTTPS是什么
HTTPS也是一个应用层协议,是在HTTP协议的基础上引入了一个加密层。
HTTP协议内容都是按照文本的方式明文传输的,这就导致在传输过程中出现一些被篡改的情况。
1.2、什么是加密
加密就是把明文(要传输的信息)进行一系列变换,生成密文。
解密就是把密文再进行一系列变换,还原成明文。
在这个加密和解密的过程中,往往需要一个或者多个中间的数据,辅助进行这个过程,这样的数据称为秘钥。
1.3、为什么要进行加密
相信我们在下载软件时都遇到过的一个事情,就是我明明点击的是网易云音乐的下载,怎么变成了qq浏览器?这就是臭名昭著的运营商劫持。
由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器,交换机等),那么运营的网络设备就可以解析出你传输的数据内容,并进行篡改。
点击“下载按钮”,其实就是在给服务器发送了一个HTTP请求,获取到的HTTP响应其实就包含了该APP的下载链接。运营商劫持之后,就发现这个请求是要下载网易云音乐,那么就自动的把用户的响应给篡改成了“qq浏览器”的下载地址了。
所以:因为http的内容是明文传输的,明文数据会经过路由器、wifi热点、通信服务运营商、代理服务器等多个物理节点,如果信息在传输过程中被劫持,传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉,这就是中间人攻击,所以我们才需要对信息进行加密。
1.4、常见的加密方式
对称加密
使用一个秘钥,加密和解密所用的秘钥是相同的。
特点:算法公开、计算量小、加密速度快、加密效率高。
非对称加密
需要两个秘钥来进行加密和解密,一个公钥,另一个是私钥,用公钥加密,只有拥有私钥的人才能解密。
特点:算法强度复杂、安全性依赖于算法与秘钥但是由于其算法复杂,而使得加密解密速度没有对称加密解密的速度快。
1.5、数据摘要&&数据指纹
数字指纹(数字摘要),其基本原理是利用单向散列函数(Hash函数)对信息进行运算,生成一串固定长度的数字摘要。数字指纹并不是一种加密机制,但可以用来判断数据有没有被篡改。
摘要常见算法:有MD5、SHA1、SHA256、SHA512等,算法把无限的映射成有限,因此可能会有碰撞(两个不同的信息,算出的摘要相同,但是概率非常低)。
摘要特征:和加密算法的区别是,摘要严格意义不是加密,因为没有解密,只不过从摘要很难反推原信息,通常用来进行数据对比。
1.6、数字签名
摘要经过加密,就得到数字签名(具体是什么,后面会细讲)。
2、HTTPS的工作过程探究
既然要保证数据安全,就需要进行加密。
网络传输中不再直接传输明文了,而是加密之后的密文。
加密的方式有很多,但是整体可以分为两大类:对称加密和非对称加密。
2.1、方案1 - 只使用对称加密
如果通信双方都各自持有同一个秘钥X,且没有别人知道,这两方的通信安全当然是可以保证的(除非秘钥被破解)。
引入对称加密后,即使数据被截获,由于黑客不知道秘钥是啥,因此就无法进行解密,也就不知道请求的真实内容是啥了。
但事情没有这么简单,服务器同一时刻其实是给很多客户端提供服务的,这么多客户端,每个人用的秘钥都必须是不同的。因此服务器就需要维护每个客户端和每个秘钥之间的关联关系,这是个很麻烦的事情。
比较理想的做法是,客户端和服务器建立连接的时候,双方协商确定这次的密钥是什么,但如果直接传输密钥,黑客就能直接获得,那么就必须对密钥进行加密,这就又回到了之前的问题,所以此时密钥的传输再用对称加密就行不通了。
2.2、方案2 - 只使用非对称加密
鉴于非对称加密的机制,如果服务器先把公钥以明文方式传输给浏览器,之后浏览器向服务器传数据前,先用公钥加密再传,这样看起来似乎是没问题的,因为只有服务器有私钥,那么这里就有两个问题,第一是服务器用私钥加密数据传输给浏览器时,因为公钥是明文传输的,黑客也持有公钥,那么服务器的数据黑客也能进行解密。第二是浏览器向服务器发送的数据,黑客也可能进行掉包,理由同上。
2.3、方案三 - 双方都使用非对称加密
1、服务端拥有公钥S与对应的私钥S’,客户端拥有公钥C与对应的私钥C’;
2、客户和服务端交换公钥;
3、客户端给服务端发消息:先用S对数据加密,再发送,只能由服务器解密,因为只有服务器有私钥S’;
4、服务端给客户端发消息:先用C对数据加密,再发送,只能由客户端解密,因为只有客户端有私钥C’;
这样可以吗?
答案当然也是不行,首先效率太低,然后也会有安全问题,如果这时黑客用自己的公钥和私钥替代了服务器,那客户端的数据还是会被盗取。
2.4、方案四 - 非对称加密 + 对称加密
1、服务端具有⾮对称公钥S和私钥S';
2、客⼾端发起https请求,获取服务端公钥S;
3、客⼾端在本地⽣成对称密钥C,通过公钥S加密,发送给服务器;
4、由于中间的⽹络设备没有私钥,即使截获了数据,也⽆法还原出内部的原⽂,也就⽆法获取到对称密钥(真的吗?);
5、服务器通过私钥S'解密,还原出客⼾端发送的对称密钥C,并且使⽤这个对称密钥加密给客⼾端返回的响应数据;
6、后续客⼾端和服务器的通信都只⽤对称加密即可,由于该密钥只有客⼾端和服务器两个主机知道,其他主机/设备不知道密钥即使截获数据也没有意义。
其实这个已经很接近答案,但是依然有一个最大的问题,这也是上面的方案使用非对称加密所共有的问题,那就是客户端如何确保发来的公钥的合法性呢?换句话说就是如果黑客从一开始就把公钥替换了,那客户端又怎么会知道呢?
2.5、引入证书
CA认证
服务端在使用HTTPS前,需要向CA机构申领一份数字证书,数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器,浏览器从证书里获取公钥就行了,证书就如身份证,证明服务端公钥的权威性。
那么同时,这里也有一个问题,我们该如何确保证书的合法性?即没有被修改过并且要是这个权威机构发放的。这就要用到证书上的数据签名了。
理解数据签名
签名的形成是基于非对称加密算法的,注意,目前暂时和https没有关系,不要和https中的公钥私钥搞混了。
2.6、方案5 - 非对称加密 + 对称加密 + 证书认证
在客户端和服务器刚一建立连接的时候,服务器给客户端返回一个证书,证书包含了之前服务端的公钥,也包含了网站的身份信息。
客户端进行认证
当客户端获取到这个证书后,会对证书进行校验(防止证书是伪造的)
1、判定证书的有效期是否过期;
2、判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构);
3、验证证书是否被篡改:从系统中拿到该证书发布机构的公钥,对签名解密,得到一个hash值(称为数据摘要),设为hash1,然后计算整个证书的hash值,设为hash2,对比hash1和hash2是否相等,如果相等,则说明证书是没有被篡改过的。
中间人有没有可能篡改该证书?
中间人篡改了证书的明文,由于他没有CA机构的密钥,所以无法hash之后用私钥加密形成签名,那么也就没有办法对篡改后的证书形成匹配的签名。如果强行篡改,客户端收到该证书后发现明文和签名解密后的值不一致,则说明证书被篡改,证书不可信,从而终止向服务器传输信息,防止信息泄露给中间人。
中间人整个掉包证书?
因为中间人没有CA秘钥,所以无法制作假的证书吗,那么中间人只能向CA申请真证书,然后进行掉包,这个确实能做到证书的整体掉包,但是别忘了,证书明文中包含了域名等服务端认证信息,如果整体掉包,客户端依旧能够识别出来。