六.应用层协议——HTTPS协议

admin管理员组

文章数量:1603458

HTTPS协议

什么是加密

话说在83 版⽕烧圆明园的电视剧中, 有⼈要谋反干掉慈禧太后.但是如果直接告诉慈禧太后这件事，皇宫内鱼龙混杂，难免会打草惊蛇，于是恭亲王奕䜣给慈禧递了个折⼦. 折⼦内容只是扯⼀扯家常, 但是套上⼀张挖了洞的纸就能看到真实要表达的意思

这其实就是加密的过程

加密就是把**明⽂(要传输的信息)**进⾏⼀系列变换, ⽣成密⽂.
解密就是把密⽂再进⾏⼀系列变换, 还原成明⽂

在我们的故事中，恭亲王奕䜣想要传递的实际内容(明文)是"当⼼肃顺, 端华, 戴恒" ，但是直接传输并不行，还需要经过一系列变化，于是将要传递的明文，放在了全篇奏折当中，这就是密文
双方提前约定好对应的密匙(挖了洞的纸)，就可以获取明文(真实内容)，而在别人眼中看到的都是密文(奏折全文，扯家常)
又比如我们写程序时使用的异或运算，其实也能算作是加密的过程，我们的实际运算经过异或运算后，将会变成密文，我们需要再次使用一次异或运算(密匙)，才能获取到真实的数据

为什么我们需要加密

早期很多公司使用的应用层协议都是HTTP协议，而像我们上节所说的，HTTP协议无论是采用GET方法还是POST方法传参，都是没有经过任何加密的，因此早期很多的信息都是可以通过抓包工具抓到的，这无疑会带来很大风险！像是我输入支付宝的账号和密码，假如被黑客抓包，那造成的损失就无法预估了！
被盗取账号和密码，可能有人会觉得离我们很遥远，所以我们再举一个例子，我们有时候在浏览器下载我们对应的软件，比如说以前有一款软件叫做天天动听，按道理来说，就会直接下载对应的安装包

但是有时候我们会遇到这样的情况，天天动听下载网址被网络运营商劫持，安装包的内容会被修改为其它软件的下载链接
而这种现象其实蛮常见的，原因就在于我们通过⽹络传输的任何的数据包都会经过运营商的⽹络设备(路由器, 交换机等), 那么运营商的⽹络设备就可以解析出你传输的数据内容, 并进⾏篡改.
一旦我们点击 “下载按钮”, 其实就是在给对应服务器发送了⼀个 HTTP 请求, 获取到的 HTTP 响应其实就包含了该APP 的下载链接.
但一旦运营商劫持之后, 发现这个请求是要下载天天动听, 就⾃动的把交给⽤⼾的响应给篡改成 “QQ浏览器” 的下载地址了
还有比如类似360安全卫士等等软件，假如我们没有对其设置，我们发出的HTTP请求将会被修改为其它新的内容，有时候等待我们电脑的将是一大堆捆绑下载的软件

这就是我们为什么需要加密的原因
因为HTTP的内容是明⽂传输的，明⽂数据会经过路由器、wifi热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。
劫持者还可以篡改传输的信息且不被双⽅察觉，这就是中间⼈攻击，所以我们才需要对信息进⾏加密

那为什么会出现这种中间人攻击的现象呢?
理由也很简单，一切都是利益.
同时我们还需要理解到数据安全是一个相对性的问题，只要算力足够强，我们就能花对应的时间成本进行破解，但是解密就会产生对应的成本，破解之后的效益，能否弥补对应花费的成本才是关键！假如耗费了大量成本(钱，时间等等)，获取的效益近乎没有，或者相较很少，那解密是没有必要的
我们需要做的就是提高解密者的解密成本，这就是数据安全

什么是HTTPS协议

为了解决诸如中间人劫持的问题，HTTPS协议才应运而生，HTTPS协议实际就是在应用层和传输层协议之间加了一层加密层（SSL&TLS），这层加密层本身也是属于应用层的，它会对用户的个人信息进行各种程度的加密。
HTTPS在交付数据时先把数据交给加密层，由加密层对数据加密后再交给传输层
更简单直接来讲，HTTPS 就是在 HTTP 的基础上进⾏了加密, 进⼀步的来保证⽤⼾的信息安全

常见的加密方式

在了解HTTPS具体工作过程探究之前，我们需要了解几种不同的加密方式

对称加密

采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密
通俗点讲，加密和解密用的密钥都是相同的，就是对称加密
常⻅对称加密算法：DES、3DES、AES、TDEA、Blowfish、RC2等

它的好处就是算法公开的，计算量一般比较小，效率高

⼀个最简单的对称加密, 就是我们前面提到过的按位异或运算
假设 明⽂ a = 1234, 密钥 key = 8888
则加密 a ^ key 得到的密⽂ b 为 9834.
然后针对密⽂ 9834 再次进⾏运算 b ^ key, 得到的就是原来的明⽂ 1234.
(对于字符串的对称加密也是同理, 每⼀个字符都可以表⽰成⼀个数字)

非对称加密

非对称加密则与对称加密不同，它需要两个密匙，一个我们称作公钥(全网公开)，另一个称作私钥(只能自己拥有)
加密和解密的过程，并没有说限定用公匙加密，私匙解密，但是有一点是确定的

假如用公钥加密，只能用私钥解密
假如用私钥加密，只能用公钥解密

用私钥来加密，大家都有公钥，当然能获取对应的明文，这加密没啥用
但是公钥公开，我们所有人都可以使用公钥来进行加密，此时只有拥有私钥的人才能解密！这就是非对称加密最大的特点
常⻅⾮对称加密算法：RSA，DSA，ECDSA

好处:算法强度复杂、安全性依赖于算法与密钥
缺陷:但是由于其算法复杂，⽽使得加密解密速度没有对称加密解密的速度快

数据摘要/数据指纹

概念

在HTTPS工作探究之前，我们还需要了解数据摘要这个概念.
数据摘要不是一种加密机制，因为它是没有解密这个过程的(不可逆)，但它有一个很重要的功能，通过数据摘要来判断文本是否被篡改
具体操作可以用下面的图片来表示
利用Hash算法，从原始文本中提取固定大小的字符串，我们将这个字符串称作数据摘要，从它的另一个名字——数据指纹，我们也可以看出来，它是具有很强的唯一性

一旦文本稍微被修改了一点，哪怕是一个字，得到的数据指纹也是不同的，这样我们就可以通过数据指纹的直接比对(不用原始文本一个个进行比对)，来判断数据是否被篡改
摘要常⻅算法：有MD5、SHA1、SHA256、SHA512等，算法把⽆限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率⾮常低）

在生活中应用场景:

1.用户注册登录

我们在新下载一个软件，比如说下载了QQ，我们首先会进行用户注册，输入对应的账号和密码，然后再将对应我们的用户信息，交到数据库中保存

但是数据库里面并不能直接存储我们的用户信息，不然公司内部人员或者黑客等等，就可以盗取我们所有的个人用户信息，这将会产生非常大的危险！
此时数据指纹就发挥作用了，数据库里面存储的仅仅是用户注册信息对应的数据指纹，下次用户再访问的时候，只需要重新比对数据库里面的特定字段进行比对即可，如果数据库中有对应的字段，则可以成功登录；否则，才需要注册
一来起到了一定意义的"加密"作用，黑客不可能通过数据指纹还原用户的注册信息；二来数据指纹的直接比对，某种程度上来说，也提高了效率

2.百度网盘------秒传

有时候我们传一部电影到网盘中速度会很慢，但是过了一段时间后，重新上传相同的文件，速度就会非常快，这是为什么呢?
使用网盘的人实际上并不止一个用户，用户与用户之间上传的文件是有可能相同的，而这些文件就不需要再重新保存在网盘数据库当中.
因此，在第一次上传的时候，会在百度网盘服务器中形成一份数据指纹，用户在向百度网盘申请上传对应资源时，双方其实会先进行协商，在用户端会先形成一份数据摘要，两个数据摘要进行比对
假如是相同的，则不需要再重新上传对应的文件，系统会提供用户访问该文件的权限，并直接显示上传成功；否则，才存储到对应的网盘之中，这就是秒传的原理.

HTTPS的工作过程探究

有了前面的知识铺垫后，我们就可以开始了解HTTPS的工作过程是什么
在这节中，我们将自己逐步设计对应的加密方案，对出现的问题再逐一解决优化，最后找到最适合我们需求的方案

方法一.只采用对称加密

假如客户端对数据使用对称加密，发到网络当中
由于中间人(黑客等等)并不知道对应的密匙，所以即便它将数据全部截取下来，也无法进行解密，或者说需要耗费精力去进行解密，无法直接得到真实的信息内容，此时数据安全是得到保证的！

但事情没这么简单.
最大的缺陷在于如何建立客户端和服务器端双方的共识呢?
服务器要得到用户的明文信息，那也要知道客户端采取的密钥是什么，但是密钥也是信息！如何将密钥信息安全传给对方呢?难不成给密钥再加上密钥吗?
有人会说内置，但是密钥又内置到哪里呢?假如就在系统之中，中间人同样可以轻松获取到对应的密钥
还有一个问题，服务器同⼀时刻其实是给很多客⼾端提供服务的. 这么多客⼾端, 每个⼈⽤的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了, ⿊客就也能拿到了).
因此服务器就需要维护每个客⼾端和每个密钥之间的关联关系, 这也是个很麻烦的事情

方法二.只采用非对称加密

鉴于⾮对称加密的机制，如果服务器先把公钥(全网公开)以明⽂⽅式传输给客户端(浏览器)，之后客户端(浏览器)向服务器传数据前都先用这个公钥加密好再传，因为只有服务器有相应的私钥能解开公钥加密的数据，所以从客户端到服务器端通信这条路径似乎是安全的！

但是服务器端到客户端的路径又该怎么保证呢?
服务器端假如用公钥加密，发送给客户端(浏览器),那客户端会表示自己无能为力，毕竟我没有对应的密钥
如果服务器⽤它的私钥加密数据传给浏览器，那么公钥又是公开的，一旦一开始这个公钥被中间⼈劫持到了，那他也能⽤该公钥解密服务器传给客户端(浏览器)的信息

方法三.双方都采用非对称加密

有了方法二，一方使用非对称加密，就能保证一端传送给另外一端的数据安全，那双方都采用非对称加密不久好了?
方法三的设计就是如此，双方各有一个公钥(全网公开)，私钥(只能自己拥有)
第一步.客⼾和服务端交换公钥

第二步.客⼾端给服务端发信息：先⽤公钥S对数据加密，再发送，因为只有服务器有私钥S’，所以只能由服务器解密

第三步.同样地，服务端给客⼾端发信息：先⽤公钥C对数据加密，再发送，因为只有客⼾端有私钥C’，所以只能由客⼾端解密

这样看上去已经比较完美了，但是依旧存在问题
前面我们已经提到过了，非对称加密的效率并不高，因此通篇采用非对称加密来进行数据的交互，效率之低可想而知
同样的，它依旧有存在隐藏的安全问题！

方法四.非对称加密＋对称加密

那有没有一种方法，能够采用对称加密进行数据之间的交互呢?这其实就是我们方法一的目标(提高效率)，不过因为密钥无法进行传递而失败告终
然后方法二又告诉了我们，假如采用非对称加密，是可以保证从客户端到服务器端通信这条路径的安全性(待定)
方法一，二的结合，方法四的思路便诞生出来
第一步.服务器端将公钥S传给客户端

第二步.客户端对公钥S进行对称加密，在本地⽣成对称密钥C, 通过公钥S加密, 发送给服务器
由于中间的⽹络设备没有私钥S’, 即使截获了数据, 也⽆法还原出内部的原⽂, 也就⽆法获取到对称密钥C

第三步，服务器端利用私钥S’，获取到对应的对称密钥C，那以后双方进行交互的时候，都直接采用对称密钥C即可

后续客⼾端和服务器的通信都只⽤对称加密即可. 由于对称密钥C只有客⼾端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义.
这就大大解决了我们方法三遇到的效率问题
但是它依旧有安全问题

中间人攻击(MITM攻击)

Man-in-the-MiddleAttack，简称“MITM攻击”
我们说方案二，三，四都有安全问题，应该如何理解呢?
现在我们站在中间人的角度去思考如何获取到我们对应的数据
假如我们是在双方都完成密钥交互的时候才开始获取数据，那我们可能真的只能傻愣愣的看着加密数据交互了.
但是如果我们在最开始握⼿协商的时候就进⾏数据获取，那就不⼀定了，我们还有机会！
拿我们的方案四举例，假如方案四都能被我们攻破，那方案二，三自然不成问题
第一步，现在服务器依旧具有⾮对称加密算法的公钥S，私钥S’，但同时我们作为中间⼈也具有⾮对称加密算法的公钥M，私钥M’

第二步，按照我们方案四的步骤，客⼾端向服务器发起请求，服务器首先会明⽂传送公钥S给客⼾端
但是，我们作为中间人，可不会让公钥S这么轻松到达客户端
我们劫持数据报⽂，提取公钥S并保存好，然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M，并将伪造报⽂发给客⼾端

第三步，客⼾端收到报⽂，提取公钥M(⾃⼰当然不知道公钥被更换过了)，⾃⼰形成对称秘钥X，⽤公钥M加密X，想要形成报⽂发送给服务器，但是我们中间人又怎么会如它所愿呢?
我们继续劫持后，直接⽤⾃⼰的私钥M’进⾏解密，得到通信秘钥X，再⽤曾经保存的服务端公钥S加密后，将报⽂推送给服务器

第四步，服务器拿到报⽂，⽤⾃⼰的私钥S’解密，得到通信秘钥X，双⽅开始采⽤X进⾏对称加密，进⾏通信。但是⼀切都在中间⼈的掌握中，劫持数据，进⾏窃听甚⾄修改，都是可以的！

所以，只要我们作为中间人，从一开始就准备好攻击双方，无论是方法四，或者是方法二，三等等，都可以随意攻破！
那中间人离我们很远吗?我们的路由器其实就是一个中间人！在访问所有网站资源之前，都需要经过它，只不过它不会危害我们而已.

如何成为中间人呢?
1.ARP欺骗
在局域⽹中，hacker经过收到ARP Request⼴播包，能够偷听到其它节点的 (IP, MAC)地址。例:⿊客收到两个主机A, B的地址，告诉B (受害者) ，⾃⼰是A，使得B在发送给A的数据包都被⿊客截取
2.假WIFI && 假网站
有些人贪小便宜，连上了别人给你的免费钓鱼WIFI，当你访问服务器资源时，都会先经过别人的节点，此时别人想要获取你的资源请求等等就变得异常容易！

本质上之所以能被攻击，核心原因是由于，客户端无法识别公钥是否合法！
假如可以识别，那你中间人怎么可以随便替换我的公钥S呢?一眼就看出六耳猕猴的真身！
这就是我们要引入安全证书的原因

安全证书

在买食品的时候，我们可能会挑有食品安全认证的食品才买，为什么呢?因为得到国家食品安全认证的食物有保障
同样的，在除了服务器端和用户端外，还有另外一个第三方CA机构来做认证，服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。
这个 证书 可以理解成是⼀个结构化的字符串, ⾥⾯包含了以下信息:
• 证书发布机构
• 证书有效期
• 公钥
• 证书所有者
• 签名
• …
服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性
具体操作过程如下:
1.申请认证(证书)
服务器端申请自己的公钥和私钥，比如说使用linux生成公钥，私钥的指令

ssh-keygen -t rsa

2.审核信息
将私钥保存好，把域名，申请者，公钥记住，去对应线上网站申请CSR文件，比如:CSR在线生成网站

3.签发证书
形成CSR之后，后续就是向CA机构进⾏申请认证证书，不过⼀般认证过程很繁琐，⽹络各种提供证书申请的服务商，⼀般真的需要，直接找平台(淘宝等等)解决就⾏

4.返回证书
服务器端将证书发给客户端

那到底什么是证书呢?证书也是文本，是数据啊！为什么它就安全呢?

安全证书的形成过程

我们填好的原始数据(域名，申请者，服务器公钥等等)，首先会通过Hash等散列函数，得到散列值，这其实就是我们提到过的数据摘要.
接下来，CA机构会利用它自己的私钥，加密这段散列值，形成对应的数字签名S
服务端申请的证书明⽂和数字签名S 共同组成了数字证书，这样⼀份数字证书就可以颁发给服务端了

假如要进行验证，也非常简单
客户端拿到对应的数字证书后，首先将数字签名和数据分离，对于数字签名，我们用CA机构提供的公钥进行解密，获取对应的散列值；对于数据我们则采用散列函数，同样获取对应的散列值
若两者的散列值相同，则该数字证书有效，里面的内容就可以信任，否则，直接舍弃！

安全证书为什么安全

因为只能用CA的私钥形成签名，CA私钥只有CA机构自己知道，世界上，只有CA能够完成签名的过程
CA机构是权威机构，为了保证合法性，一般OS和浏览器，在出厂下载的时候，就已经内置了CA的公钥！
所以，就会有以下三种情况:
1.数据一旦被修改，对应的散列值立马发生改变，验证不通过；
2.数据没有修改，签名修改了，因为浏览器只会用CA的公钥来进行解密，你自己用私钥改的签名，没有人认，散列值解不出来
3.数据和签名都改了，整个证书改掉呢?
由于没有私钥，浏览器依旧解不出来，不认你的证书
就算我中间人自己去CA机构申请一份证书，但是不要忘了证书里面还包括域名，申请人等等的信息!尤其是域名，浏览器对获取到的数字证书进行验证，依旧一眼就可以识破这是中间人伪装的假证书

为什么数据为什么不直接加密，而是先形成摘要，形成签名呢?
1.普适性
有些加密算法，其实对明文的长度是有要求的，所以需要缩短明文的长度
有人会说明文长度理论上应该差不多，的确如此，但是我们不要简单理解为这是为HTTPS服务的方案，而是一套解决办法，以后甚至可以用来数据的加密传输等等
2.提高效率
缩⼩签名密⽂的⻓度,摘要的长度是固定的，比较短，加快数字签名的验证签名的运算速度

5.验证证书
客户端验证证书是否有效，看域名，看申请者等等，然后从中获取对应的合格服务器端公钥
6.密钥协商
进行方法四非对称加密＋对称加密进行信息交流的过程

HTTPS真正的工作过程

所以HTTPS整个完整过程是⾮对称加密 + 对称加密 + 证书认证三大过程的结合
1.用户端先向服务器申请对应的证书
2.然后利用浏览器内置的CA机构公钥，验证证书的合法性
一旦异常直接丢弃；
否则，证明证书是合法的，而且内容没有被修改
接下来，公钥的合法性得到了保证，客户端再进行方法四的形成对称密匙C的所有过程！

本文标签： 协议应用层HTTPS