Let’s|Let’s Encrypt证书支持CT,让你的网站更安全
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),有了主密钥,客户端和服务器端就可以保证通信数据是加密且没有被篡改。
对于一个 HTTPS 网站来说,PKI 体系并不是孤立的技术解决方案,它由很多机构组成,比如 CA 机构、网站部署者、用户、浏览器,证书是 PKI 最核心最重要的内容,通过下图可以了解 PKI 的构成。
文章图片
图1:PKI 证书最大的问题就是伪造证书的存在,一旦出现伪造证书,PKI 安全体系将会非常脆弱,出现伪造证书的原因如下:
- CA 机构有意无意会签发一些错误的证书,比如 CA 机构没有正确校验申请者的身份。
- CA 机构是一个追求盈利的机构,在利益的驱动下,可能会无节制的签发证书,如果签发一个恶意的二级 CA 证书,带来的危害更大。
- 攻击者会通过各种技术攻击手段,冒充或者伪造某个域名的拥有者,从而成功申请到一张证书,然后通过证书进行危害操作。
非法证书带来的危害是非常大的,如果非法证书校验成功,对于用户来说,他认为在和真正的服务器在通信,实际上是和潜在的攻击者在通信,用户的隐私和安全性将得不到保障。
在 PKI 基础设施中,可能会出现以下一些困惑:
- 域名拥有者无法知晓那些 CA 机构给他签发了证书,也不知道是否有人冒充他的身份申请证书并提供服务。
- CA 机构并不清楚它到底签发了多少证书,也不确定是否签发了伪造证书,二级 CA 签发机制不可控。
- 对于浏览器来说,它没有技术手段校验证书是否是合法的。
为了解决证书潜在的问题,谷歌提出了一个解决方案,这就是证书透明度(CT),目前这个技术解决方案已经非常成熟了,了解 CT,以下两个网站必须了解:
- www.certificate-transparency.org
- rfc6962
通过 CT,能够达成以下的几个目标:
- CA 机构能够知晓其签发了那些证书,并快速检测到是否签发恶意证书了。
- 网站拥有者能够知晓域名对应证书签发的全过程,一旦发现有攻击者伪造了域名对应的证书,可以快速联系 CA 机构,吊销该证书。
- 浏览器厂商能够审计证书的使用情况,如果发现有恶意证书,可以快速关闭HTTPS连接,保障用户的安全。
CT 由三部分组成:
- Certificate logs
- Certificate monitors
- Certificate auditors
文章图片
图2:ct结构 (1)Certificate logs
Certificate logs 是一个网络服务(需要部署,也要提供查询服务),是 CT 最核心的组成部分,Certificate logs 记录了证书所有签发记录,相当于一个证书中心数据库,任何人都可以新增、查询证书签发记录。
Certificate logs 有几个特性:
- 只读,只能新增记录,不能更新或者删除记录
- 通过一种称为 Merkle Tree Hash 的机制进行密码学保护,保证数据没有篡改。
- 任何人都可以向 Certificate logs 提交证书,并且查询证书是否合法存在于 Certificate logs 中。
在 HTTPS 协议握手过程中,浏览器就是通过 SCT 信息(可以通过三种途径获取)确认网站是否支持 CT,如果发现网站不支持,可以中止握手过程。现在大家应该明白 CT 和 SCT 的区别了。
任何人都可以构建 Certificate logs 服务,一般情况下,CA 机构给证书申请 SCT 的时候,会向多个 Certificate logs 服务发送请求。
下列表格列举了部分符合 Chrome CT 策略的 Certificate Logs 服务:
Certificate Logs | 地址 |
---|---|
Google 'Aviator' log | ct.googleapis.com/aviator |
Google 'Icarus' log | ct.googleapis.com/icarus |
Google 'Pilot' log | ct.googleapis.com/pilot |
Google 'Rocketeer' log | ct.googleapis.com/rocketeer |
Google 'Skydiver' log | ct.googleapis.com/skydiver |
DigiCert Log Server | ct1.digicert-ct.com/log |
DigiCert Log Server 2 | ct2.digicert-ct.com/log |
有了 Certificate Logs 服务的中心数据,Monitors 服务就可以基于 Certificate Logs 服务进行监控操作,任何人(主要是 CA 机构)都可以构建 Certificate monitors 服务。
通过 Certificate monitors 服务,能够查询证书是否是未授权或者非法的,也能检测证书包含的扩展是否合法,也能检测证书信息是否存在于 Certificate Logs 服务中,总之通过 monitors 服务,证书的签发和使用纳入了 PKI 监控体系,证书的使用更加透明了。
下表列举几个常见的 CT Monitors 服务。
工具名称 | 开发者 | 工具地址 | |
---|---|---|---|
crt.sh | COMODO | https://crt.sh | |
HTTPS encryption on the web | 谷歌 | https://transparencyreport.google.com/https/certificates | |
Certificate Transparency Monitoring | https://developers.facebook.com/tools/ct/ | ||
lectl | 开源 | https://github.com/sahsanu/lectl | 基于 crt.sh 工具,用于校验 Let's Encrypt 签发证书的日志信息 |
文章图片
图3:crt Facebook 的监控服务也非常好,你可以在该服务上登记你拥有的域名,一旦该域名有相应的证书签发了,Facebook 就会立刻发送消息通知你,这样你就可以更好的监控证书的使用了。
潜在的一个问题,任何人可以查询任意域名的 CT 信息,潜在带来一定的隐私问题,当然证书和域名一样,使用过程确实应该处于监控之下,这样才能保障安全。
(3)Certificate auditors
Certificate auditors 服务主要由浏览器来完成,主要有二个步骤:
- HTTPS握手阶段校验证书是否包含 SCT 信息,如果没有说明证书不符合 CT 机制,可能存在潜在的危险。
- 异步校验证书是否存在错误签发,恶意使用的情况,相当于完成 Certificate monitors 服务的功能,整个过程是异步的,避免影响 HTTPS握手。
前面描述了基础性的知识,对于网站部署者来说,其更关心如何让网站支持 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 : Mar6 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 : Mar6 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 协议扩展 。
- 客户端向服务器发送 HTTPS 协议请求。
- 客户端请求的 Client Hello 消息包含 signed_certificate_timestamp TLS/SSL 协议扩展,请求服务器返回 SCT 信息。
- 服务器接收到 Client Hello 消息后,在 Server Hello 消息中返回 SCT 信息。
- 客户端接收到 SCT 信息后,代表该证书是一个有效的证书,是经过审计的。
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 协议握手阶段就会失败。
那么在 Chrome 上如何让用户感知 CT 的存在呢?在老的 Chrome 版本开发者工具上可以看到 CT 信息(较新版本的 Chrome 已经去除,可见 CT 可以进入生产阶段了)。下图描述 Chrome 42 版本处理 CT 的相关情况。
文章图片
图4:chrome-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 开始的版本已经支持该特性,可以进行相关测试。
【Let’s|Let’s Encrypt证书支持CT,让你的网站更安全】作为全球最大的浏览器厂商,Chrome 在推进 CT 普及上做了很多工作,主流的收费 CA 机构也逐渐支持 CT,对于开发者来说,应该校验下自己的证书或者网站是否支持 CT,如果没有,应该快速行动起来。
推荐阅读
- 知识
- (二)ES6第一节变量(let|(二)ES6第一节变量(let,const)
- javaweb|基于Servlet+jsp+mysql开发javaWeb学生成绩管理系统
- Swift5.0|Swift5.0 UITexview的基本使用
- Swift7|Swift7 - 循环、函数
- Servlet原理|Servlet原理 二(Web应用与创建Servlet实例)
- 运行报错Cannot|运行报错Cannot find module '@babel/compat-data/corejs3-shipped-proposals’
- 律师的人性
- 100天共同成长吧!干货篇(5)-|100天共同成长吧!干货篇(5)- ‘行动派’学习心得
- 2018-08-31-‘工作有感’