论文阅读：Analyzing Third Party Service Dependencies in Modern Web Services

Analyzing Third Party Service Dependencies in Modern Web Services: Have We Learned from the Mirai-Dyn Incident?

IMC 2020

1 背景&目的

  目前web生态系统越来越依赖第三方服务，例如DNS、CDN。但是第三方服务并不总是安全的，例如2016年的Mirai Dyn攻击、2016的GlobalSign撤销错误事件、2019年的Amazon DNS DDoS攻击等。这些事件就引出了web生态系统的健壮性的问题：

• 除了这些个别事件，是否有其他类型的第三方服务也是影响流行web服务的潜在弱点？
• 网站和第三方供应商之间是否存在隐藏的传递性或间接依赖关系，涉及到集中度和第三方依赖程度？
• 在Dyn事件后，网站是否发生变化，是否减少了对第三方服务的依赖？

  本文的目的就是，基于这些问题，对Alexa top 100K的网站进行测量，且主要从基础设施的角度进行测量。即测量DNS、CDN、CA，同时不考虑DoH和DoT，因为它们部署得太少了。

2 问题范围&一些概念

2.1 问题范围

  上图显示了一个典型的web请求的生命周期。本文关注的第三方服务就在上图过程中。

1. 用户发起对example.com的请求，通过example.com的权威nameserver解析到它的IP地址。（网站的网络服务提供者是该网站的DNS记录的权威机构）
2. 请求被路由到example.com的web服务器上，如果example.com使用https，则它将会向客户端提供有CA颁发的SSL证书。
3. 客户端通过联系提供证书撤销列表服务的服务器（CRL分发点或CDP），或者向OCSP服务器询问证书状态来验证证书合法性。（CDP和OCSP由CA管理，其地址包含在证书里面）
4. 如果证书合法，客户端会向example.com请求内容，内容可能托管在CDN上。网站可能会从其他内容提供者那加载内容，例如javascript libraries、font等。

2.2 基本概念

  网站集合表示为 W = { w 1 , w 2 , ⋯   , w n } W=\{w_1,w_2,\cdots ,w_n\} W={w1​,w2​,⋯,wn​}
  这些网站使用的服务集合表示为 S = { s 1 , s 2 , ⋯   , s m } S = \{s_1,s_2,\cdots,s_m\} S={s1​,s2​,⋯,sm​}
  令$P^S$表示一种服务类型的所有供应商的集合

• 第三方依赖（Third-party dependency）：$w\in W$使用一个不同于自己的实体的服务
• 直接依赖（Direct dependency）：$w\in W$使用$p\in P^{s_1}$获得服务$s_1$，那么$w$直接依赖$p$。一个$p^{\prime }\in P^{s_2}$可能也使用$p$来获得$s_1$服务
• 间接依赖（Indirect dependency）：对于一个$w\in W$或$p\in P^{s_1}$，他们直接依赖$p^{\prime }\in P^{s_2}$，并且$p^{\prime }$直接依赖$p^{\prime \prime }\in P^{s_3}$，那么$w,p$间接依赖$p^{\prime \prime }$
• 关键依赖（Critical Dependency）：对于一个$w\in W$或$p\in P^{s_1}$，他们使用另外一个$p^{\prime }\in P^{s_2}$来获得$s_2$服务，如果$p^{\prime }$挂了之后$s_2$服务就对$w,p$不可见，则说$w,p$关键依赖$p^{\prime }$。换句话说就是依赖的唯一性。
• 服务提供者的集中度（Concentration of a service provider）： 计算直接/间接依赖于给定提供商的网站数量。例如，如果100个网站直接使用Dyn，而50个网站间接使用Dyn，则我们说Dyn的集中度为150。令$D_w^p$表示网站直接依赖的$p\in P^{s_1}$的集合，令$D_s^p$为所有服务类型$s\in S$的提供者的集合且这些提供者都直接依赖$p$。那么$C_p$为服务提供者的集中度，可计算如下：
  C p = ∣ f c ( D w p , D s p ) ∣ = ∣ D w p ∪ ⋃ s = 1 m ⋃ k ∈ D s p f c ( D w k , D s k ∖ { p } ) ∣ C_p =|f_c(D_w^p, D_s^p)|=|D_w^p \cup \bigcup_{s=1}^m \bigcup_{k\in D_s^p} f_c(D_w^k,D_s^k\setminus\{p\})| Cp​=∣fc​(Dwp​,Dsp​)∣=∣Dwp​∪s=1⋃m​k∈Dsp​⋃​fc​(Dwk​,Dsk​∖{p})∣
• 服务提供者的影响力（Impact of a service provider）：计算关键依赖于服务提供商的网站数量，例如如果有100个网站使用Dyn，其中80关键依赖它，那么Dyn对80个网站有影响。令$E_w^p$表示关键依赖于$p\in p^{s_1}$的网站集合；令$E_s^p$表示所有服务类型$s\in S$的提供者的集合且这些提供者关键依赖于$p$。那么$I_p$为服务提供者的影响力，计算为：
  I p = ∣ f i ( E w p , E s p ) ∣ = ∣ E w p ∪ ⋃ s = 1 m ⋃ k ∈ E s p f i ( E w k , E s k ∖ { p } ) ∣ I_p =|f_i(E_w^p, E_s^p)|=|E_w^p \cup \bigcup_{s=1}^m \bigcup_{k\in E_s^p} f_i(E_w^k,E_s^k\setminus\{p\})| Ip​=∣fi​(Ewp​,Esp​)∣=∣Ewp​∪s=1⋃m​k∈Esp​⋃​fi​(Ewk​,Esk​∖{p})∣

基于这些基本概念，就有了以下问题：

• 有多少网站关键依赖第三方供应商提供DNS、CDN和CA服务？
• 就供应商的影响而言，网络生态系统有多集中？就供应商的影响而言，网络中是否存在单点故障？
• 间接依赖对第三方依赖的盛行有什么影响，以及提供者的影响？
• 自从Dyn事件以来，在网站的关键依赖、服务提供商的集中度和服务间依赖方面，世界发生了怎样的变化？

3 测量方法

3.1 DNS测量方法

  DNS有两种测量方法：

1. 将TLD与nameserver进行匹配。（这种方法大多数情况很好，但如果服务提供商使用别名，那就会漏掉）
2. 将nameserver的SOA（Start of Authority Records）与网站进行匹配。（这种方法不是很好，因为很多情况下网站使用第三方nameserver）

综合两种情况，设计的测量方案：

3.2 CA测量方法

  与DNS类似，简单的TLD匹配工作得很好。测量方案：

另外要看一个网站是否关键依赖OCSP和CDP，本文使用的方法是查看是否开启了OCSP Stapling。

3.3 CDN测量

  大多数CDN使用CNAME重定向来将资源指向CDN。

• 可以查看一个网站的内部资源的CNAME重定向，并与CNAME到CDN的映射进行匹配
• 可以查看每个内部资源的AS编号，并将AS映射到流行的CDN

这就需要找到内部资源，使用phantomJS获取网站的登录页，并记录至少为页面上的一个对象提供服务的所有主机名。然后对页面的所有内部资源执行dig CNAME查询。

3.4 服务之间的依赖

  DNS、CDN、CA服务也会互相依赖，例如CA的OCSP和CDP以及CDN会依赖DNS解析IP；CA可能会使用CDN

4 测量结果

4.1 直接依赖

  直接依赖分析：

• 第三方依赖的普遍性
• 查看第三方供应商中网站的集中情况，并确定互联网中的单店鼓掌
• 对比Dyn 2016攻击之后和现在的第三方依赖状态

4.1.1 第三方依赖

1）小众网站对第三方DNS的依赖程度很高。top 100K网站中有89%依赖第三方DNS，85%是关键依赖；而top 100网站中有49%使用第三方DNS，28%是关键依赖。

2）DNS服务提供商的关键依赖，从2016到2020提高了4.7%

3）33.2%的网站使用CDN，更受欢迎的网站越不是关键依赖。对于关键依赖CDN的网站，top 100K占85%，top 100占43%

4）2016和2020年对CDN的关键依赖并没有重大改变

5）更受欢迎的网站对第三方CA的依赖程度越小

6）2016和2020年对CA的关键依赖并没有重大改变

4.1.2 服务提供者的集中度

7）4个DNS提供者是50%的top 100K网站的关键依赖，2个CDN是50%的使用CDN的网站的关键依赖，2个CA是50%的支持HTTPS的网站的关键依赖

8）2016到2020，DNS和CA的提供者集中度增加了，但是CDN提供者的集中度下降了

4.2 间接依赖

   间接依赖主要分析：

• 服务提供商之间是否存在关键依赖关系，就像网站一样
• 由关键的服务间依赖产生的间接依赖如何影响网站的第三方依赖，以及供应商之间的集中度

4.2.1 $CA\to DNS$ 依赖

9）当考虑$CA\to DNS$关键依赖时，72%的网站关键依赖3个DNS提供商，而只考虑$website\to DNS$依赖时，这一比例为40%

4.2.2 $CA\to CDN$依赖

10）当考虑$CA\to CDN$关键依赖时，56%的网站关键依赖3个CDN提供商，而只考虑$website\to CDN$依赖时，这一比例为18%

4.2.3 $CDN\to DNS$依赖

11）主流的CDN提供商使用私有DNS，因此 DNS提供商的影响几乎没有变化。

5 Case Study

  本文给了两个Case Study，还挺有趣的。

5.1 Hospital

  网络中断会阻碍医院运作，而实际上。2020年3月22日，新冠流行期间，巴黎医院管理局AP-HP遭到了DDoS攻击。此外2016年的Dyn攻击中，AthenaHealth和AllScripts也遭到中断，因为他们用了Dyn。

本文分析了美国前200家医院的第三方依赖分析

5.2 Smart Home Company

  智能家居服务的中断也会造成严重后果，本文分析了23家只能家居公司的第三方依赖，包括智能家居框架（如三星SmartThings、Yonomi等）、智能家居设备（如Lifx、Philips Hue等）。在这23家公司中，14家在本地和云端运营，9家智能家居公司仅在云端运营。

6 总结

  本文根据测量结果给出了一些建设性意见：

• 网站在使用第三方服务时需要增强弹性和冗余性，以及需要了解他们所使用的第三方服务隐藏的依赖性。
• 服务提供商应该支持并鼓励冗余，在使用其他第三方服务时也应该是透明的

  未来工作方面，包括合并分析网站之间的依赖关系，测量服务提供商的能力，以更好地描绘他们个人的弱点，设计一个防御度量，利用这些度量来评估一个网站的健壮性。

可以构建这样一种服务:给定一个网站，它可以分析其完整的依赖结构，并使网站管理员能够在选择新的服务提供商时做出明智的政策决定。

依赖分析可以扩展到研究服务级别的依赖关系，如支付处理器、消息传递平台、CRM等。

可以对电子商务、教育或政府部门等进行有趣的案例研究，分析它们对第三方的依赖。