介绍

 

承接上篇：HTTP协议初识·中篇_清风玉骨的博客-CSDN博客

本篇内容：

长链接

网络病毒

cookie使用&session介绍

基本工具介绍

postman 模拟客户端请求

fiddler 本地抓包的软件

https介绍

https协议原理

为什么加密

怎么加密

CA证书介绍

数字签名介绍

加密是怎么防止中间人攻击(黑客)

补充1：长链接

 1：http周边会话保持

补充2：cookie保存方法(旧)

这种老方法容易被盗取，这里会造成很大的用户信息泄漏隐患

问题1：网络病毒（木马与蠕虫）

木马：以盗取目标主机信息为主要目的违法行为，比如盗取你的cookie文件

蠕虫：以攻击主机为主要目的破坏行为，比如强制占用你的网络资源之类的，让你的主机变卡 

当你的cookie文件被别人使用的时候，就会发生服务器误认的情况

木马：对你问题不是最大大，但是对社会危害比较大，因为通常并不会只攻击你一个人，它通常会广泛散布，比如一个社交软件的木马病毒，它会进行诈骗之类的违法行为

但是对你影响比较大的问题就是你的账号密码泄漏了 

补充3：cookie保存方法(新)

2：添加cookie属性

测试结果

补充4：基本工具

postman 

下载参考教程

全网最全的 postman 工具使用教程 - 知乎 (zhihu.com)

演示1：请求成熟的网址

演示2：请求自己写的网址

服务器状态

功能1：可以构建参数进行请求

这里演示的是raw的格式进行提交，还可以用form表单的形式这里就不一一演示了

fiddler

简介：本地抓包的软件

下载参考教程

Fiddler入门：下载、安装、配置、抓包、customize rules - 知乎 (zhihu.com)

 演示1：自动抓取本地请求

演示2：游览器视角

演示3：抓取本地登入信息 

无论是post还是get方法都是一样的，都不安全！

其他的功能就自行了解吧

工作原理

这其实就是代理

        记得要想起局域网通信原理，其实任何东西都可以被抓到，因为都是明文传输的！不在同一个局域网不能抓，但是可以实现，为了安全不要去涉及这些东西

工具总结

HTTPS协议原理

HTTPS是什么

HTTPS也是⼀个应⽤层协议.是在HTTP协议的基础上引⼊了⼀个加密层
HTTP协议内容都是按照⽂本的⽅式明⽂传输的.这就导致在传输过程中会出现⼀些被篡改的情况
 

        密文很简单，这里不介绍了，因为这是有专门的岗位进行的，普通的程序员只需要知道就行了

例子：a^b = c  c^b = a

通过一个简单的异或就可以实现一种加密，客户端a(明文数据)，异或b(密钥)之后得到密文c，再发送c给服务端，服务端知道密钥b，再异或b得到a，这就实现了一个加密的网络传输，这就可以算是一种对称加密

补充4：为什么要加密

运营商劫持

网络抓包

        所以这也是为什么你直接访问国外网址，你是访问不了的，因为运营商直接掐掉了，注意无论是什么的网络请求都绕不开运营商！！！

加密

        看待加密的数据是否安全，这应该在时间维度上进行判断，因为如果在长时间的维度上基本上是没有可以被破解的，我们讨论的安全，通常是基于一段数据基于现在的算力在长时间的维度上无法被破解，那么我们就说这是安全的，因此加密和破解这是一个此消彼长的一队，并且随着发展在不断的进步

补充5：常见的加密方式
 

对称加密
 

• 采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对
称加密，也称为单密钥加密，特征：加密和解密所⽤的密钥是相同的
• 常⻅对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等
• 特点：算法公开、计算量⼩、加密速度快、加密效率⾼

对称加密其实就是通过同⼀个"密钥",把明⽂加密成密⽂,并且也能把密⽂解密成明⽂.
 

非对称加密
 

• 需要两个密钥来进⾏加密和解密，这两个密钥是公开密钥（publickey，简称公钥）和私有密钥（privatekey，简称私钥）。
• 常⻅⾮对称加密算法(了解)：RSA，DSA，ECDSA
• 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，⽽使得加密解密速度没有对称加密解密的速度快。

⾮对称加密要⽤到两个密钥,⼀个叫做"公钥",⼀个叫做"私钥".
公钥和私钥是配对的.最⼤的缺点就是运算速度⾮常慢，⽐对称加密要慢很多.
• 通过公钥对明⽂加密,变成密⽂
• 通过私钥对密⽂解密,变成明⽂
也可以反着⽤
• 通过私钥对明⽂加密,变成密⽂
• 通过公钥对密⽂解密,变成明⽂

 

补充6：数据摘要&&数据指纹

数据摘要可以对比两个文件是否为同一个文件 

• 数字指纹(数据摘要),其基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算,⽣成⼀串固定⻓度的数字摘要。数字指纹并不是⼀种加密机制,但可以⽤来判断数据有没有被窜改。

• 摘要常⻅算法：有MD5、SHA1、SHA256、SHA512等，算法把⽆限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率⾮常低，可以忽略不记）

• 摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常⽤来进⾏数据对⽐

例如：session id就是通过哈希摘要形成的，它通过你的账号密码形成的数据摘要进行匹配来实现登入的成功的功能，并且在企业的内部关于用户表的密码也并不是直接存储明文密码的，因为涉及到了密码的字段，必须是“加密”的，这里也是通过数据摘要来形成的，并且由于生成的是固定的，也可以方便管理(因为用户的密码各有长度)

还有百度网盘的妙传的功能也是如此实现的，由于使用人数众多，当有人上传文件的时候网盘就会形成一个数据摘要，因为这是通过特殊算法形成的一段固定长度的子串，当有人上传一样的文件的时候，这时候网盘就会通过摘要进行匹配，再管理起来，当出现一样的数据摘要的时候，就直接把这个文件给上传人使用。表现在上传的时候并不是直接开始上传，而是网盘通过本地计算机生成一个数据摘要，网盘利用这个数据摘要匹配，当匹配到的时候就不需要再上传了，形成了妙传的功能

 

补充7：数字签名

        签名的形成是基于⾮对称加密算法的，注意，⽬前暂时和https没有关系，不要和https中的公钥私钥搞混了

当服务端申请CA证书的时候，CA机构会对该服务端进⾏审核，并专⻔为该⽹站形成数字签名，过程如下：
1.CA机构拥有⾮对称加密的私钥A和公钥A'
2.CA机构对服务端申请的证书明⽂数据进⾏hash，形成数据摘要
3.然后对数据摘要⽤CA私钥A'加密，得到数字签名S
服务端申请的证书明⽂和数字签名S共同组成了数字证书，这样⼀份数字证书就可以颁发给服务端了

签名流程：把数据进行散列函数操作得到一个散列值，图上的认证指的就是数据(不要被误导了)，把数据和签名合在一起形成数字签名

验证流程：把数据和签名分开，分别进行散列函数操作，得到两个散列值，当不相等的时候就说明两者之间有一份被篡改了了，否则表示文本没有被篡改过

总结：数据签名是为了防止数据被篡改

HTTPS的⼯作过程探究

 

既然要保证数据安全,就需要进⾏"加密".
⽹络传输中不再直接传输明⽂了,⽽是加密之后的"密⽂".
加密的⽅式有很多,但是整体可以分成两⼤类:对称加密和⾮对称加密

网络通信要解决是什么问题

先解决第一个数据被监听的问题

方案1-只使用对称加密
 

        如果通信双⽅都各⾃持有同⼀个密钥X，且没有别⼈知道，这两⽅的通信安全当然是可以被保证的（除⾮密钥被破解） 引⼊对称加密之后,即使数据被截获,由于⿊客不知道密钥是啥,因此就⽆法进⾏解密,也就不知道请求的真实内容是啥了.

        但事情没这么简单.服务器同⼀时刻其实是给很多客⼾端提供服务的.这么多客⼾端,每个⼈⽤的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了,⿊客就也能拿到了).因此服务器就需要维护每个客⼾端和每个密钥之间的关联关系,这也是个很⿇烦的事情~

        ⽐较理想的做法,就是能在客⼾端和服务器建⽴连接的时候,双⽅协商确定这次的密钥是啥~

        但是如果直接把密钥明⽂传输,那么⿊客也就能获得密钥了，此时后续的加密操作就形同虚设了.因此密钥的传输也必须加密传输!

        但是要想对密钥进⾏对称加密,就仍然需要先协商确定⼀个"密钥的密钥".这就成了"先有鸡还是先有蛋"的问题了.此时密钥的传输再⽤对称加密就⾏不通了.

无法保证密钥被监听！

方案2-只使用非对称加密
 

​    鉴于非对称加密的机制，如果服务器先把公钥以明⽂⽅式传输给浏览器，之后浏览器向服务器传数据前都先⽤这个公钥加密好再传，从客⼾端到服务器信道似乎是安全的(第二点无法解决)，因为只有服务器有相应的私钥能解开公钥加密的数据。

但是服务器到浏览器的这条路怎么保障安全？

        如果服务器⽤它的私钥加密数据传给浏览器，那么浏览器⽤公钥可以解密它，⽽这个公钥是⼀开始通过明⽂传输给浏览器的，若这个公钥被中间⼈劫持到了，那他也能⽤该公钥解密服务器传来的信息了。

只能保证单向数据的安全！

方案3-双方都使用非对称加密
 

        服务端拥有公钥S与对应的私钥S'，客⼾端拥有公钥C与对应的私钥C'

        客⼾和服务端交换公钥

        客⼾端给服务端发信息：先⽤S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥 S'

        服务端给客⼾端发信息：先⽤C对数据加密，在发送，只能由客⼾端解密，因为只有客⼾端有私钥 C' 这样貌似也⾏啊，

        但是 • 效率太低 • 且依旧有安全问题(第二点无法解决)

效率低，并且无法解决数据被篡改的行为！

 

方案4-非对称加密+对称加密

        • 服务端具有⾮对称公钥S和私钥S'

        • 客⼾端发起https请求，获取服务端公钥S

        • 客⼾端在本地⽣成对称密钥C,通过公钥S加密,发送给服务器.

        • 由于中间的⽹络设备没有私钥,即使截获了数据,也⽆法还原出内部的原⽂,也就⽆法获取到对称密钥(真的吗？)

        • 服务器通过私钥S'解密,还原出客⼾端发送的对称密钥C.并且使⽤这个对称密钥加密给客⼾端返回 的响应数据.

        后续客⼾端和服务器的通信都只⽤对称加密即可.由于该密钥只有客⼾端和服务器两个主机知道,其 他主机/设备不知道密钥即使截获数据也没有意义.

        由于对称加密的效率⽐⾮对称加密⾼很多,因此只是在开始阶段协商密钥的时候使⽤⾮对称加密,后续的传输仍然使⽤对称加密

看似已经解决问题了，但是无法解决第二个数据被篡改的问题！

方案2，⽅案3，⽅案4都存在⼀个问题，如果最开始，中间⼈就已经开始攻击了呢？
 

中间人攻击-针对上面的四个方案场景
 

Man-in-the-MiddleAttack，简称“MITM攻击”
 

        确实，在⽅案2/3/4中，客⼾端获取到公钥S之后，对客⼾端形成的对称秘钥X⽤服务端给客户端的公钥S进⾏加密，中间⼈即使窃取到了数据，此时中间⼈确实⽆法解出客⼾端形成的密钥X，因为只有服务器有私钥S'
        但是中间⼈的攻击，如果在最开始握⼿协商的时候就进⾏了，那就不⼀定了，假设hacker已经成功成为中间⼈

1.服务器具有⾮对称加密算法的公钥S，私钥S'

2.中间⼈具有⾮对称加密算法的公钥M，私钥M'

3.客⼾端向服务器发起请求，服务器明⽂传送公钥S给客⼾端

4.中间⼈劫持数据报⽂，提取公钥S并保存好，然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M，并将伪造报⽂发给客⼾端

5.客⼾端收到报⽂，提取公钥M(⾃⼰当然不知道公钥被更换过了)，⾃⼰形成对称秘钥X，⽤公钥M加密X，形成报⽂发送给服务器

6.中间⼈劫持后，直接⽤⾃⼰的私钥M'进⾏解密，得到通信秘钥X，再⽤曾经保存的服务端公钥S加 密后，将报⽂推送给服务器

7.服务器拿到报⽂，⽤⾃⼰的私钥S'解密，得到通信秘钥X

8.双⽅开始采⽤X进⾏对称加密，进⾏通信。但是⼀切都在中间⼈的掌握中，劫持数据，进⾏窃听甚⾄修改，都是可以的

上⾯的攻击⽅案，同样适⽤于⽅案2，⽅案3 问题本质出在哪⾥了呢？客⼾端⽆法确定收到的含有公钥的数据报⽂，就是⽬标服务器发送过来的

无法解决数据被篡改的问题！我们只有解决这个问题才能安全的进行通信

补充8：引入证书

认识CA认证
 

 百度文库CA证书

关于CA机构这个是一个全球性的机构，在每个地区国家都可能会不一样，并且下面有很多子机构，为什么我们信任它其实就是基于信任链，并且这些机构是经过国家认证的合法机构，我们使用就是基于它的可信任 

        服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性，用以证明数据没有被篡改

 

        关于网络通信这里1~3步，只需要一次就可以了，后续只是在做4~6的步骤，通常证书会有期限的，到期了就失效了，这里的明文信息由申请者提供，交付给CA机构形成证书

        CA机构为了签发证书，CA机构也有自己的私钥和公钥，当然只有CA机构才知道私钥

证书的验证

当客⼾端获取到这个证书之后,会对证书进⾏校验(防⽌证书是伪造的).
• 判定证书的有效期是否过期
• 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
• 验证证书是否被篡改:从系统中拿到该证书发布机构的公钥,对签名解密,得到⼀个hash值(称为数据摘要),设为hash1.然后计算整个证书的hash值,设为hash2.⽐hash1和hash2是否相等.如果相等,则说明证书是没有被篡改过的.

整体替换必须要真的证书，否则游览器不认(内置的公钥无法解密)，但是一旦用真的证书，域名(唯一的)之类的一定会不同，并且甚至可以被肉眼看出来(访问的网站都不一样了)

 

这个证书可以理解成是⼀个结构化的字符串,里面包含了以下信息:

 证书发布机构
• 证书有效期
• 公钥
• 证书所有者
• 签名
• ......
需要注意的是：申请证书的时候，需要在特定平台生成查，会同时生成⼀对密钥对，即公钥和私钥。这对密钥对儿就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。
其中公钥会随着CSR文件，⼀起发给CA进⾏权威认证，私钥服务端自己保留，用来后续进⾏通信（其实主要就是⽤来交换对称秘钥）

CA证书的申请

这里的公钥在证书中就会被包含，私钥则需要服务端自行保存好，可以在线形成，也可以本地形成

可以使⽤在线⽣成CSR和私钥：https://myssl.com/csr_create.html
形成CSR之后，后续就是向CA进⾏申请认证，不过⼀般认证过程很繁琐，⽹络各种提供证书申请的服务商，⼀般真的需要，直接找平台解决就⾏

游览器内置的证书

 

只要是合法的常用的基本上浏览器都会内置证书

 

方案5-非对称加密+对称加密+证书认证

非对称加密：用以交换密钥

对称加密：用以通信

证书认证：用以证明数据未被篡改

基于这三点就可以实现网络通信的安全性了，具体实现参上

总结：有了方案5，就有了https，就可以了安全的网络通信，基于https的内容如果想要深入了解，去了解其中的生态，可能会有更加深的认识

补充9：常见问题

 

为什么签名不直接加密，而是要先hash形成摘要?
 

缩小签名密⽂的⻓度，因为摘要是固定长度的，加快数字签名的验证签名的运算速度，还有一点是有的算法对加密文本是有长度要求的，无法对大文本进行整体加密
 

如何成为中间⼈-了解
 

 • ARP欺骗：在局域⽹中，hacker经过收到ARPRequest⼴播包，能够偷听到其它节点的(IP,MAC)地址。例，⿊客收到两个主机A，B的地址，告诉B(受害者)，自己是A，使得B在发送给A的数据包都被⿊客截取
• ICMP攻击：由于ICMP协议中有重定向的报⽂类型，那么我们就可以伪造⼀个ICMP信息然后发送给局域⽹中的客⼾端，并伪装⾃⼰是⼀个更好的路由通路。从⽽导致⽬标所有的上⽹流量都会发送到我们指定的接口上，达到和ARP欺骗同样的效果
• 假wifi&&假⽹站等
 

加密总结

网络请求完整流程

 

左侧都是客户端做的事情,右侧都是服务器做的事情
 

 

HTTPS⼯作过程中涉及到的密钥有三组.

        第⼀组(⾮对称加密):⽤于校验证书是否被篡改.服务器持有私钥(私钥在形成CSR⽂件与申请证书时获得),客⼾端持有公钥(操作系统包含了可信任的CA认证机构有哪些,同时持有对应的公钥).服务器在客⼾端请求是，返回携带签名的证书.客⼾端通过这个公钥进⾏证书验证,保证证书的合法性，进⼀步保证证书中携带的服务端公钥权威性。

        第⼆组(⾮对称加密):⽤于协商⽣成对称加密的密钥.客⼾端⽤收到的CA证书中的公钥(是可被信任的)给随机⽣成的对称加密的密钥加密,传输给服务器,服务器通过私钥解密获取到对称加密密钥.

        第三组(对称加密):客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密.

        其实⼀切的关键都是围绕这个对称加密的密钥.其他的机制都是辅助这个密钥⼯作的.
        第⼆组⾮对称加密的密钥是为了让客⼾端把这个对称密钥传给服务器.
        第⼀组⾮对称加密的密钥是为了让客⼾端拿到第⼆组⾮对称加密的公钥.

 

至此应用层结束

套接字，请求报文的处理，序列化和反序列化，http&https等完成