本月大事件:云厂商漏洞致Let's Encrypt禁用SNI域验证
近日,不少云厂商的都面临着允许签发未经授权的Let's Encrypt证书的控诉。虽说问题出在云厂商,但Let's Encrypt毅然决然地禁用了相应的验证方法。
FransRosén发现他可以使用ACME协议中的SNI验证方法为某些云厂商托管的域颁发证书,并明确提到了Heroku和Amazon CloudFront。
问题的核心在于,这些服务供应商允许用户上传证书,然后系统将自动向具有相应服务器名称的TLS请求提供服务。ACME SNI验证方法使用以.acme.invalid结尾的临时证书。
在问题被曝光后,Let's Encrypt立即禁用了TLS-SNI-01验证方法。Let's Encrypt随后决定,除了少数特例,它将永久禁用。据悉,较新的TLS-SNI-02方法也很脆弱。考虑到这个问题的新的TLS-SNI-03方法正在开发中,目前用户应该切换到HTTP或DNS验证方法。
短新闻回顾
rustls的作者提供了一些比较OpenSSL和rustls的性能的基准数据。
CT天文台为证书透明度日志中的数据提供了Web界面。
Google现在提供了一个支持DNS-over-HTTPS协议草案的服务器。
1个月,报告嵌入在软件中的证书问题, 现在已经有更多的案例被发现:Comodo,Intel和UnionPay都有类似的问题。
苏黎世的真实世界加密会议包括HACL(正式验证NSS加密),TLS标准化过程,TLS 1.3部署TLS生态系统问题等等。
Mozilla宣布Firefox中的所有新Web功能都需要安全上下文(即HTTPS或本地主机连接)。
信托商店天文台为浏览器和操作系统的各种根商店提供的证书提供下载链接。
一些顶级域名已被添加到HSTS预加载列表:.bank和.insurance。 使用HSTS预加载列表的浏览器将始终通过HTTPS加载使用这些TLD的域。
OpenStreetMap默认使用HTTPS。
Scott Helme写了一篇带有挑衅性标题的博客文章:“我们需要更多的HTTPS钓鱼网站!”
NSS 3.35已经发布,更改包括支持最新的TLS 1.3草案,并正式验证ChaCha20和Poly1305的实施。
OpenSSL宣布了其开发结构的变化,特别是关于邮件列表和GitHub的使用。
赛门铁克未能更新其中一个HTTPS证书; 访问者之一的子域因此收到证书到期错误消息。
CNN现在默认使用HTTPS。
Chrome取消了对证书中CN字段的支持。因为它们已被弃用了很多年,但由于企业设备倾向于使用过时的技术,并且往往仍然独家使用CN领域,所以仍然有可能通过企业策略重新获得支持,该选项将在Chrome 66中删除。
Wired指出,Tinder的数据连接没有完全用HTTPS保护。
DigiCert宣布将从2月1日开始将所有证书记录到证书透明,并将添加SCT。 Chrome将在四月份要求CT日志记录和SCT以获得新证书。
一篇论文讨论了X.509证书后量子签名的影响。
标题为“为什么APT不使用HTTPS?”的网页认为Debian软件包管理器不使用HTTPS,主要是因为APT总是验证签名。
最新的Java更新包括一些TLS更新,包括对TLS会话散列,扩展主密钥扩展和协商有限域Diffie-Hellman参数的支持。
在CA /浏览器论坛的讨论爆发了哪些版本的基线要求和论坛的章程目前是有效的辩论。
TLS 1.3正处于终审阶段,这意味着我们很快可以看到最终的TLS1.3 RFC。但这不是我们第一次听说TLS 1.3在终审了。花了这么长时间,锅不能全让标准本身背,而是生态系统的问题。
微软宣布将在三月份要求Office 365使用TLS1.2。 对TLS 1.0和1.1的支持将被禁用。
DigiCert提出了与不包括域名所有权的任何技术检查可疑域验证方法的一些问题。 这导致了关于贬低这种验证方法的更长时间的讨论。但Entrust表示强烈反对,并希望保持原有的有问题的验证方法或是非常长的转换周期。
领取专属 10元无门槛券
私享最新 技术干货