TLS是否必须不断修改以使其面向未来?
TLS 1.3标准即将完成,但这一切得来不易。那些使用着旧版TLS的设备始终是标准化过程的一大挑战。尽管这使得协议变得莫名的复杂,但同时也更易于人们部署。为了让TLS能够适应各种设备,唯一的办法就是不断改变。
常见的问题有,版本不兼容:接收TLS 1.3连接的设备不会降级到较低版本。为了避免这些问题,版本协商转移到了扩展中,并引入了由Google的David Benjamin发明的GREASE机制。 TLS 1.3实现可以发送一组服务器要忽略的伪版本号。 同样的机制也可以用于其他领域,如密码套件。
但是版本协商并不是唯一的问题:中间件会假定TLS包将遵循他们在TLS 1.2中使用的格式,并且如果它们没有,则会断开连接。 通过让TLS 1.3看起来更像1.2,许多这些问题都可以得到解决。
预防类似的问题并不是件容易的事,硬件开发商常常对TLS协议不甚了解。David Benjamin提出了一个听起来很极端的办法,在正规版本的TLS1.3之外允许一些临时修改版的存在。这些修改版本每几周就会变化一次,一些服务器和浏览器可以在短时间内提供支持。
鉴于Chrome和谷歌自有服务的市场份额很大,任何人都不可能部署破坏它们之间连接的设备。 如果浏览器和网页无法就临时TLS版本达成一致也没有问题:它们总是可以回退到标准化的TLS 1.3(至少如果能使双方都正确地实现版本协商,就是值得去尝试的努力)。
本月短新闻
- Crypto 2018会议宣布将在8月19日举办TLS1.3研讨会
- Mozilla的Lin Clark在一篇博客中解释了DNS通过HTTPS
- 基于哈希的签名方案XMSS已经在RFC 8391中进行了规定。假设XMSS是后量子安全的,但它是一种有状态的方案,因此通常不是现有签名方案的直接替换。
- 在pppd的EAP-TLS实现中发现缓冲区溢出。
- OpenSSL发布了一个关于Diffie-Hellman参数的拒绝服务漏洞的安全公告。
- NCC集团已发布有关针对ECDSA和DSA的内存缓存侧通道攻击的研究。 为了响应这项研究,Libgcrypt发布了一个安全补丁。
- Let’s Encrypt 支持使用TLS的ALPN机制的新域验证方法。 RFC的草案也已经发布。
- Digicert宣布将离开CA安理会(CASC)。 CA安全委员会是代表证书颁发机构的行业组织。 Digicert博客文章表明该公司对CASC的重点存在分歧,特别是有关扩展验证证书的分歧。
- RFC的草案建议不要使用旧的TLS版本1.0和1.1。
- 对于即将召开的黑帽大会,有关一种名为TLBleed的新CPU侧通道攻击的讨论已经公布。
- 从7月开始,PCI-DSS信用卡标准要求禁用TLS 1.0。
- Scott Helme撰写了关于如何使用证书透明度日志来发现网络钓鱼的文章。
- 如果网站支持,Google会自动将通过Google搜索广告的链接重定向到HTTPS。
- ctutils和CTjs开始提供JavaScript功能,以便与证书透明度日志进行通信。
- Eric Lawrence注意到微软对EV证书的行为发生了改变。只有在启用了SmartScreen(微软反网络钓鱼功能)时,才显示绿色EV指示器。
- EFF重新启动了其STARTTLS Everywhere项目,该项目旨在维护具有有效证书的SMTP服务器配置列表。
- Hardenize支持验证Expect-CT标头。
- MTA-STS(电子邮件服务器的TLS证书验证)和SMTP-TLSRPT(报告TLS故障)的标准已获批准,很快就会有RFC。 Hardenize在博客文章中对MTA-STS进行了解释。
- Firefox 61默认支持最新的TLS 1.3草案版本。
稿源:The Feisty Duck