目录
HTTPS背景知识
HTTPS是什么?
加密解密
为什么要加密
常见的加密方式
对称加密
非对称加密
数据摘要&&数据指纹
数字签名
HTTPS工作过程探究
方案1:只使用对称加密
方案2:只使用非对称加密
方案3:双方都使用非对称加密
编辑
方案4:非对称加密+对称加密
中间人攻击
证书的引入
数据签名
查看CA机构
方案5:非对称加密+对称加密+证书认证
HTTPS完整流程
HTTPS也是⼀个应用层协议。是在HTTP协议的基础上引入了⼀个加密层。
HTTP协议内容都是按照文本的方式明文传输的。这就会导致在传输过程中出现一些被篡改的情况。早期很多公司刚起步的时候,使用的应用层协议都是HTTP,而HTTP无论是用GET方法还是POST方法传参,都是没有经过任何加密的,因此早期很多的信息都是可以通过抓包工具抓到的。
为了解决这个问题,于是出现了HTTPS协议,HTTPS实际就是在应用层和传输层协议之间加了一层加密层(SSL&TLS),这层加密层本身也是属于应用层的,它会对用户的个人信息进行各种程度的加密。HTTPS在交付数据时先把数据交给加密层,由加密层对数据加密后再交给传输层。
当然,通信双方使用的应用层协议必须是一样的,因此对端的应用层也必须使用HTTPS,当对端的传输层收到数据后,会先将数据交给加密层,由加密层对数据进行解密后再将数据交给应用层。
此时数据只有在用户层(应用层)是没有被加密的,而在应用层往下以及网络当中都是加密的,这就叫做HTTPS。
什么是加密和解密?
在这个过程中,往往需要一个或者多个中间的数据,辅助进行这个过程,这样的数据被称为密钥(正确发音是yue四声,但是大家都读作yao四声)。
例如在电影《火烧圆明园》中,有人要谋反干掉慈禧太后。恭亲王奕䜣给慈禧递的折子。折子内容只是扯⼀扯家常,但是套上⼀张挖了洞的纸就能看到真实要表达的意思。慈禧通过一张挖了洞的纸解密出了折子要传递的信息。
在这个例子中:
因此在古代其实人们早已能够运用加密和解密,而加密解密到如今已经发展成为一门独立的学科:密码学。而密码学的奠基人,也正是计算机科学的祖师爷之一,艾伦·麦席森·图灵。
计算机领域中的最高荣誉就是以他名字命名的“图灵奖”。
早期接触互联网的人应该都或多或少地了解臭名昭著的“运营商劫持”事件。比如当我们要想下载一个软件的时候。未被劫持的效果,点击下载按钮,就会弹出你想要下载的软件的下载链接。
但是由于你发出的HTTP请求是明文传输的,并且一定要经过运营商的路由器,那么路由器收到你的HTTP请求之后经过分析得知你想要下载某一个软件,此时它便可以响应一个其它软件的下载链接给你,如果这时候你稍微一不注意就会下载到某些流氓软件。
劫持的具体过程如下:
中间人攻击
因为http的内容是明文传输的,明⽂数据会经过路由器、wifi热点、通信服务运营商、代理服务
器等多个物理节点,如果信息在传输过程中被劫持,传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉,这就是中间人攻击 ,所以我们才需要对信息进行加密。
不止运营商可以劫持,其他的黑客也可以用类似的⼿段进行劫持,来窃取用户隐私信息,或者篡改内容.试想⼀下,如果黑客在用户登陆支付宝的时候获取到用户账户余额,甚⾄获取到用户的支付密码.....在互联网上,明文传输是非常较危险的事情!!!
HTTPS就是在HTTP的基础上进⾏了加密,进⼀步的来保证用户的信息安全。
对称加密的原理
如果你还想知道更多的非对称加密算法,可以了解一下RSA,这是一个基于因式分解的非对称加密算法。下面我们简单理解一下对称加密,对称加密最典型的例子就是异或运算。
我们用A异或B得到一个中间值C,此时如果我们采用C异或B就能重新得到A。在这个过程中,A就相当于通信双方想要交互的数据,B就相当于对称加密当中的密钥,C就相当于被密钥加密后的数据,异或运算实际就是一个简单的对称加密算法。当然按位异或只是一个简单的对称加密。HTTPS使用的对称加密算法要复杂许多。
非对称加密要用到两个密钥,一个公钥一个私钥,可以:
非对称原理涉及到的数学知识比较复杂,这里不作过多解释。
一般地,把对一个信息的摘要称为该消息的指纹或数字签名,数字签名是保证信息的完整性和不可否认性的方法。数据的完整性是指信宿接收到的消息一定是信源发送的信息,而中间绝无任何更改;信息的不可否认性是指信源不能否认曾经发送过的信息。其实,通过数字签名还能实现对信源的身份识别(认证),即确定"信源"是否是信宿意定的通信伙伴。 数字签名应该具有唯一性,即不同的消息的签名是不一样的;同时还应具有不可伪造性,即不可能找到另一个消息,使其签名与已有的消息的签名一样;还应具有不可逆性,即无法根据签名还原被签名的消息的任何信息。这些特征恰恰都是消息摘要算法的特征,所以消息摘要算法适合作为数字签名算法。
应用场景
比如某一个网站支持VIP功能,那么当VIP访问该网站的时候就需要输入密码来验证身份,如果直接将密码发送到网络当中,无论使用哪种协议总会有泄漏的可能性,因此我们可以将密码利用数据摘要算法生成⼀串固定长度的数字摘要。
网站的服务器数据库里面存储的同样是数字摘要,虽然我们不知道密码的具体内容,但是可以通过比较两个摘要来确定密码的正确性从而验证登录者的身份,这样就避免了直接用网络传输密码,从根本上保证了安全。
摘要经过加密生成数字签名(主要应用于证书,后面详细解释)
既然要保证安全,就需要对传输的数据进行加密。网络传输的过程中也就不再使用明文传输,而是加密之后的密文。刚才上面提到了两类加密方式对称加密和非对称加密,那么为什么会有两种加密方式呢?HTTPS协议实际工作的过程中又是使用的哪种加密方式呢?
如果通信双⽅都各自持有同⼀个密钥X,且没有别⼈知道,这两方的通信安全当然是可以被保证的(除非密钥被破解)。引入对称加密之后,即使数据被截获,由于黑客不知道密钥是啥,因此就⽆法进行解密,也就不知道请求的真实内容是啥了。
但事情没这么简单。服务器同⼀时刻其实是给很多客户端提供服务的。这么多客户端,每个人用的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了,黑客就也能拿到了)。因此服务器就需要维护每个客户端和每个密钥之间的关联关系,这也是个很麻烦的事情。比较理想的做法是,在客户端与服务器建立连接的时候,双方就协商好这次通信要使用到的密钥。
但是如果直接把密钥明文传输,那么黑客就也能获得密钥了,此后的加密解密操作就形同虚设,白白浪费资源了。因此密钥的传输必须加密传输。但是要想对密钥进行对称加密,就仍然需要先协商确定⼀个"密钥的密钥"。这就成了"先有鸡还是先有蛋"的问题了。此时密钥的传输再用对称加密就行不通了,我们要考虑其他方法来保证密钥的安全性。
鉴于非对称加密的机制,如果服务器先把公钥以明文方式传输给浏览器,之后浏览器向服务器传数据前都先用这个公钥加密好再传,从客户端到服务器信道似乎是安全的(有安全问题),因为只有服务器有相应的私钥能解开公钥加密的数据。但是服务器到浏览器的这条路怎么保障安全?
如果服务器用它的私钥加密数据传给浏览器,那么浏览器⽤公钥可以解密它,而这个公钥是⼀开始通过明⽂传输给浏览器的,若这个公钥被中间⼈劫持到了,那他也能⽤该公钥解密服务器传来的信息了。
并且前文提到了非对称加密的速度极慢,网络通信过程除了安全问题最重要的就是效率问题,只使用对称加密既不安全速度又慢,因此不采用这种方法。
这样貌似可以,但是首先效率低下,其次也有安全问题,能够遭到中间人攻击(后面会讲)
首先解决效率问题
由于对称加密的效率比非对称加密高很多,因此可以这样提高效率:只是在开始阶段协商密钥的时候使用非对称加密,后续的传输仍然使用对称加密。这样的做法已经很接近HTTPS采用的方法了,但是会遭到中间人攻击。
MAN-in-the-MiddleAttack,简称“MITM攻击”
确实,在⽅案2/3/4中,客户端获取到公钥S之后,对客⼾端形成的对称秘钥X⽤服务端给客户端的公钥S进⾏加密,中间⼈即使窃取到了数据,此时中间⼈确实无法解出客⼾端形成的密钥X,因为只有服务器有私钥S'。HTTPS通信安全的关键在于对称加密的密钥是否加密传输,中间人攻击窃取的也正是对称加密的密钥。
上面非对称加密+对称加密的方式想法很正确,先采用非对称加密保证密钥的安全传输,保证以后通信的安全性,之后采用对称加密保证通信的效率。但是中间人攻击可以伪装成为服务器,在第一步非对称加密的途中就窃取到密钥。
首先中间人有自己的对称加密密钥C,中间人有非对称加密公钥M,私钥M',server有S,S'。
了解完中间人攻击的具体过程,我们仔细分析一下可以发现,安全性出现危机的关键在于,客户端无法确定收到包含公钥的数据报文是由谁发送的,即client无法验证公钥的权威性。
为了解决上面的中间人攻击,HTTPS引入了证书来保证信息的安全传输。
对于中间人来说,证书可以说是一个很聪明的阳谋
服务端在使用HTTPS前,需要向CA机构申领⼀份数字证书,数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器,浏览器从证书里获取公钥就行了,证书就好比身份证,证明服务端公钥的权威性。
CA认证
CA认证,即电子认证服务 ,是指为电子签名相关各方提供真实性、可靠性验证的活动。
证书颁发机构(CA, Certificate Authority)即颁发数字证书的机构。是负责发放和管理数字证书的权威机构,并作为电子商务交易中受信任的第三方,承担公钥体系中公钥的合法性检验的责任。
这个证书可以理解成一个结构化的字符串,里面包含了以下信息:
需要注意的是:申请证书的时候,需要在特定平台生成,会同时生成⼀对密钥对,即公钥和私钥。这对密钥对就是用来在网络通信中进行明文加密以及数字签名的。
其中公钥会随着CSR⽂件,⼀起发给CA进行权威认证,私钥服务端自己保留,用来后续进行通信(其实主要就是用来交换对称秘钥)
可以使用在线生成CSR和私钥:https://myssl.com/csr_create.html
形成CSR之后,后续就是向CA进行申请认证,不过⼀般认证过程很繁琐,网络各种提供证书申请的服务商,⼀般真的需要,直接找平台解决就行。
签名的形成是基于非对称加密算法的,但是注意目前暂时和https没有关系,不要和https中的公钥私钥搞混了。
当服务端申请CA证书的时候,CA机构会对该服务端进行审核,并专门为该网站形成数字签名,过程如下:
在浏览器中点击右上角的
选择"设置",搜索"证书管理",即可看到以下界面(如果没有,在隐私设置和安全性->安全⾥⾯找找)
上面我们已经分析完毕中间人攻击的过程,得出了公钥的权威性无法保证的结论。那么证书认证的出现就能够保证server公钥的权威性,具体实现过程如下:
在客户端和服务器刚⼀建立连接的时候,服务器给客户端返回⼀个证书,证书包含了之前服务端的公钥,也包含了网站的身份信息。
客户端进行认证,当客户端获取到这个证书之后,会对证书进行校验(防止证书是伪造的)。
验证证书是否被篡改:从系统中拿到该证书发布机构的公钥,对签名解密,得到⼀个hash值(称为数据摘要),设为hash1。然后计算整个证书的hash值,设为hash2。对比hash1和hash2是否相等。如果相等,则说明证书是没有被篡改过的。
中间人有没有可能篡改证书
中间人掉包整个证书?
总结:
HTTPS⼯作过程中涉及到的密钥有三组
第一组(非对称加密):用于校验证书是否被篡改。服务器持有私钥(私钥在形成CSR⽂件与申请证书时获得),客户端持有公钥(操作系统包含了可信任的CA认证机构有哪些,同时持有对应的公钥)。服务器在客户端请求是,返回携带签名的证书。客户端通过这个公钥进行证书验证,保证证书的合法性,进⼀步保证证书中携带的服务端公钥权威性。
第二组(非对称加密):用于协商⽣成对称加密的密钥。客户端用收到的CA证书中的公钥(是可被信任的)给随机⽣成的对称加密的密钥加密,传输给服务器,服务器通过私钥解密获取到对称加密密钥。
第三组(对称加密):客户端和服务器后续传输的数据都通过这个对称密钥加密解密。
其实⼀切的关键都是围绕这个对称加密的密钥。其他的机制都是辅助这个密钥工作的