文章目录
- 前言
- 一、Https协议
- 二、常见的加密方式
- 对称加密
- 非对称加密
- 数据摘要&&数据指纹
- 中间人攻击
- 三、Https的加密历程
- 方案1-只使用对称加密
- 方案2-只使用非对称加密
- 方案3-双方都使用非对称加密
- 方案4-非对称加密+对称加密
前言
之前我们学习了Http协议,也试着做了一个HttpServer。所以对于Http我们也有了一个比较清晰的认识。
一、Https协议
之前我们在实现一个HttpServer的时候,我们所做的网络传输的数据都是没有任何加密的。
不做任何加密会有什么风险?
- 一旦被拦截,里面的数据一览无余。
- 可以劫持报文数据,将报文数据做篡改。
Https也是⼀个应用层协议,是在Http协议的基础上引⼊了⼀个加密层。
截止到目前,我们现在浏览的大部分网站都是采用Https协议,http协议正在逐步隐退。
二、常见的加密方式
对称加密
• 采用单钥密码系统的加密方法,同⼀个密钥可以同时用作信息的加密和解密,这种加密方法称为对称加密,也称为单密钥加密,特征:加密和解密所用的密钥是相同的。
• 常见对称加密算法(了解):DES、3DES、AES、TDEA、Blowfish、RC2等。
• 特点:算法公开、计算量小、加密速度快、加密效率高。
对称加密其实就是通过同⼀个"密钥",把明文加密成密文,并且也能把密文解密成明文。
⼀个简单的对称加密,按位异或。
非对称加密
需要两个密钥来进行加密和解密,这两个密钥是公开密钥(public key,简称公钥)和私有密钥(private key,简称私钥)。
• 常见非对称加密算法(了解):RSA,DSA,ECDSA。
• 特点:算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂,而使得加密解密速度没有对称加密解密的速度快。
• 通过公钥对明文加密,变成密文
• 通过私钥对密文解密,变成明文
也可以反着用
• 通过私钥对明文加密,变成密文
• 通过公钥对密文解密,变成明文
数据摘要&&数据指纹
• 数字指纹(数据摘要),其基本原理是利用单向散列函数(Hash函数)对信息进行运算,生成一串固定长度的数字摘要。数字指纹并不是一种加密机制,但可以用来判断数据有没有被篡改。
• 摘要常见算法:有MD5、SHA1、SHA256、SHA512等,算法把无限的映射成有限,因此可能会有碰撞(两个不同的信息,算出的摘要相同,但是概率非常低)。
• 摘要特征:和加密算法的区别是,摘要严格来说不是加密,因为没有解密,只不过从摘要很难反推原信息,通常用来进行数据对比。
怎么理解呢? 就像我们上一章将到的Cookie,现在很多企业所保存的Cookie内容其实是session ID, 既然我们要保证用户每一个人都必须保证唯一的session ID,我们就可以采用这种数据摘要的方式来生成用户的唯一session ID。
还有一种应用于云盘当中, 如果我们宿舍4个人都想要在云盘中保存一个教学视频,舍友A率先保存,花费了一个小时才上传到云盘。云盘服务器通过读取该视频二进制数据,生成一个唯一的摘要文件,存入到数据库中。
而当舍友B、C、D也想上传到云盘时,云盘会先读取计算机本地视频的二进制内容,通过同样的算法也生成一个摘要文件,而云盘只需要先上传这个摘要文件,再将它与数据库进行查找,如果找到,那就没有必要再存放一份相同的视频到它的服务器当中。 而是生成一个类似于软链接的文件,这样舍友B、C、D就成功实现秒传。
中间人攻击
Man-in-the-MiddleAttack,简称“MITM攻击”。
日常生活中我们进行网络通信并不是直接向服务器直接发送信息,而是先发送消息给路由器,路由器再发送给运营商,运营商再发给目标服务器。
所以在这里运营商和路由器就是中间人。
所以,如果我们不对数据进行加密的话,中间人可以将我们所传送的报文数据一览无余。
而如果中间人怀有恶意的话,中间人不一定就是运营商,也有可能是一些恶意的VPN,恶意的钓鱼WIFI,恶意的网络热点,恶意的钓鱼网站。就会导致你的隐私泄露或者报文数据被劫持篡改。
三、Https的加密历程
加密方法总是伴随着被破解->改进->被破解->改进…
所以Https在这样的历程中,有过这么几种加密方案。
方案1-只使用对称加密
因为对称加密是客户端和服务器需要约定好各自维护同一份密钥,但是对于客户端,客户端的秘钥是尽量不一样的,因为一旦客户端的秘钥都是相同的,黑客只需要破解一个客户端秘钥,就等于拿到了所有客户端的秘钥。
所以,这就需要服务器同时维护多个秘钥,会产生巨大的负担。且在维护关联关系也是十分麻烦。
方案2-只使用非对称加密
非对称加密需要双方各自持有公钥和私钥,只使用非对称加密的方式,私钥一般都是由服务器来持有,公钥也是服务器在收到请求时,响应给客户端时发送过去的。
图示如下
这就是客户单和服务器一次交互的流程。但是这并不安全,因为如果存在中间人,就会是这样。
中间人也能持有公钥S,且不能保证服务器发送给客户端的报文安全。
方案3-双方都使用非对称加密
-
服务端拥有公钥S与对应的私钥S’,客户端拥有公钥C与对应的私钥C’。
客户端和服务端交换公钥。 -
客户端给服务端发信息:先用S对数据加密,再发送。只能由服务器解密,因为只有服务器有私钥S’。
-
服务端给客户端发信息:先用C对数据加密,再发送。只能由客户端解密,因为只有客户端有私钥C’。
这种方案虽然可行,但是效率很低,而且也存在安全问题。
这里直接贴出有恶意中间人的图示。
这里的恶意中间人如果自己携带自己的公钥M和私钥M’,方案3就十分不安全。
方案4-非对称加密+对称加密
方案4是针对于方案3 效率低下 的改进,但是也仍然存在和方案3 一样的安全问题。