计算机网络 | 网络安全 | HTTP & HTTPS | URI解析全过程

网络安全 & HTTPS

1.Http和Https

1.1 HTTP报文内容

• 请求报文和响应报文的结构如下

• 请求行：包含用于请求的方法，请求 URI 和 HTTP 版本。
• 响应行：包含表明响应结果的状态码，原因短语和 HTTP 版本。
• 可能包含 HTTP 的 RFC 里未定义的首部（Cookie 等）
  

1.2 HTTP的缺点

主要有三点，我们逐个击破：

1. 通信使用明文（不加密），内容可能会被窃听
2. 不验证通信方的身份，因此有可能遭遇伪装
3. 无法证明报文的完整性，所以有可能已遭篡改

• 以上三点可以用以下方式解决

• 安全电子邮件：PGP
• SSL+TSL

1.3 HTTP+ 加密 + 认证 + 完整性保护 =HTTPS（port：443）

• 概述

其实就是通过SSL（Secure Socket Layer，安全套接层）或 TLS（Transport Layer Security，安全层传输协议）的组合使用，通常HTTP直接与TCP通信，当使用SSL时，则先演变为SSL通信，再由SSL与TCP通信

• SSL和TLS的关系
  

1. 通信加密

• 概述

我们俗称的HTTPS，其实就是使用SSL建立安全通信线路，然后在这条线路上进行通信即HTTP over SSL

• 内容加密的弊端

就是将报文的主体进行加密，HTTP本身不加密，但是前提是要求客户端和服务器同 时具备加密和解密机制。主要应用在 Web 服务中。但是内容有被篡改的风险，稍后我们讲到加密的密钥就很清晰了

• 共享密钥加密方式（对称加密）

加密解密使用相同的密钥，但是密钥传输的过程会被别人监听，那么信息加密也就没意义了

• 公开密钥加密方式（非对称加密）

使用一个公开密钥和私有密钥，公开密钥可以被任何人获取，私有密钥只有自己知道，使用公开加密，私有解密；所以对于通信双方各自都要发一份公开密钥，因为双方都要有加密解密的能力

• 混合加密

因为公开相对于共享来说处理速度要慢一点，那么采用混合的加密，在建立连接之处使用公开密钥的方式去安全的传输共享密钥方式中要使用的密钥（使用公开密钥加密），然后安全的送达后使用共享密钥的方式通信

• 公开密钥加密方式的弊端

在最开始传输公开密钥的时候，这个公开密钥本身有没有被替换，是否为货真价实的公开密钥，为了解决我们引入数字证书认证机构CA

2. 证书认证

• 证书的结构

• 公钥；
• 持有者信息；
• 证书认证机构（CA）的信息；
• CA 对这份⽂件的数字签名及使⽤的算法；
• 证书有效期；
• 还有⼀些其他额外信息

• 概述

虽然使用HTTP不发确认通信方是否为我们期望的，但是使用SSL提供的证书就可以验证对方，证书是由第三方的可信赖结构颁发的；伪造证书是非常困难的。另外，客户端持有证书即可完成个人身份的确认，也可用于对 Web 网站的认证环节。

• CA机构业务流程

1. 服务器向机构申请公开密钥
2. 机构判明申请者身份
3. 会对已申请的公开密钥做数字签名（就是用机构自己的私有密钥进行加密的过程）
4. 然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书 后绑定在一起。
5. 服务器将这份证书发送给客户端
6. 客户端用认证机构的公开密钥（事前浏览器内部植入的）对证书进行验证，成功后明确两件事：①.这个公开密钥对应的数字认证机构是真实有效的②.服务器的公开密钥是值得信赖的
7. 拿到证书的公开密钥对报文进行加密传输
8. 服务器用自己的私有密钥进行解密
   

• 注意

上面过程中我们没有写具体是怎么对证书进行验证的例如第6步

• 证书链（信任链）

通常证书并不是由根证书（自签证书）签发的而是由中间证书（他签）签发的。，所以一般会一直想上寻找到没有上级签发机构的证书，说明它是根证书

3. 完整性保护

• 使用HTTP本身自带的完整性验证报文的方法（报文鉴别码）

这类方法大致使用MD5和SHA-1等散列验证校验的方法，使用起来并不便捷、可靠；可惜的是，用这些方法也依然无法百分百保证确认结果正确。因 为 PGP 和 MD5 本身被改写的话，用户是没有办法意识到的。

1.4 HTTPS的握手框架（RSA、ECDHE）

• 概述

我们握手框架里面的不同多办是由密钥构成的不同算法造成的， 常见的算法有RSA算法、ECDHE算法

1. RSA的流程

• RSA算法流程之第一阶段

1. 客户端发送Client Hello报文开始SSL通信，报文中含有客户端支持的SSL版本号、加密组件列表（使用的加密算法和密钥长度）、生成的客户端随机数（服务器用来生成对称密钥的材料之一）

• RSA算法流程之第二阶段

1. 服务器可以进行SSL通信时，会以Server Hello报文予以回应；和客户端一样在报文中加入自己的SSL版本，从客户端列表中选择的加密组件；然后对客户端来的SSL版本进行校验并生成自己的随机数并随之返回
2. 之后服务器发送Server Certificate报文给客户端，内容为公开密钥证书
3. 服务器发送Server Hello Done 报文通知客户端，最初阶 段的 SSL握手协商部分结束。

• 流程之第三阶段（体现混合加密）

1. 接着客户端发送Client Key Exchange 报 文作为回应，客户端会生成一个新的随机数（pre-master），用服务器的RSA公钥加密该随机数随着报文发出；服务器收到密钥用自己的RSA私钥解密，得出客户端的随机数，至此客户端和服务器都共享了三个随机数 Client Random、Server Random、pre-master。然后双方根据这三个随机数生成对称密钥，即会话密钥（master secret）
2. 客户端再发送Change Cipher Spec 报文，告诉服务器开始使用加密方式发送消息；之后的报文都会采用对称密钥进行加密
3. 接着客户端发送Finished 报文，将所有发送的数据做个摘要加密后发出去，让服务器做个校验，如果正确解密本次握手协商为成功

• 流程之第四阶段

1. 服务器同样发送Change Cipher Spec报文
2. 服务器发送Finished报文。如果双⽅都验证加密和解密没问题，那么握⼿正式完成。
   

• RSA的缺点

使⽤ RSA 密钥协商算法的最⼤问题是不⽀持前向保密。因为客户端传递随机数（⽤于⽣成对称加密密钥的条件之⼀）给服务端时使⽤的是公钥加密的，服务端收到到后，会⽤私钥解密得到随机数。所以⼀旦服务端的私钥泄漏了，过去被第三⽅截获的所有 TLS 通讯密⽂都会被破解。

2. ECDHE的流程

• 与RSA的流程区别（大致有两个区别）

• 在第二阶段末尾多了个Server Key Exchange报文

这个报文就是在服务器发送完自己的证书后，开始做了三件事来填充这个报文内容

• 选择了椭圆曲线，选好了椭圆曲线相当于椭圆曲线基点也定好了，这些都会公开给客户端；
• ⽣成随机数作为服务端椭圆曲线的私钥，保留到本地；
• 根据基点和私钥计算出服务端的椭圆曲线公钥，这个会公开给客户端。

之后在第三阶段中

1. 客户端先验证其证书等正常流程，之后客户端会⽣成⼀个随机数作为客户端椭圆曲线的私钥，然后再根据服务端前⾯给的信息，⽣成客户端的椭圆曲线公钥然后⽤Client Key Exchange报文发给服务端。
2. 至此最终会话密钥的构成为：客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥，通过椭圆曲线，椭圆基点，对方公钥和自己的私钥计算x坐标得到）
3. 之后同理会采用对称密钥来通信

1.5 Http的get和post区别

1 HTTP方法

• 概述

这些方法总的而言就是告诉服务器自己的需求

• get方法：获取资源

get方法用来获取请求访问已被URI识别的资源，指定的资源服务器解析请求报文后返回响应内容。如果是请求的资源为文本则保持原样返回（像CGI：通用网管接口，则需要处理后返回）

• post：传输实体主体

post方法用来传输实体的主体，虽然用 GET 方法也可以传输实体的主体，但一般不用 GET 方法进行 传输，而是用 POST 方法。虽说 POST 的功能与 GET 很相似，但 POST 的主要目的并不是获取响应的主体内容。

• put：传输文件

put用来传输文件，就向FTP协议的文件上传一样，要求在请求主体中包含文件内容，然后保存到URI指定的位置，在1.1中任何人都可以不带验证机制的上传容易安全性问题，但是Rest风格下会开放使用

• head：获取报文首部

不返回主体，用于确认URI的有效性及资源更新的日期时间，就是少了主体的get

• delete：删除文件

就是通过指定的URI删除文件，同样不带验证机制，可配合Rest风格使用

• options：询问支持的方法

对于请求URI指定资源的支持方法

• trance：追踪路径

在发送请求时会在Max-Forwards，每经过一个服务器-1，到0停止传输；如果请求方接收到请求的响应200则成功；不怎么用因为容易引发安全问题

• connect：要求用隧道协议连接代理

该方法向代理服务器申请建立隧道，然后与服务器需要建立隧道（TCP+SSL+TLS），协议用来加密，然后隧道用来传输

• 1.0 与 1.1 之间请求方法的区别
  

2.GET和POST的区别

• 概述

我们可以差分成三个层面来讲这个区别：

1. 对于传输层来说：都使用TCP来传输，那么直接跳过没有区别
2. 对于浏览器发送请求给服务器
3. 对于接口中接收get或post方法
4. 在 HTTP 协议层面

1. 对于浏览器发送请求给服务器

我们针对于几个点进行说明

• 幂等性：Get是幂等性的；而Post不是。这是因为从下面后退刷新和缓存中能看出，Get方法使用完对双方都没有什么区别，而Post重新刷新意味着重新提交，可以改变服务器行为的，即不是幂等性
• 安全：两者其实都是明文，但是Get的请求参数是跟在URI后面的，而Post的数据不会在在URI中显示，并且Post参数无法被缓存从日志信息上也无法查看

2. 对于接口中的Get和Post

对于接口中的相互传递，其实就是使用了HTTP的大框架，没有向浏览器和服务器之间有那么多限制，只要符合HTTP格式就能发；

在Rest风格中：

• get被定义为：【GET】 + 【资源定位符】被专用于获取资源或者资源列表，
• post被定义为：【POST】+ 【资源定位符】则用于“创建一个资源”
• 另外的put、delete等都差不过；这里简单提一嘴put和post的区别：其实就是更加完善的post

3. 在 HTTP 协议层面

• GET 只会发送一个TCP数据包，将首部和实体数据一起发送，然后服务器进行响应。
• 而 POST 会先将数据包的首部发送，服务器响应 100 continue，然后继续发送实体部分，服务器进行处理。也就是总共会发送两个 TCP 数据包。

3.post请求，客户端如何知道请求已经到达服务端了？

• 概述

查看响应报文就可以了，开发大多使用前端使用AJAX调用后端响应接口，那么直接查看AJAX的回调函数中的数据和状态码是否是自己想要的就可以了

4.不写不做任何操作可以用post吗

• 概述

实际上肯定是可以的，但是在规范中大多使用get来完成这样的操作，因为post无论有没有操作，对于服务器都是一次提交而不像get可以使用缓存，而post的重复提交又会时服务器重复处理等，所以还是建立用get

1.6 HTTP版本的变迁

HTTP/1.0与HTTP/1.1的对比

• HTTP/1.1 相⽐ HTTP/1.0 性能上的改进：

• 使⽤ TCP ⻓连接的⽅式改善了 HTTP/1.0 短连接造成的性能开销。
• ⽀持管道化⽹络传输，只要第⼀个请求发出去了，不必等其回来，就可以发第⼆个请求出去，可以减少整体的响应时间。
• 支持断点续传，也就是通过标记来进行分块传输。例如一次文件上传中途断网失败，下次可以从切断位置继续上传，通过指定Content-Range字段来表示从文件流的什么位置开始读取。

• HTTP/1.1 的缺陷

• 请求 / 响应头部（Header）未经压缩就发送，⾸部信息越多延迟越⼤。只能压缩 Body 的部分；
• 发送冗⻓的⾸部。每次互相发送相同的⾸部造成的浪费较多；
• 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端⼀直请求不到数据，也就是队头阻塞，没有请求优先级控制；
• 请求只能从客户端开始，服务器只能被动响应。

• HTTP/1.1 的优化

• 使用缓存，减少发送HTTP请求。
• 减少重定向次数，将重定向交给代理。
• 合并请求，将一些小请求合并成一个大请求。
• 延迟放松请求，对于一些暂时用不到的请求延迟发送。
• 压缩响应的资源

HTTP/2.0

• HTTP/2 相⽐ HTTP/1.1 性能上的改进：

1. 头部压缩

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是⼀样的或是相似的，那么，协议会帮你消除重复的部分。这就是所谓的 HPACK 算法：在客户端和服务器同时维护⼀张头信息表，所有字段都会存⼊这个表，⽣成⼀个索引号，以后就不发送同样字段了，只发送索引号，这样就提⾼速度了。

2. ⼆进制格式

HTTP/2 不再像 HTTP/1.1 ⾥的纯⽂本形式的报⽂，⽽是全⾯采⽤了⼆进制格式，头信息和数据体都是⼆进制，并且统称为帧（frame）：头信息帧和数据帧。增加了数据传输的效率。

3. 数据流

HTTP/2 的数据包不是按顺序发送的，同⼀个连接⾥⾯连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。客户端还可以指定数据流的优先级。优先级⾼的请求，服务器就先响应该请求。

4. 多路复⽤

HTTP/2 是可以在⼀个连接中并发多个请求或回应，⽽不⽤按照顺序⼀⼀对应。降低了延迟，⼤幅度提⾼了连接的利⽤率。

5. 服务器推送

HTTP/2 还在⼀定程度上改善了传统的「请求 - 应答」⼯作模式，服务不再是被动地响应，也可以主动向客户端发送消息。

• HTTP/2 的缺陷

多个 HTTP 请求在复⽤⼀个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以⼀旦发⽣了丢包现象，就会触发 TCP 的重传机制，这样在⼀个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。

HTTP / 3 的改进

• 由于是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！
• 基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

2.可能遭遇的攻击

2.1 Dos（Denial of Service，拒绝服务攻击）攻击之SYN泛洪攻击

• 概述

Dos攻击就是指攻击是一大类攻击的总和，目的在于使用大量的请求，耗尽服务器的资源，导致停止服务或者实质下线。

• SYN泛洪攻击

我们说到当第二次握手时，服务器就会对连接进行分配资源，那么在这种机制下攻击者发送大量的 TCP SYN 报文段，而不完成第三次握手的步随着这种 SYN 报文段纷至沓来，服务器不断为这些半开连接分配资源(但从未使用) ，导致服务器的连接资源被消耗殆尽。

• 解决

解决方式就是SYN COOKIE，工作方式如下

• 当服务器收到一个SYN时，由于不知道其合法性，所以不会为其创建资源，不维持这个半连接状态
• 然后服务器生成自己的初始序列号，序列号由源和目标IP和端口以及仅有服务器知道的盐值三者构成的一个散列函数得到的，服务器会将此序列号填入首部【序号字段】，然后回应SYNACK报文段，并且服务器不记录cookie或SYN信息
• 如果客户端合法，回应的ACK报文段中的确认字段就是用相同散列函数以及相同数据算出的cookie值+1，那就建立连接
• 如果没有返回一个ACK，服务器也没有为其分配资源

2.2 XSS（跨站脚本）攻击

• 概述

大致就是服务器没有对用户的输入做严格的限制，当用户输入恶意的代码就在会网页发生意想不到的效果
!!!

• 类型

• 反射型XSS：即需要通过用户访问特定的连接，才能对Web页面插入非法脚本，从而进行一些恶意操作。攻击相当于是一次性的。
• 存储型XS：把对应的恶意脚本存储到数据库中，每当访问页面都会从数据库中取出执行，例如在留言中插入恶意脚本，每次访问留言板都会执行。

• 如何防御

• 就是编写代码更加规范，对于输入的要进行校验等
• 对于 URL 请求进行过滤，阻止恶意脚本的插入。
• 对于网页展示的形式进行编码，使得特殊写入的脚本无法执行。

2.3 XST攻击

• 概述

XST攻击就是利用cookie的机制获取用户信息（通过Trace和Track），由于存在跨域无法传输的情况，所以XST攻击主要就是解决怎么跨域传输信息；例如，在abc.example.com下的页面，不能向def.example.com提交Ajax请求。
!!!

• 解决

杜绝 XST 非常简单，Web 服务器限制 Trace、Track 方法的请求即可。另如今， XMLHTTPRequest 已经杜绝了 Trace 与 Track 方法的请求（Chrome 25 版本及 FireFox 19 之后），如果尝试用 Trace / Track 方法请求，会抛出 SecurityError 异常，这也从根本上杜绝了 XST 攻击。

2.4 CSRF

• 概述

CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。

通俗的来说，就是攻击者盗用你的身份，以你的名义发送恶意的请求，例如，你登陆了某个网址，浏览器保存了对应的 Cookie，然后在没有登出，即 Cookie 没有过期的情况下访问另一个危险网站，该网站带着你的 Cookie 访问对应网站进行一些有害操作。

目前最普遍的解决方法是，使用一个 Token，在自己访问的时候请求会带上这个 Token 进行访问，而危险网站的访问并不存在该 Token 则为非法操作，Token 可以在一个 hidden 的表单中提交等，不存在与 Cookie 中，所以危险网站一般情况无法获取。

从输入网址到网页显示发生了什么？

引流！！

转载：https://blog.csdn.net/weixin_49258262/article/details/125433883