2017IMC-Mission Accomplished? HTTPS Security after DigiNotar

本文链接：https://blog.youkuaiyun.com/qq_35324057/article/details/111875311

背景

有关

知识点

看一篇论文的基础是先把基础知识搞明白，在这片论文中主要涉及CT、HSTS、HPKP、CAA、SCSV和TLSA。

HSTS

HSTS 于2012年11月发布RFC 6797。

国际互联网工程组织IETE正在推行一种新的Web安全协议全称为：HTTP Strict Transport Security。采用该协议的网站将保证浏览器始终链接到该网站的HTTPS加密版本，而不需要用户手动输入加密地址，该协议将帮助网站采用全局加密，使得用户看到的版本就是该网站的安全版本。说白了，就是强制让客户端的服务器采用HTTPS链接。从此服务器端再也不要再进行重定向操作了。

开启：当客户端发起HTTPS请求后，服务端返回的超文本传输协议响应头中包含 Strict-Transport-Security字段，如：Strict-Transport-Security: max-age=31536000; includeSubDomains 这说明：① 在未来的 31536000秒（一年）内，HSTS 都是生效的，即该域名的 http 请求都将自动转为 https 请求；② includeSubDomains 意味着该域名下的所有子域名也都会采用 https 请求。

HPKP （HTTP Public Key Pinning）

HTTP公钥锁定是一种安全功能，也是用来防范由「伪造或不正当手段获得网站证书」造成的中间人攻击。2015年标准化为RFC 7469
字面意思就是将指定的证书公钥钉在HTTP头部，通过HTTP头部设置，要求客户端只接收网站指定CA签发的证书，如果没有接收到指定的CA证书，它将拒绝创建连接。
HPKP 技术给予我们主动选择信任 CA 的权利。它的工作原理是通过响应头或者标签告诉浏览器当前网站的证书指纹，以及过期时间等其它信息。未来一段时间内，浏览器再次访问这个网站必须验证证书链中的证书指纹，如果跟之前指定的值不匹配，即便证书本身是合法的，也必须断开连接。里面包含过期时间以及是否包含子域，还有证书指纹。
一般证书指纹被指定为中间证书生成指纹，这样最合理，具体分析看参考网站。

参考：https://imququ.com/post/http-public-key-pinning.html

CT（Certificate Transparency）

参考：http://www.certificate-transparency.org/how-ct-works

证书透明度，为了发现CA签发的非法证书，解决诸如：域名所有者的管理不善导致域名配置被第三方控制，从而第三方能够向CA申请你网站的证书。由谷歌主导在2013年标准化为RFC 6962。目标是提供一个开放的审计和监控系统，可以让任何域名所有者或者CA确定证书是否被错误签发或者被恶意使用，从而提高HTTPS网站的安全性。
整套系统由三部分组成：Certificate Logs；Certificate Monitors；Certificate Auditors
证书所有者或者 CA 都可以主动向 Certificate Logs 服务器提交证书，所有证书记录都会接受审计和监控。支持 CT 的浏览器（目前2016年只有 Chrome）会根据 Certificate Logs 中证书状态，作出不同的反应。CT 不是要替换现有的 CA 设施，而是做为补充，使之更透明、更实时。

启用CT的三种方式：

通过X.509v3 扩展
CA 先预签证书，并将证书提交到 CT Logs 服务器得到 SCT 信息，然后 CA 将 SCT（signed certificate timestamp） 做为预签证书（precertificate）的扩展再次签名，这样就得到了一个含有 SCT 扩展的证书。
通过TLS扩展
简单概括为TLS中由对应的扩展signed_certificate_timestamp传递SCT信息，客户端在client hello中启用该扩展，则服务器也给出相应。前提是服务器已经拥有SCT。
通过 OCSP Stapling
CA 按照普通流程完成证书签发后，再将证书提交到 CT Logs 服务器得到 SCT，然后改造OCSP（Online Certificate Status Protocol，在线证书状态协议）服务，将 SCT 信息包含到 OCSP 响应中。服务端启用 OCSP Stapling（OCSP 封套）后，就可以在证书链中包含证书的 OCSP 查询结果，其中就包含 SCT 信息。
OCSP是一个在线查询接口，浏览器可以实时查询单个证书的合法性。

三部分的作用以及关系：

在这里插入图片描述

Certificate Logs：可以理解为SCT颁发者，证书存储者，一旦颁发SCT，在整个证书的生命周期中都将伴随证书。证书不能删除，修改或追溯插入日志
Certificate Monitors（证书监控）：监视器监视日志中的可疑证书，例如非法或未授权的证书，异常的证书扩展名或具有奇怪权限的证书（例如，CA证书），
Certificate Auditors（证书审核）：会验证日志的整体完整性。会查询特定证书是否在证书日志中。也可以理解为当server发送sct给client时，client通过证书审核者对SCT进行验证。

还需要验证其对特定日志的看法与其他监视器和审计员的观点一致，所以他们之间也需要通信。

CAA

创建了一种DNS机制，该机制使得域名所有者可以将所允许为其主机名颁发证书的CA列入白名单。2013年标准化为RFC 6844指定授权CA为其域名签发证书，签发时会检查CAA记录，如果未获得授权则。
一般有几个关键词：

Issue：指定颁发证书的CA
Issuewild：用于限制通配证书的颁发
Iodef：用于在出现问题时为通知提供支持，指定证书颁发机构可以向其报告策略违规的URL。

参考：https://blog.qualys.com/product-tech/2017/03/13/caa-mandated-by-cabrowser-forum?_ga=2.87305119.608328144.1606733224-720590712.1595059180

TLSA

TLS身份验证记录（TLSA）用于将TLS服务器证书或公共密钥与找到该记录的域名相关联。使用TLSA记录，您可以将TLS / SSL证书的指纹存储在域的DNS中。
TLSA记录保存证书关联数据，并用于指定域的TLS服务器中使用的密钥。

该记录的RR数据字段具有四个数据字段：

证书使用情况字段
选择器字段
匹配类型字段
证书关联数据

例子：

3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

证书使用情况：指定如何验证证书。

0：CA约束，建立TLS时提供的证书必须由列出的根CA或其中间CA之一颁发，并且具有进行验证的应用程序已经信任的根CA的有效证书路径。该记录可能仅指向中间CA，在这种情况下，此服务的证书必须通过此CA来进行，但是到受信任的根CA的整个链仍必须有效。
1：服务证书约束，所使用的证书必须与TLSA记录完全匹配，并且还必须将PKIX认证路径验证传递给受信任的根CA。
2：信任锚声明，所使用的证书具有指向该记录中提及的证书的有效证书路径，但是不需要将PKIX证书路径验证传递给受信任的根CA。
3：域颁发的证书，服务使用自签名证书。它没有任何其他人签名，并且正是此记录。

选择器：连接到服务并收到证书时，选择器字段指定应检查的部分。

0：表示选择要匹配的整个证书。
1：表示仅选择用于证书匹配的公钥。匹配公用密钥通常就足够了，因为这很可能是唯一的。

匹配类型：

0：类型表示所选的全部信息都存在于证书关联数据中。
1：表示对所选数据进行SHA-256哈希。
2：意味着对所选数据进行SHA-512哈希处理。

证书关联数据：给定其他字段的设置，要匹配的实际数据。这是十六进制数据的长“文本字符串”。

SCSV（Signaling（发信号） Cipher Suite Value）

用于协议降级攻击，为了解决传统服务器的互操作性问题，许多TLS客户端实现不依赖于TLS协议版本协商机制，而是在初始握手尝试失败时有意使用降级协议重新连接。这样的客户端可能会退回到它们宣布版本低至TLS 1.0（或甚至其前身的安全套接层（SSL）3.0））的连接，作为最高支持版本。

除了协议降级之外，还有其他技术能够迫使浏览器客户端回退到较旧的TLS版本，包括：网络故障、欺骗性TCP RST数据包、缺少响应等。

参考：https://blog.youkuaiyun.com/u010129119/article/details/77665925

CT

得出的一些结论：

sct几乎在证书中全部存在
支持TLS扩展和OCSP的sct仅仅占很小一部分
支持OCSP的部分可能是出于用户的需求
供应商自2014年以来，没有显著变化，且主要的带头人是google

HSTS AND HPKP

在主动扫描中，作者通过发送HTTP HEAD请求来探测HSTS和HPKP报头的服务器。
并统计以HTTP 200回应的域名。并将两者结合起来一起分析，因为都是存在于http包头中。

在这里插入图片描述

统计当前的支持这两项的域并与互联网巨头所推出的一些名单做对比，并对这些域名做了测量以及进一步探究。主要是对这两项的一些特性进行统计分析，观测其是否偏离标准，发现问题。

作者是在多个地方对同样的域范围进行扫描，在这两项中，他首先分析对比不同地方扫描的差异，不一致的地方主要是：HSTSmax-age、includeSubDomains,HPKPpins 对应不同的 key。并给出三点原因：

不是在同一时间进行扫描的
不同的ip配置，比如任意广播服务
负载均衡器与不一致配置的服务器。

后续作者只对在不同扫描中提供相同HTTP报头的域进行统计分析。

HSTS：
max-age设置为”0“，非数数值，空值

在这里详细解释一下HPKP具体细节：

当一个站点开启此功能后，则在需要通过HTTPS访问站点时返回Public-Key-Pins HTTP标头：

Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime [; includeSubDomains][; report-uri="reportURI"]

pin-sha256
引用的字符串是Base64编码的主题公钥信息（SPKI）指纹。可以为不同的公钥指定多个引脚。
max-age
浏览器应记住仅使用其中一个已定义的密钥访问此站点的时间（以秒为单位）。即该header的存活时间。
includeSubDomains（可选）
表明此规则同样适用于所有站点的子域。
report-uri（可选）
若指定此参数，则会将引脚验证失败报告给给定的URL

例子：

Header always set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains"

HPKP：存在一些没有给定有效的max-age，还有不包含pins

还讨论了，同时支持两者的情况，比如支持HSTS的子域中又支持HPKP，然后作者统计了这类情况的max-age生存期长短的占比。

在这里插入图片描述

还有includeSubDomains中如果子域不支持HTTPS那么将会很困难。

Public Key Pinning：这一步主要分析HPKP中的pins了，存在一小部分无效的pins是在握手过程中缺失了证书，这些证书是被浏览器接受的，但是被违背了TLS标准。还有一部分是提供了错误的pins，可细分为没有匹配的证书和无效的哈希值，包括格式不满足等等。

作者还对TOP 1M内的域名做了统计分析，在TOP10K，TOP1K等域范围中两者的支持情况。同时与前人的工作做了对比。

SCSV(降级预防)

当第一次连接server失败，并且向通过更低的TLS版本再次连接server时，client会在自己的密码套件中添加scsv密码套件，当server收到该密码套件时，会进行判断：如果client所支持的最高版本低于自己所支持的最高版本，那么会abort：放弃连接

作者统计了几种情况，1，正确放弃连接，发送给client，alert消息。2，因为一些瞬态错误，如：timeout。3，server端发生了错误

结论

不支持SCSV的Alexa前100列表中的7个域中的5个来自Microsoft，并根据HTTP头使用IIS。

同时在被动收集的数据集中也出现了使用SCSV的情况。

继续正常连接的比例很低，放弃的连接的比例很高，alexa前100万网站中的覆盖率超高，因为密码库的原因。

基于DNS的保护手段

其中有两个记录可以用来帮助证书的发放和核实。DNSSEC，它是对DNS提供给DNS客户端（解析器）的DNS数据来源进行认证，并验证不存在性和校验数据完整性验证，但不提供机密性和可用性。
在这里插入图片描述
这张图是两者整体上的解析结果，里面的signed代表DNSSEC的签名

CAA

首先CAA的具体细节在前面的预备知识已经讲过了，主要有三个关键词：issue、issuewild、iodef。作者从这三点出发，统计分析了具体的信息。

比如，在issue中统计了在.com,.de,.net等中的占比以及最高的比例的CA是letsencrypt.org，以及一些次高的占比，还有一些其它的情况。

iodef这个允许邮箱和URL去报告错误，分析了两者的占比，以及去重统计。

总之，域名所有者在选择他们的CAA记录时似乎意识到了安全性。他们大多不允许通配符证书，他们对letsencrypt.org表现出非常明显的偏好。

TLSA

TLSA有四种证书使用类型，分别从0~3：

0，1：这两种情况要求整个证书链通过验证。
2：在验证中必须使用的新信任锚（根证书）被固定。
3：在任何证书链之外的终端实体证书上，例如，可以用于自签名证书。

作者统计了每种情况的占比，并与之前的工作做了对比。有些差异，以及差异的原因。

讨论

在这里插入图片描述
在这一部分作者根据测量结果，讨论了HTTPS安全的总体状态。

首先，对于使用HSTS的域，有效部署SCSV的频率较低。原因是不正确地为大量可能未使用的域设置HSTS。
使用HPKP的域也非常频繁地使用CT和HSTS头。
使用CAA或TLSA经常合并，并且经常与HSTS或HPKP部署相关。

复现

有关复现，我已经搭建好了jupyter notebook，在D:\software\Jupyter_notebook，cd到D:\software\Jupyter_notebook\analysis\Scripts目录下，执行：

source activate

打开python虚拟环境，然后再在该目录下执行jupyter notebook，即可弹出网页编辑器。退出虚拟环境可以执行deactivate。

有关具体搭建过程，因为我的需求是在别的盘建立python虚拟环境，这样就安装第三方包就不会占用c盘空间，所以我在D盘建立了python虚拟环境，具体方法百度即可，然后在该虚拟环境下搭建的jupyter notebook。

由于数据集较大，所以无法下载。

服务器，goscanner安装位置

与之前工作有区分，他们使用的是不同的goscanner版本，所以我将这个安装在另外的文件夹，但是在~/.bashrc里面设置的是20年那篇文章的软件。我将本文工具放置在文件夹：/home/k8s/zzy/mission_accomplished_https。后续方便继续复现。

技术，方法，包

tldextract

import tldextract

result = tldextract.extract("baidu.com")

print(result)

ExtractResult(subdomain='', domain='baidu', suffix='com')

用该包找到域名对应的suffix

AD flag

在解析服务器上用dig测试一下，例如：

#dig @127.0.0.1 +dnssec   test.net.  SOA

如果配置正确，应该返回test.net的SOA记录和相应的RRSIG记录，另外返回的头部中应该包含AD标志位，表示DNSSEC相关的数字签名验证是正确的，类似下面的样子：

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1397

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3

参考链接：https://blog.youkuaiyun.com/josunna/article/details/6558255

dnssec查询使用：
有关unbound使用的ip地址是：127.0.2.1

Unfortunately, massdns does not support dnssec. We must check for the AD bit ourselves. To that end, we use a vanilla unbound (https://www.unbound.net/) on localhost and github.com/miekg/exdns/q/q.go to do a DNS query with DNSSEC enabled. We then ran the below script (which you need to configure to reproduce) from SYD and MUC. For your convenience, we also provide the result files.

在查询dnssec时设置的标志位，有该标志则代表安全。

pandas apply

apply函数
apply函数是pandas里面所有函数中自由度最高的函数。该函数如下：
DataFrame.apply(func, axis=0, broadcast=False, raw=False, reduce=None, args=(), **kwds)

该函数最有用的是第一个参数，这个参数是函数，相当于C/C++的函数指针。

这个函数需要自己实现，函数的传入参数根据axis来定，比如axis = 1，就会把一行数据作为Series的数据结构传入给自己实现的函数中，我们在函数中实现对Series不同属性之间的计算，返回一个结果，则apply函数会自动遍历每一行DataFrame的数据，最后将所有结果组合成一个Series数据结构并返回。