流量劫持

流量劫持：利用各种恶意软件，木马修改浏览器、锁定主页或不停弹出新窗口等方式，强制用户访问某些网站，从而造成用户流量损失的情形

原因

  1.网络链路本身不安全。网络链路牵扯到具体的网络协议，这些协议当中，有些从设计上就没有考虑安全问题，贻害至今；另有一些，在当时可能是安全的，但正所谓“没有绝对的安全”，随着计算力和攻击手段的发展，当时安全的协议如今可能已经变得不再安全。

  2.干扰安全链路，迫使链路降级到不安全的方案上。这一点可以归结到前面，但单独拿出来说，是因为很多攻击手段会利用这一点去做，导致我们的安全方案根本没有使用起来。

dns域名解析

    发起请求-》hosts文件-〉域名服务器(获取结果进行缓存)-》向顶级域名服务器进行查询(例如com域名服务器，net域名服务器) 最终解析成功后，对指定ip进行数据请求

如何污染dns解析达到流量劫持

    1.在用户设备上动手。这个主要是通过一些恶意软件实现的，比如早期一些流氓软件会 在用户本机篡改hosts文件，影响用户的搜索引擎工作。

    2.污染中间链路设备。由于 DNS 查询是基于 UDP 协议明文发送的，因此在任意中间设备上，比如路由器进行中间人攻击，修改 UDP 包的内容，就可以影响 DNS 的结果了。

    3.入侵 DNS 服务器。这是一种成本比较高的方案，看起来似乎很困难，但 DNS 是一种相对古老的技术，其服务软件的实现可能已经年久失修，别有用心的攻击者可以寻找一些缺乏维护的DNS 服务器，施行攻击。另外，有时 DNS 服务器上不止运行 DNS 软件，还会有一些其他的软件也在运行，比如同时也启动了 HTTP 服务等，这时攻击者也可以通过这些软件的漏洞来控制服务器，进而影响 DNS 的解析。由于 DNS的缓存和上下传递关系，一旦有 DNS 服务器被影响，就会一次影响很多用户的访问，因此非常危险。

    注：第一种和第三种的实施成本都比较高，但污染链路设备，在 Wi-Fi 普及而安全意识尚未普及的今天，是最容易得手的一种途径

如何抵御 DNS 投毒

    1.DNS over TLS。这种协议是在 TLS 协议之上传输 DNS 内容，有点类似 HTTPS 和TLS 的关系。

    2.DNS over HTTP。用 HTTP 协议来传输 DNS ，也是可以的。国内厂商当中对这种方案的支持较多。最简单的实现是使用一个 固定的 IP 地址作为域名服务器，每次不发生 UDP ，而是向这台服务器发送 HTTP 请求来获取解析结果。但通常很难签发相应的证书给固定 IP，因此也有些厂商自己对 HTTP 报文进行加密，从而防止这些解析结果再被中间人篡改。

    3.DNS over HTTPS。和第二点比较类似，只是协议由http替换成https

    注：由于浏览器没有暴露 DNS 相关的接口，这三种较为安全的 DNS 查询方式，都无法在前端当中得以使用。而 iOS 和 Android 开发者有机会使用其中的技术进行加强，但需要单独编写一些代码

防止 http流量劫持

    1.CSP（Content Security Policy）在 HTML 加载的时候，指定每种资源的 URL白名单规则，防止 XSS 的运行和数据外送

      缺点：

      (1)CSP 可以用在 HTTP 页面，这也是我们想在 HTTP 页面用它做防御的一个原因。但中间人攻击可以在链路上直接移除 CSP的相关标记，导致 CSP 全部失效。

      (2)CSP 规则设置比较复杂。不然也不会有一个网站专门用来查询和生成规则了。设置不当 很容易玩脱，会直接导致你的资源不可用。

      (3)影响动态创建脚本。CSP 存在的一部分意义就是阻止动态创建脚本这种行为，这是防御XSS 的一种办法。但同时市面上很多技术方案也是基于这种方式做的，比如一些统计 SDK之类的，甚至有些开发人员的开发模式即是如此。

    2.SRI(Subresource Integrity)

      读取资源标签中的integrity属性，将其中的信息摘要值，和资源实际的信息摘要值进行对比，如果发现无法匹配，那么浏览器就会拒绝执行资源

      缺点：

        (1)和 CSP 一样，当我们用在 HTTP 页面中时，中间人可以直接移除 SRI 的相关属性，这样就完全失效了。

        (2)动态创建的脚本时，除非单独在前端计算信息摘要，否则无法使用 SRI 。

        (3)如果中途因为某种原因修改了脚本内容而忘记了更新摘要值，那么会直接影响可用性。有些自作聪明的代理或资源托管服务器，会对 JavaScript 进行压缩或者混淆，而这个过程对开发者透明，这样也会导致可用性受到影响。

        (4)兼容性比较有限。 iOS Safari 的支持至少需要 iOS 11，在目前看来不是很理想，https如何工作（在http的协议上增加了ssl/tls）

HTTP、HTTPS、TCP、SSL/TLS 之间的关系是什么

      最底层的协议是 TCP ，HTTP 是直接基于 TCP 的；SSL/TLS 也是基于 TCP 的，而 HTTPS 则是基于 SSL/TLS 的SSL 其实是先于 TLS 出现的，后来又被规范成 TLS 协议

TLS

      (1)加密套件:TLS 握手时所要使用的加密组合

      TLS 握手时，客户端会首先向服务器发送自己所支持的加密套件供服务器去选择，服务器选出最合适的后再告诉客户端。选出的结果之所以称为“套件”，是因为这个加密不止一种，每种加密会用在不同的场合

      (2)密钥协商

       在加密套件选取完成之后，客户端和服务端就会开始进行密钥协商密钥协商，这个过程有时也被称为“密钥交换”，但其实在协商的过程中，交换的并不是密钥，而是 “生成密钥用的信息”。

      (3)证书体系

      仅仅有密钥协商也是不够的，因为这无法阻止中间人在 Alice 和 Bob 中间扮演传话的角色，分别和双方进行协商在密钥协商之前，双方还会互相确认身份，这是引入证书体系、 证书链等一系列措施的原因确定加密套件-》证书交换-〉密钥协商方式确定-》客户端从服务端获取加密数据

https相关的流量劫持

    (1)SSL strip

    在 HTTPS 协议建立之前，浏览器可能并不知道网站是基于 HTTPS 的，因此首先会去使用HTTP 协议来访问网站，然后再经由网站的跳转改为 HTTPS 协议。中间人在这个过程中，实际上可以屏蔽掉这个跳转响应，自己和网站服务器建立 HTTPS 连接，而继续和被劫持的浏览器之间使用HTTP 协议。如此一来，流量劫持就会退回到 HTTP 协议时的难度。

    方案：

      HSTS（HTTP Strict-Transport-Security）

      在HTTPS响应报文的头部中，增加一个名为Strict-Transport-Security的头，内容是这个头的有效期。当浏览器在 HTTPS 响应中看到它时，下一次浏览器会直接使用 HTTPS来进行请求。

      缺点：

        只有 HTTPS 的响应才会去识别 HSTS ，这是为了防止中间人攻击在 HTTP 上的影响。 第一次用户如果使用 HTTP 进行请求，那么首次进行跳转依然是需要服务器进行配合。二次访问时， HSTS 才会真正开始起作用。

    (2)FREAK 攻击

      SSL 曾经支持过一种不安全的加密方式，而某些漏洞可以巧妙地触发这种不安全加密。中间人能够在密钥协商中截获 RSA 加密的公钥，并通过暴力破解来逆推出私钥。一旦私钥被得出，该证书也就不再安全，后续的所有会话都会处于危险之中

cdn

    用户如何能被引导到 对应的CDN 服务器上

    这主要是依赖于 DNS 服务。用户要想知道一个域名具体对应的 IP 地址需要进行 DNS 查询。那么只要利用 DNS 服务，对不同地区的用户，返回不同的 IP 地址，就可以将流量导流至相应的 CDN 服务器。

CDN 与流量劫持

      劫持原因

        1.CDN 和用户之间，走的是 HTTP 协议，这种情况比较多见，解决起来比较容易，就是换成 HTTPS 协议

        2.服务器和 CDN 之间，以及 CDN 内部，是 HTTP 协议的，这样就比较头疼了。