在http协议一文,我们理解了这个应用层协议的报文、特性等
但说到底,它依旧是在用明文的方式传送数据,很容易被中间人窃取和篡改,安全性很差
于是,我们在http层
和tcp层
之间放一个加密层
先前,我们直接将http报文交付给TCP层进行网络传输;
这里,我们在交付前先通过一道密码通信的框架(SSL/TLS),再将加密后的数据交给TCP,这样的HTTP+SSL/TLS
的组合就是HTTPS
443
;80
号端口到达对端后即可判断是否要进行解密
在讲解https之前,我们需要一些加密相关概念的铺垫
一般加密过程我们需要考虑三样东西
一段数据借助某种加密算法,通过加密密钥
可以生成密文,密文通过解密密钥
还原成原数据
这里加密密钥
和解密密钥
可以相同也可以不同,根据它们是否相同可以区分出两类加密方式
也称单密钥加密
常见的加密算法:DES、3DES、AES、TDEA、Blowfish、RC2等
特点:算法公开、计算量小、加密速度快、加密效率高
一个简单对称加密算法案例:按位异或
假设明文a = 1234,密钥key = 8888
加密:a ^ key得到密文b = 9834
然后针对密⽂9834再次进⾏运算b^key,得到的就是原来的明⽂1234.
当然,按位异或只是最简单的对称加密.HTTPS中并不是使⽤按位异或.
需要两个密钥来进⾏加密和解密,这两个密钥是公开密钥(publickey,简称公钥)和私有密钥(privatekey,简称私钥)。
常⻅⾮对称加密算法:RSA,DSA,ECDSA
特点:算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂,⽽使得加密解密速度没有对称加密解密的速度快
⾮对称加密要⽤到两个密钥,⼀个叫做"公钥",⼀个叫做"私钥".
公钥和私钥是配对的.最⼤的缺点就是运算速度⾮常慢,⽐对称加密要慢很多.
也可以反着⽤
数据摘要(数字指纹),其基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算,⽣成⼀串固定⻓度的数字摘要。数字指纹并不是⼀种加密机制,但可以⽤来判断数据有没有被窜改。
转化是单向的,我们可以通过原文映射出摘要,但无法从摘要还原出原文。
算法把无限映射成有限,因此有可能发生碰撞(两个不同的信息得到的摘要相同),但是只要算法合适,这种情况发生的概率极低。
如上,我们仅更改了文本的一个字符,但是它的数字摘要却发生了巨大的变化
摘要常见算法:MD5、SHA1、SHA256、SHA512等
摘要特征:和加密算法的区别是,摘要严格意义不是加密,因为没有解密,通常⽤来进⾏数据对⽐
将摘要进行加密就会得到数字签名(后面细说)
如果通信双⽅都各⾃持有同⼀个密钥X,且没有别⼈知道,这两⽅的通信安全当然是可以被保证的(除⾮密钥被破解)
引⼊对称加密之后,即使数据被截获,由于⿊客不知道密钥是啥,因此就⽆法进⾏解密,也就不知道请求的真实内容是啥了.
但事情没这么简单.服务器同⼀时刻其实是给很多客⼾端提供服务的.这么多客⼾端,每个⼈⽤的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了,⿊客就也能拿到了).因此服务器就需要维护每个客⼾端和每个密钥之间的关联关系,这也是个很⿇烦的事情~
⽐较理想的做法,就是能在客⼾端和服务器建⽴连接的时候,双⽅协商确定这次的密钥是啥~
但是如果直接把密钥明⽂传输,那么⿊客也就能获得密钥了~~此时后续的加密操作就形同虚设了.
因此密钥的传输也必须加密传输!
但是要想对密钥进⾏对称加密,就仍然需要先协商确定⼀个"密钥的密钥".这就成了"先有鸡还是先有蛋"的问题了.此时密钥的传输再⽤对称加密就⾏不通了.
鉴于⾮对称加密的机制,如果服务器先把公钥以明⽂⽅式传输给浏览器,之后浏览器向服务器传数据前都先⽤这个公钥加密好再传,从客⼾端到服务器信道似乎是安全的(有安全问题),因为只有服务器有相应的私钥能解开公钥加密的数据。
但是服务器到浏览器的这条路怎么保障安全?
如果服务器⽤它的私钥加密数据传给浏览器,那么浏览器⽤公钥可以解密它,⽽这个公钥是⼀开始通过明⽂传输给浏览器的,若这个公钥被中间⼈劫持到了,那他也能⽤该公钥解密服务器传来的信息了
服务端给客⼾端发信息:先⽤C对数据加密,在发送,只能由客⼾端解密,因为只有客⼾端有私钥C’
这样貌似也⾏啊,但是
先解决方案3的效率问题
此时,客户端拿着公钥,服务端拿着私钥
从方案1到方案4,我们似乎已经得到了一个完全的方案
Man-in-the-MiddleAttack,简称“MITM攻击”
下面我们尝试作为一个中间人破解方案4
服务器具有⾮对称加密算法的公钥S,私钥S’
中间⼈具有⾮对称加密算法的公钥M,私钥M’
客户端具有对称加密算法密钥C
客户端像服务器发起请求,服务器将公钥明文传送给客户端
中间人劫持到数据报文,提取公钥S并保存好,然后将劫持到报文中的S换成自己的公钥M,将伪造报文发给客户端
客户端收到报文,提取公钥M(浑然不知已经被人改了),将对称密钥C用M加密后形成报文发送给服务器
中间人劫持后,直接用自己的私钥M’进行解密,得到通讯密钥C,再用曾经保存的服务器公钥S加密后发送给服务器
服务器拿到报文,用自己的S’解密,得到通讯密钥C
至此,双方便开始用C进行对称加密,进行通讯.但是一切都在中间人的掌控之中,劫持数据,进行窃听甚至修改
上面的攻击方案,也同样试用方案2、3
问题的本质出在那里?客户端无法确定收到的含有公钥的数据报文,就是目标服务器发来的!
服务端在使用HTTPS服务前,需要向CA机构申领一份数字证书,数字证书里包含了申请者的信息、公钥信息等。服务器把证书传送给浏览器,浏览器就可以给从证书中获取公钥
如果用这个证书代替方案4中的服务器发出的公钥
那么,只要保证服务器和客户端通讯过程中,这个证书无法被修改或者替换,即可杜绝中间人攻击的发生。
接下来我们就看看证书是如何保证的
这个证书可以理解成是⼀个结构化的字符串,⾥⾯包含了以下信息:
其中,数字签名起到了重要做作用
签名的形成基于非对称加密算法
CA机构手里拿着一对公钥(A)-私钥(A`)对,且公钥会被内置到用户的操作系统
收到服务端的申请信息、公钥信息等明文进行核验,并添加发布机构、有效期等信息,组成一个明文证书
然后获取明文证书的数据摘要
再用私钥A`对数据摘要进行加密得到数字签名
最后将明文证书与数字签名组成数字证书,颁发给服务器端
申请的时候,需要在特定平台⽣成CSR,会同时⽣成⼀对密钥对,即公钥和私钥。这对密钥对就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。 其中公钥会随着CSR⽂件,⼀起发给CA进⾏权威认证,私钥服务端⾃⼰保留,⽤来后续进⾏通信(其实主要就是⽤来交换对称秘钥)
![]()
![]()
可以使⽤在线⽣成CSR和私钥:https://myssl.com/csr_create.html
形成CSR之后,后续就是向CA进⾏申请认证,不过⼀般认证过程很繁琐,⽹络各种提供证书申请的服务商,⼀般真的需要,直接找平台解决就⾏
在客⼾端和服务器刚⼀建⽴连接的时候,服务器给客⼾端返回⼀个证书,证书包含了之前服务端的公钥,也包含了⽹站的⾝份信息.
当客户端获取到这个证书,会对证书进行校验(防止证书是伪造的)
Edge浏览器,点击右上⻆的
完整流程:
HTTPS⼯作过程中涉及到的密钥有三组.
其实⼀切的关键都是围绕这个对称加密的密钥.其他的机制都是辅助这个密钥⼯作的.
- 第⼆组⾮对称加密的密钥是为了让客⼾端把这个对称密钥传给服务器.
- 第⼀组⾮对称加密的密钥是为了让客⼾端安全拿到第⼆组⾮对称加密的公钥.