酷应用

Let’s Encrypt证书支持CT，让你的网站更安全

百家 作者：聊聊架构 2018-06-28 00:24:50

2018 年四月份 Let’s Encrypt 宣布其发布的证书将直接嵌入 SCT 信息，作为全球最大的免费 CA 机构，他的一举一动对于 HTTPS 网站部署者来说非常关键，我们不禁要问，SCT 作用是什么？总结来说，证书透明度（Certificate Transparency，CT）特性（注意 CT 和 SCT 的区别，CT 是证书特性，而 SCT 是 CT 特性的一种表现形式）是证书的有效补充，它能够让你的网站更安全。

这篇文章全面回顾 CT，如果你的网站还不支持该特性，那么应该快速行动起来了。

证书

CT 是证书的一个特性，正因为证书存在一些缺点，CT 才被创造出来，在理解 CT 之前，我们有必要理解什么是证书、证书的作用、证书的缺陷。

如果想部署 HTTPS 网站，首先向 CA 机构申请一张证书，CA 机构在审核申请者的身份后，会签发一张证书，证书中包含了申请者网站的主机名、主机公钥，同时 CA 机构会用自己的私钥对整个证书进行签名，并将签名添加到证书文件中，然后发送给证书申请者。

证书是 TLS 协议中非常关键的一环，其主要作用：

  • 向网站访问者确认服务器的真实身份，确保客户端（浏览器）是和真正的网站提供者在通信，避免遇到中间人攻击，实现密码学中的身份认证特性。

  • 客户端和服务器使用证书中的公钥（依赖于不同的密码协商算法，功能有所不同）协商出主密钥（Master Secret），有了主密钥，客户端和服务器端就可以保证通信数据是加密且没有被篡改。

证书的细节信息比较多，可以参考其他书籍和文章，本文主要描述证书在 PKI（public key infrastructure，公钥基础设施）体系中的一些缺陷。

对于一个 HTTPS 网站来说，PKI 体系并不是孤立的技术解决方案，它由很多机构组成，比如 CA 机构、网站部署者、用户、浏览器，证书是 PKI 最核心最重要的内容，通过下图可以了解 PKI 的构成。

证书最大的问题就是伪造证书的存在，一旦出现伪造证书，PKI 安全体系将会非常脆弱，出现伪造证书的原因如下：

  • CA 机构有意无意会签发一些错误的证书，比如 CA 机构没有正确校验申请者的身份。

  • CA 机构是一个追求盈利的机构，在利益的驱动下，可能会无节制的签发证书，如果签发一个恶意的二级 CA 证书，带来的危害更大。

  • 攻击者会通过各种技术攻击手段，冒充或者伪造某个域名的拥有者，从而成功申请到一张证书，然后通过证书进行危害操作。

在 PKI 基础设施中，浏览器校验证书的时候，只能判断证书是否是合法 CA 机构签发的，没有技术手段校验证书是否是非法的。即使未来发现证书是非法的，证书吊销更新机制（CRL 和 OCSP）也是非常滞后的。

非法证书带来的危害是非常大的，如果非法证书校验成功，对于用户来说，他认为在和真正的服务器在通信，实际上是和潜在的攻击者在通信，用户的隐私和安全性将得不到保障。

在 PKI 基础设施中，可能会出现以下一些困惑：

  • 域名拥有者无法知晓那些 CA 机构给他签发了证书，也不知道是否有人冒充他的身份申请证书并提供服务。

  • CA 机构并不清楚它到底签发了多少证书，也不确定是否签发了伪造证书，二级 CA 签发机制不可控。

  • 对于浏览器来说，它没有技术手段校验证书是否是合法的。

证书透明度

为了解决证书潜在的问题，谷歌提出了一个解决方案，这就是证书透明度（CT），目前这个技术解决方案已经非常成熟了，了解 CT，以下两个网站必须了解：

  • www.certificate-transparency.org

  • rfc6962

CT 是一组技术解决方案，它能够审计、监控证书的签发、使用，从而让证书在 PKI 体系中更透明，它不是证书的替代解决方案，而是证书的有效补充，它也没有改变 PKI 体系，这几点务必要记住。

通过 CT，能够达成以下的几个目标：

  • CA 机构能够知晓其签发了那些证书，并快速检测到是否签发恶意证书了。

  • 网站拥有者能够知晓域名对应证书签发的全过程，一旦发现有攻击者伪造了域名对应的证书，可以快速联系 CA 机构，吊销该证书。

  • 浏览器厂商能够审计证书的使用情况，如果发现有恶意证书，可以快速关闭 HTTPS 连接，保障用户的安全。

CT 是一个公开的技术解决方案，并不是封闭的，也不是谷歌专有的，PKI 体系中任何一个组织都可以参与，从而有效保障网站的安全性。

CT 由三部分组成：

  • Certificate logs

  • Certificate monitors

  • Certificate auditors

这三部分的结构如下图，详细细节会逐步描述。

（1）Certificate logs

Certificate logs 是一个网络服务（需要部署，也要提供查询服务），是 CT 最核心的组成部分，Certificate logs 记录了证书所有签发记录，相当于一个证书中心数据库，任何人都可以新增、查询证书签发记录。

Certificate logs 有几个特性：

  • 只读，只能新增记录，不能更新或者删除记录

  • 通过一种称为 Merkle Tree Hash 的机制进行密码学保护，保证数据没有篡改。

  • 任何人都可以向 Certificate logs 提交证书，并且查询证书是否合法存在于 Certificate logs 中。

向 Certificate logs 提交证书新增请求后，Certificate logs 会返回 SCT 信息（Signed Certificate Timestamp），SCT 非常重要，相当于证书签发的票据。

在 HTTPS 协议握手过程中，浏览器就是通过 SCT 信息（可以通过三种途径获取）确认网站是否支持 CT，如果发现网站不支持，可以中止握手过程。现在大家应该明白 CT 和 SCT 的区别了。

任何人都可以构建 Certificate logs 服务，一般情况下，CA 机构给证书申请 SCT 的时候，会向多个 Certificate logs 服务发送请求。

下列表格列举了部分符合 Chrome CT 策略的 Certificate Logs 服务：

Certificate Logs地址
Google 'Aviator' logct.googleapis.com/aviator
Google 'Icarus' logct.googleapis.com/icarus
Google 'Pilot' logct.googleapis.com/pilot
Google 'Rocketeer' logct.googleapis.com/rocketeer
Google 'Skydiver' logct.googleapis.com/skydiver
DigiCert Log Serverct1.digicert-ct.com/log
DigiCert Log Server 2ct2.digicert-ct.com/log

（2）Certificate monitors

有了 Certificate Logs 服务的中心数据，Monitors 服务就可以基于 Certificate Logs 服务进行监控操作，任何人（主要是 CA 机构）都可以构建 Certificate monitors 服务。

通过 Certificate monitors 服务，能够查询证书是否是未授权或者非法的，也能检测证书包含的扩展是否合法，也能检测证书信息是否存在于 Certificate Logs 服务中，总之通过 monitors 服务，证书的签发和使用纳入了 PKI 监控体系，证书的使用更加透明了。

下表列举几个常见的 CT Monitors 服务。

工具名称开发者工具地址
crt.shCOMODOhttps://crt.sh
HTTPS encryption on the web谷歌https://transparencyreport.google.com/https/certificates
Certificate Transparency MonitoringFacebookhttps://developers.facebook.com/tools/ct/
lectl开源https://github.com/sahsanu/lectl

重点推荐 crt.sh，输入域名就可以查看所有的证书签发记录了，如下图：

Facebook 的监控服务也非常好，你可以在该服务上登记你拥有的域名，一旦该域名有相应的证书签发了，Facebook 就会立刻发送消息通知你，这样你就可以更好的监控证书的使用了。

潜在的一个问题，任何人可以查询任意域名的 CT 信息，潜在带来一定的隐私问题，当然证书和域名一样，使用过程确实应该处于监控之下，这样才能保障安全。

（3）Certificate auditors

Certificate auditors 服务主要由浏览器来完成，主要有二个步骤：

  • HTTPS 握手阶段校验证书是否包含 SCT 信息，如果没有说明证书不符合 CT 机制，可能存在潜在的危险。

  • 异步校验证书是否存在错误签发，恶意使用的情况，相当于完成 Certificate monitors 服务的功能，整个过程是异步的，避免影响 HTTPS 握手。

如何获取 SCT

前面描述了基础性的知识，对于网站部署者来说，其更关心如何让网站支持 CT，确切的说，如何获取 SCT 信息，网站支持 CT 有三种途径，分别是证书扩展、OCSP 协议、TLS/SSL 协议扩展。这三种方式有不同的应用场景，有些需要 CA 机构处理，有些需要网站部署者处理，接下去分别描述。

（1）通过证书扩展获取 SCT

目前 Let’s Encrypt 证书直接包含了 SCT 信息，这种方式无需网站部署者做任何的操作就能让网站支持 CT，从效率上和可管理性看，这种方式是最好的，CA 机构提供的证书直接包含 SCT。

对于 CA 机构（以 Let’s Encrypt 为例）来说，需要注意在签发证书的时候，先要获取 SCT 信息，然后再将 SCT 信息嵌入到证书中，但是由于没有证书就无法获取 SCT，为了解决这个问题，Let’s Encrypt 先生成一张 precertificate 证书，然后向两个 Certificate Logs 提交 precertificate 证书（一个是谷歌的 Certificate Log 服务，另外一个是非谷歌的 Certificate Log 服务），获取到 SCTs 后，再修改 precertificate 证书，添加 SCTs 扩展。

从 2018 年 4 月 30 号以后，所有在 Let’s Encrypt 签发或更新的证书将自动包含 SCTs。

可以使用 OpenSSL 命令行工具获取证书 SCTs 信息，比如运行下列命令：

$ openssl x509 -in  /etc/letsencrypt/live/simplehttps.com/cert.pem -noout -text

该命令和 SCTs 有关的输出如下：

CT Precertificate SCTs: 
    Signed Certificate Timestamp:
        Version   : v1 (0x0)
        Log ID    : 29:3C:51:96:54:C8:39:65:BA:AA:50:FC:58:07:D4:B7:
                    6F:BF:58:7A:29:72:DC:A4:C3:0C:F4:E5:45:47:F4:78
        Timestamp : Apr 18 09:03:52.458 2018 GMT
        Extensions: none
        Signature : ecdsa-with-SHA256
                    30:45:02:20:51:E8:EB:BF:7E:0A:BA:F8:6D:94:C2:3A:
                    B6:4B:02:B5:24:F3:7B:A8:7A:B9:C1:C2:D7:02:2A:F1:
                    7A:92:7D:5B:02:21:00:D3:7F:51:B1:87:E5:A8:9A:F2:
                    24:43:10:65:76:31:26:25:2C:9A:1C:4E:DB:4F:F0:EF:
                    E4:25:82:4E:5D:16:7F
    Signed Certificate Timestamp:
        Version   : v1 (0x0)
        Log ID    : 55:81:D4:C2:16:90:36:01:4A:EA:0B:9B:57:3C:53:F0:
                    C0:E4:38:78:70:25:08:17:2F:A3:AA:1D:07:13:D3:0C
        Timestamp : Apr 18 09:03:52.480 2018 GMT
        Extensions: none
        Signature : ecdsa-with-SHA256
                    30:44:02:20:5F:DE:E5:DD:AC:FE:85:99:A7:22:67:28:
                    86:0E:2C:81:62:F6:2F:66:ED:18:AC:93:E2:99:6F:76:
                    5D:4B:7C:F3:02:20:6E:1F:66:EB:A0:E9:09:D9:B3:F0:
                    70:69:90:D6:30:5A:E0:BD:ED:F8:6F:8C:71:65:CF:A7:
                    5B:8E:56:D3:C8:7D

从输出可以看出，由两个 Certificate Logs 提供 SCTs 信息。

（2）OCSP 封套的方式

CA 机构可以使用 OCSP 协议的方式提供 SCT 信息，这属于一种异步提供 SCT 信息的方式，OCSP 协议主要提供证书吊销信息，相比 CRL 来说，OCSP 扩展性更好，也就是说 CA 机构的 OCSP 服务也可以包含 SCTs 信息。

从操作性上看，网站部署者如果想支持 CT，需要部署 OCSP 封套服务（原生 OCSP 服务有很多的缺点），当然现在 OCSP 封套服务已经很普及了。

可以寻找一个支持 OCSP 封套的网站（且包含 SCTs 信息），检查 OCSP 响应中的 SCT 信息，运行以下命令：

$ openssl s_client -connect sslanalyzer.comodoca.com:443 -status

关键输出如下：

OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: D34EC319BA5859D11C60B76153473BA7778FF88A
    Produced At: Jun 16 12:02:50 2018 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: D5C398C21A2572B0EA4272663FFBD90522DFE38D
      Issuer Key Hash: D34EC319BA5859D11C60B76153473BA7778FF88A
      Serial Number: 9E487D65A15ACAA085C2DEE46DD1B0FC
    Cert Status: good
    This Update: Jun 16 12:02:50 2018 GMT
    Next Update: Jun 23 12:02:50 2018 GMT
        Response Single Extensions:
            CT Certificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A:
                                3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10
                    Timestamp : Mar  6 16:12:54.862 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:0B:2D:26:5F:B4:04:EC:95:75:F1:40:DE:
                                16:8F:73:BA:44:39:B6:C2:F5:FB:F2:ED:F9:9B:6D:20:
                                CA:2C:33:E6:02:20:5F:41:C9:18:14:8D:E4:1A:72:7F:
                                4E:B1:67:A7:EA:E9:8F:90:6D:F9:7F:F6:80:D6:96:03:
                                D5:05:7D:C7:44:B0
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 56:14:06:9A:2F:D7:C2:EC:D3:F5:E1:BD:44:B2:3E:C7:
                                46:76:B9:BC:99:11:5C:C0:EF:94:98:55:D6:89:D0:DD
                    Timestamp : Mar  6 16:12:54.280 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:3D:F3:DD:77:1F:4A:73:4B:F5:88:95:07:
                                BD:37:EC:D9:E3:80:1F:7E:48:AC:ED:79:FE:90:FC:AA:
                                1F:2B:11:A1:02:20:46:7E:8C:CB:7B:FB:15:EC:D4:04:
                                E6:93:01:31:57:FF:FA:A8:E2:FF:C1:DB:83:CF:90:49:
                                0C:FC:4B:A9:2C:41

（3）TLS 扩展方式获取 SCT

如果前两种获取 SCT 的方式都不能用，可以采用 signed_certificate_timestamp TLS/SSL 协议扩展获取 SCT。

这种方式需要网站部署者自行向 Certificate Log 服务申请 SCTs 信息（如果 CA 机构不能支持 SCT，那么只能采取这种方式），大概的步骤如下：

  • 服务器实体向 Certificate Logs 服务申请 SCT 信息。

  • 配置 TLS/SSL 协议扩展支持 SCT 信息，比如 Nginx nginx-ct 模块就能支持 signed_certificate_timestamp TLS/SSL 协议扩展 。

那么客户端如何通过 TLS 扩展的方式获取 SCT 信息呢，步骤如下：

  • 客户端向服务器发送 HTTPS 协议请求。

  • 客户端请求的 Client Hello 消息包含 signed_certificate_timestamp TLS/SSL 协议扩展，请求服务器返回 SCT 信息。

  • 服务器接收到 Client Hello 消息后，在 Server Hello 消息中返回 SCT 信息。

  • 客户端接收到 SCT 信息后，代表该证书是一个有效的证书，是经过审计的。

使用 Wireshark 工具抓取 HTTPS 协议消息，在 Client Hello 消息中可以看到 signed_certificate_timestamp TLS/SSL 协议扩展，消息如下：

Extension: signed_certificate_timestamp (len=0)
    Type: signed_certificate_timestamp (18)
    Length: 0

服务器 Server Hello 消息会响应 signed_certificate_timestamp TLS/SSL 协议扩展，响应信息如下：

Extension: signed_certificate_timestamp (len=243)
    Type: signed_certificate_timestamp (18)
    Length: 243
    Serialized SCT List Length: 241
    Signed Certificate Timestamp (Google 'Pilot' log)
        Serialized SCT Length: 119
        SCT Version: 0
        Log ID: a4b90990b418581487bb13a2cc67700a3c359804f91bdfb8...
        Timestamp: Dec 13, 2017 14:28:56.004000000 UTC
        Extensions length: 0
        Signature Hash Algorithm: 0x0403
        Signature Length: 72
        Signature: 3046022100b1ad781896f9659d2107a63a3221bc1dfc66e1...
    Signed Certificate Timestamp (Symantec log)
        Serialized SCT Length: 118
        SCT Version: 0
        Log ID: ddeb1d2b7a0d4fa6208b81ad8168707e2e8e9d01d55c888d...
        Timestamp: Dec 13, 2017 14:28:55.786000000 UTC
        Extensions length: 0
        Signature Hash Algorithm: 0x0403
        Signature Length: 71
        Signature: 3045022100a5f24b5025366f6d47f943dbb236b2ecceb0ea...

该响应包含了两个 SCT 信息，分别是 Pilot 和 Symantec 提供的 Certificate Logs 服务。至于 Nginx 如何配置，此处就不进行描述了。

这种方式需要网站部署者做很多工作，没有特殊情况，建议不要采用。

CT 普及度

CT 是谷歌提出来的解决方案，在 Chrome 浏览器上做了很多的尝试，截止到今日，其普及程度越来越高了，Firefox 也准备开始校验 SCT，但目前还没有实施完。

如果想了解 Chrome 浏览器支持 CT 的情况，可以访问 chromium 的 ct-policy 仓库，其中讲解了在 Chrome 中校验 CT 的策略。

  • 从 2015 年 1 月份开始，Chrome 要求所有的 EV 证书开始支持 CT。

  • 从 2018 年 4 月 30 号开始，Chrome 要求所有的证书支持 CT（2018 年 4 月 30 号以后签发的证书，老的证书没有该限制），如果访问的网站包含 SCT，则在 TLS/SSL 协议握手阶段就会失败。

对于 CT 来说，是否生效，取决于浏览器的处理策略，但从本质上来说，CA 机构应该提交证书签发信息，让证书签发行为透明化。而且目前已经证明，CT 是具备可行性的一种技术解决方案。

那么在 Chrome 上如何让用户感知 CT 的存在呢？在老的 Chrome 版本开发者工具上可以看到 CT 信息（较新版本的 Chrome 已经去除，可见 CT 可以进入生产阶段了）。下图描述 Chrome 42 版本处理 CT 的相关情况。

如果你不了解网站用户使用的浏览器（针对 CT，目前其实就是 Chrome），但又想了解客户端处理 CT 是否遇到问题（应对 Chrome 硬性要求网站支持 CT 的期限）; 或者从安全的角度考虑，强制希望客户端浏览器校验 SCTs，那么可以提前了解一个新的 HTTP 消息头 Expect-CT。

如果你想了解网站 CT 支持情况，可以使用报告模式，比如：

Expect-CT: max-age=0, report-uri="https://www.simplehttps.com/ct/reportOnly"

如果浏览器在处理 SCTs 的时候遇到问题，会向 report-uri 属性对应的地址发送报告，以便让管理员了解详细的信息。max-age=0，表示每次访问都处理 SCTs 信息。

如果你向让浏览器强制校验 SCTs，可以使用 enforce 模式，比如：

Expect-CT: enforce max-age=30, report-uri="https://www.simplehttps.com/ct/reportOnly"

enforce 属性表示强制让浏览器校验 SCTs，max-age=30 表示在 30 秒内缓存校验结果。

这个消息头的详细定义可以参考 Expect-CT Extension for HTTP draft-ietf-httpbis-expect-ct-02，目前 Chrome 61 开始的版本已经支持该特性，可以进行相关测试。

作为全球最大的浏览器厂商，Chrome 在推进 CT 普及上做了很多工作，主流的收费 CA 机构也逐渐支持 CT，对于开发者来说，应该校验下自己的证书或者网站是否支持 CT，如果没有，应该快速行动起来。

赠书福利

本文作者虞卫东的新书《深入浅出 HTTPS：从原理到实战》现已上市，这本书全面介绍了 HTTPS 领域的相关知识，内容包括密码学、OpenSSL 命令行、证书、TLS 协议、HTTPS 网站性能优化、HTTPS 网站最佳实践、大型网站 HTTPS 架构设计等等。

截至本周日 24 点之前，本文留言获赞最多的 5 位用户，每人可获得一本《深入浅出 HTTPS：从原理到实战》，欢迎大家留言。

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/

*文章为作者独立观点，不代表 爱尖刀 立场
本文由 聊聊架构发表，转载此文章须经作者同意，并请附上出处( 爱尖刀 )及本页链接。
原文链接 https://www.ijiandao.com/2b/baijia/133762.html
安全
图库
聊聊架构 聊聊架构
公众号 关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接
百度热搜榜
排名 热点 搜索指数
iTrust
AiDeep Ued
关于我们 联系我们 升级日志 法律声明 广告服务 侵删通道
Copyright © 2021 K2CMS All rights reserved.
京ICP备14006288号