Haulyn5 的博客
0%

SSM+19 论文阅读笔记

发表于 更新于 分类于 阅读次数： Valine：

前言

转眼已经进入2月，假期已经荒废了20余天，随着市区里的一例确诊病例，六线小县城也变得紧张焦虑起来。

接下来半年将是决定保研成败的关键时期，没有时间可以浪费了，由于暂时没有项目做，就刷 paper 扩展一下知识面先。由于小白也没什么筛选能力，就先从四大顶会（S&P, CCS, USENIX, NDSS) ，开始刷咯。

由于之前已经确定要做浏览器安全，Web安全，所以就直接跳过其他领域，直接找 Web 相关。

按照顺序从 S&P 开始，S&P 的 paper 被按照 session 分开。其中，Session 3: Web Security 与 Session 15: Web and Cloud Security 看到题目与我们的领域挂钩，于是从这里开始。

今天开始读第一篇 paper ：Does Certificate Transparency Break the Web? Measuring Adoption and Error Rate ， DOI: 10.1109/sp.2019.00027 .

正文

初读的问题

  1. 这篇论文做了什么？怎么做到的？做到了什么程度？

  2. 什么是 Certificate Transparency (CT) ？

    这里甚至有一个 CT 项目的官方网站 https://www.certificate-transparency.org/
    首页的视频貌似是 Facebook 支持的，这里是 YouTube 版本 https://youtu.be/6PrAVzjZeOI ， 要流畅一些。

  3. 什么是 OCSP Stapling？

    OCSP（Online Certificate Status Protocol，在线证书状态协议）是用来检验证书合法性的在线查询服务，一般由证书所属 CA 提供。某些客户端会在 TLS 握手阶段进一步协商时，实时查询 OCSP 接口，并在获得结果前阻塞后续流程。OCSP 查询本质是一次完整的 HTTP 请求 - 响应，这中间 DNS 查询、建立 TCP、服务端处理等环节都可能耗费很长时间，导致最终建立 TLS 连接时间变得更长。

    而 OCSP Stapling（OCSP 封套），是指服务端主动获取 OCSP 查询结果并随着证书一起发送给客户端，从而让客户端跳过自己去验证的过程，提高 TLS 握手效率。

    从无法开启 OCSP Stapling 说起 Jerry Qu https://imququ.com/post/why-can-not-turn-on-ocsp-stapling.html

  4. TLS 和 SSL 都有什么区别？
    详解 HTTPS、TLS、SSL、HTTP区别和关系

  5. 什么是 Signed Certificate Timestamp (SCT) ?

    Basic Log Operations

    Anyone can submit a certificate to a log, although most certificates will be submitted by certificate authorities and server operators. When someone submits a valid certificate to a log, the log responds with a signed certificate timestamp (SCT), which is simply a promise to add the certificate to the log within some time period. The time period is known as the maximum merge delay (MMD).

    https://www.certificate-transparency.org/how-ct-works

  6. 多次看到的 Alexa Top？https://www.alexa.com/topsites

  7. 什么是 TLD？ Top Level Domain。顶级域。

  8. 什么是 EV certificate ？Extended Validation (EV) ，在 Chrome 中会有额外的UI
    image-20200206135259573

初读

看完了 Abstract、Introduction 和 Background ，大致过了一下 Methodology 。

这又是一篇 Google 发的 Paper，想起前不久刚刚看一篇 USENIX 的 Google 发的 Site Isolation: Process Separation for Web Sites within the Browser , 都是以 Chrome 为跳板，做新功能的开发、用户以及实际使用数据的统计与调研。这种手笔的 Paper 想必也只有 Google 能发了，不过相比之下，同是浏览器界巨头的 Mozilla 好像就还没看到相关的顶会 paper （也许以后会删掉这段话哈哈哈）

这篇文章做的是对 Certificate Transparency 技术的实际应用情况等的研究，并以此为基础研究了如何在互联网范围内部署新的技术，总结经验与教训。其中 CT 技术用于提高证书安全性，在 Web 环境下即 HTTPS 网站证书的应用。

又将前面提到的讲座视频看完了，大致对 CT 技术有了概念。简明扼要的说，CT技术是为了解决人们对于 CA 的 Blind Trust，由于 CA 有被攻击或 Mis-issue （也许不是这么拼？大意就是错误颁发）证书的危险，单纯对于 CA 签名的一切证书盲目信任是有风险的，于是 Google 的科学家觉得应该把这个颁布证书的过程 Transparent，于是原来系统中 site owner, CA, Client 的简单变得复杂一点，新增一个 Certificate Logs (Operators)， Monitor 和 Auditor。CA对证书进行签名后，要将这个证书告诉 Logs ， 而Logs是一个 Append-Only 的 Merkle tree 结构。Logs 通常由 Big Tech Corporations 负责运营，讲座中提到了他们自己 Google 和隔壁 Facebook 在搞，毕竟这个数据量一般的小公司也吃不住，（碎碎念：讲座说早期 Google 甚至把 Merkle Tree 结构整个一直放在 RAM 里，而目前来看可能有点吃不住了哈哈哈），然后每个人都可以检查 Logs ， 比如一个 Site Owner 就可以看看自己网站的HTTPS 证书的公钥是不是自己的，或者是不是有人假注册了自己的网站，除此之外还会有安全研究人员等人担任 Monitor 的位置。不过考虑到一般的用户很有可能没有技术能力检索 Logs， Google 考虑后续可能会有大公司将检索 Logs 开发为一个 Service。（好像说的还是不够简明扼要哈哈哈）Auditor具体的一些工作我也没太深入，当然更具体的技术实现等等和一些细节就还是扔个官网吧，https://www.certificate-transparency.org/what-is-ct。

对这篇paper有了基本的了解后，感觉这篇 paper 主要还是帮助自己补充 HTTPS 相关的基本知识哈哈，后面的部分将不再逐词逐句的阅读，取关键部分过一下提取出来就好了。

泛读

方法、数据收集

Major CT enforcement milestones in Chrome

于是作者团队为了检查 CT 技术如今实际的应用情况，首先收集各个来源的数据。

  1. Chrome 的使用数据
  2. 证书错误报告
  3. 收集不同定位的网站，检查 web 服务器支持情况（Alexa Top 10000，“Chrome User Experience Report,” January 2018, https://developers.google.com/web/tools/chrome-user-experience-report/，HTTP Archive）
  4. CT logs （36 个 well known 的 logs 的快照）
  5. Chrome product help forums

应用情况

根据 Chrome 的统计，有71.1% 的 HTTP 连接是 CT-compliant. 63.2% 的 HTTPS 连接是 CT-compliant.

服务器对CT的支持情况如下表，来源论文。

HTTPS CT-compliant
(out of HTTPS)		 Serves noncompliant
SCTs (out of HTTPS)
Alexa Top 10k 73.0% 54.0% 0.2%
CrUX Report 39.3% 36.0% 0.1%
HTTP Archive 54.8% 43.2% 0.1%

用户影响

Chrome 中的SCT验证过程用时：在统计中，99%的验证用时在13ms以下，平均1.9ms，中位数1.1ms。 相比之下 证书验证 平均用时88ms，中位数14ms。

错误对用户的影响

  1. Error Clickthrough : 其实就是所谓的无视警告，继续访问。In the week ending July 2, 2018，Chrome 67，该类用户比例为 47.8%， 有趣的是，当用户们看到 钓鱼和恶意软件的警告时，无视警告的比例为 4.9%, 而整体所有可以无视警告的证书错误跳过率是28.0%，哈哈哈大家都不傻，而且可能感觉CT警告不重要）
  2. 受影响无法访问的网站：新版 Chrome 中 Top 10 中，Top 8 是 Gov 网站。

哈哈哈看到了说很多用户吐槽 CT 错误让他们无法办公，决定换浏览器哈哈哈，对于很多人，安全果然没有工资重要。

风险

Log disqualification or distrust

因为 CT 对 log 还是有一定要求的，所以如果一个log 不能满足要求了，就要被从 Chrome 的信任名单中除名。根据 log 遇到的各种情况，Chrome 会采取不同对策，此处不作详述。当 log 不再值得信任的时候，上面的证书等等也要做操作，总是还是挺麻烦的。

Server-side SCT serving

有的网站选择自己提供 SCT ，而不是让他们的CA提供嵌入 SCT 的证书，或者将SCT 放到 OCSP 响应中。主要原因是为了避免把 SCT 发给没有声明自己支持 CT 的客户，这样可以节省带宽。但是这又带来了各种安全问题，如具体实现的问题，使用 SCT 是否来自不可信任的 log 。

讨论 ： 设计原则

这一部分讨论了使得 CT 技术在应用的过程中导致尽可能少的 breakage 的原因。

相当少的先行者( First Movers)

大致就是说 CT 的覆盖主要依托于 少量大 CA 的行动， 普通站长完全可以不懂这个技术，也什么都不需要做。作者还提到了一个HPKP，但是由于大家都不会配置， Chrome 将这项技术废弃了。

HTTP Public Key Pinning(HPKP). HPKP allows sites to “pin” their connections to individual public keys, mitigating the site’s vulnerability to a CA compromise [46]. HPKP is notoriously difficult for site owners
to implement correctly [47]–[49]. Perhaps as a result, HPKP has seen very low adoption across the web [50], contributing to Chrome’s recent decision to deprecate HPKP [51].

分阶段的强制要求

分阶段的 Enforcement 使得可以较早发现解决问题。

浏览器策略

对于不同的 Log 的问题做不同的合适处理等。

讨论 ： 部署的问题

依赖 Major Player 的赞助

CT 的成功不得不说是 Google 和 Cloudflare 两家大厂在后面撑腰，作者也说，如果没有这两大帮助，CT 可能不能得到如此广泛的应用。如果新的一个 Idea 没有得到金主的帮助，很有可能凉。

极大的实现投资

说白了就是新功能实现太麻烦了，而且往往随之而来的是数不清的bug。作为一个开拓者太难了，论文的前面也提到，有的用户一看报了 CT 的错误，也不想怎么解决，就换了个浏览器。（隔壁 Mozilla 偷笑）

不过，论文就 Mozilla 没有成功实现 CT 技术在全文两个部分连着嘲讽两次哈哈哈。

​ Initial implementation can be a substantial engineering effort. For example, Firefox’s experimental CT implementation has been disabled by default for over a year due to unresolved regressions [33]. Firefox developers have expressed concerns about whether the security properties of CT are valuable enough to warrant this investment [54].

开放性问题

审计问题

CT 设计时考虑到了 Log 的审计，但是目前还没有广泛使用的技术可以做这个审计。广泛使用的审计会 reveal 两类问题：第一会发现一部分 misbehavior 的 log，导致更多的 log disqualifications ，第二，会带来用户浏览兴趣隐私的相关问题，具体参见连接（好多东西）https://docs.google.com/document/d/1DY2OsrSJDzlRHY68EX1OwQ3sBIbvMrapQxvANrOE8zM/edit 。

名称修订

有些组织会希望将 log 的证书做一些修改，不展示完全的域名。因为一些子域名，例如内部公司主机名本身就是可以理解的秘密，或者比如 a.com 的公司计划造一个高达，如果 gaoda.a.com 这个域名被公之于众，也挺不好意思的。毕竟 CT 技术要求透明，这就遇到了一些问题。

用户反映

前面也有数据提到用户倾向于对 CT 报错直接跳过，长此以往带来的用户惯性是非常危险的，对互联网的安全生态也有威胁，所以如何调整和设计 WARN UI ，也是一个重要问题。

总结

这篇 paper 围绕 CT 技术来讲，研究了 CT 技术的应用现况，遇到的问题、风险，以及如何能尽可能的减轻新的安全技术带来的用户体验下降，最后总结了一些设计准则。目前来看，CT 技术已经得到了较为广泛的应用，并且尽可能少的 breakage ，但是用户倾向于面对 CT 错误铤而走险，是 CT技术面临的新的挑战。

杂谈

Merkel Tree

讲座提到 Certificate Transparency 的 Log 内部也是使用 Merkle Tree 进行维护，证书的哈希作为叶子节点，而后一层一层哈希上去。（ Merkle Tree Cow beer)

image-20200206122040047

同时讲座在最后提到了一个 Merkle Tree 的实现。https://github.com/google/trillian

image-20200206123819946