TLS1.3/QUIC 是怎样做到 0-RTT 的

《低延迟与用户体验杂谈》中,我们提到了TLS1.3以及QUIC协议可以有效的降低传输层的延迟,改善用户体验。而TLS1.3和QUIC降低用户延迟有一个共同点,那就是在提供同等功能特性下,减少Round-Trip Time (RTT)次数。你甚至会经常听到QUIC和TLS1.3的拥趸说TLS1.3和QUIC可以做到0-RTT,基本消灭了(安全)传输层的延迟。事实真的是这样吗?

TLS RTT

我们先看一下TLS1.2 (以ECDH为例)的建立加密连接的过程:

从上图可以看出,在发送应用数据之前,TLS安全传输层需要经过2-RTT才能完成握手。如果是恢复会话,TLS1.2可以采用Session IDSession Ticket进行快速握手:

从上图可以看到,在使用Session Ticket的情况下,需要1-RTT。

那么TLS1.3是如何进一步优化的呢?

TLS 1.3完全握手

在完全握手情况下,TLS 1.3需要1-RTT建立连接。与TLS1.2有两点不同:握手过程中移除了ServerKeyExchangeClientKeyExchange, DH (Diffie-Hellman) 参数通过 key_share 传输。

TLS1.3恢复会话握手

TLS1.3恢复会话可以直接发送加密后的应用数据,不需要额外的TLS握手。因此,我们常说的TLS1.3 0-RTT握手其实是指恢复加密传输层会话不需要额外的RTT。但是,在第一次进行完全握手时,是需要1-RTT的。

与TLS1.2比较,无论是完全握手还是恢复会话,TLS1.3均比TLS1.2少1-RTT。因此,TLS1.3从被提上draft草案开始获得了各方面的好评。从nginx和Chrome支持此特性的速度可见一斑。

但是TLS1.3也并不完美。TLS 1.3 O-RTT无法保证前向安全性(Forward secrecy). 简单讲就是,如果当攻击者通过某种手段获取到了Session Ticket Key,那么该攻击者可以解密以前的加密数据。

这个问题不是TLS1.3独有,TLS1.2也存在这个问题。对于TLS1.3来说,要缓解该问题可以通过设置ServerConfiguration中的Expiration Date字段,使得与Session Ticket Key相关的DH静态参数在短时间内过期(一般几个小时)。

使用TLS最多的场景是HTTPS和HTTP/2. 以HTTP/2为例,一个完整的 HTTP Request需要经历的RTT如下:

HTTP/2 over TLS1.2首次连接 HTTP/2 over TLS1.2连接复用 HTTP/2 over TLS1.3首次连接 HTTP/2 over TLS1.3连接复用
DNS解析 1-RTT 0-RTT 1-RTT 0-RTT
TCP握手 1-RTT 0-RTT 1-RTT 0-RTT
TLS握手 2-RTT 1-RTT 1-RTT 0-RTT
HTTP Request 1-RTT 1-RTT 1-RTT 1-RTT
总计 5RTT 2-RTT 4-RTT 1-RTT

从上表可以看出:

  1. 首次连接发起HTTP请求是非常昂贵的。因此,如果你是用HTTPS作一些不可告人的代理应用的话,一定尽量保持长连接,避免频繁建立新连接。
  2. 连接的multlplexing(多路复用)可以有效减少RTT次数,降低延迟。在连接复用的情况下,TLS1.3将整个http request的RTT降低到了1个,达到理论的最小值。

QUIC RTT

  1. 当客户端首次发起QUIC连接时,客户端想服务器发送一个client hello消息,服务器回复一个server reject消息。该消息中有包括server config,类似于TLS1.3中的key_share交换。这需要产生1-RTT. 事实上,QUIC加密协议的作者也明确指出当前的QUIC加密协议是「注定要死掉的」(destined to die), 未来将会被TLS1.3代替。只是在QUIC提出来的时候,TLS1.3还没出生😂,这只是一个临时的加密方案。
  2. 当客户端获取到server config以后,就可以直接计算出密钥,发送应用数据了,可以认为是0-RTT。密钥推导可以参见Key derivation.
  3. 因此,QUIC握手除去首次连接需要产生1-RTT,理论上,后续握手都是0-RTT的。
  4. 假设1-RTT=100ms, QUIC建立安全连接连接的握手开销为0ms, 功能上等价于TCP+TLS, 但是握手开销比建立普通的TCP连接延迟都低:

    (正常体为首次建立连接的延迟,粗体部分为后续握手的延迟)

HTTP/2 over TLS 1.3 vs QUIC

当前,QUIC普遍的应用场景是 HTTP/2 over QUIC. 我们以一个完整的 HTTP Request需要经历的RTT为例,比较TLS1.3与QUIC的RTT开销:

HTTP/2 over TLS1.3首次连接 HTTP/2 over TLS1.3连接复用 HTTP/2 over QUIC首次连接 HTTP/2 over QUIC连接复用
DNS解析 1-RTT 0-RTT 1-RTT 0-RTT
TCP握手 1-RTT 0-RTT
TLS握手 1-RTT 0-RTT
QUIC握手 1-RTT 0-RTT
HTTP Request 1-RTT 1-RTT 1-RTT 1-RTT
总计 4RTT 1-RTT 3-RTT 1-RTT

从上表可以看出:HTTP/2 over QUIC相比HTTP/2 over TLS 1.3最大的优势是首次连接是的RTT开销降低了1-RTT(25%)。在连接复用的情况,QUIC的RTT开销与TLS1.3相等。

前面我们提到,QUIC(UDP+QUIC Crypto)在功能层面等价于TCP+TLS, 并且其加密协议(QUIC Crypto)未来会被TLS1.3代替。而在连接复用的情况下QUIC与TLS1.3的RTT开销旗鼓相当,那么是否意味着在HTTP/2的应用场景下,TCP+TLS1.3就可以完全替代QUIC呢?答案是否定的,主要原因如下:

  1. QUIC从数据包级别解决了队头阻塞的问题,而TCP+TLS只能解决http request级别的队头阻塞问题。具体原理可以参见《当我们在谈论HTTP队头阻塞时,我们在谈论什么》.
  2. QUIC与HTTP/2结合更加紧密,比如HTTP/2的stream, frame, Header Compression都可以直接映射到QUIC的stream, packet, Header Compression. 从协议分层看这会使得应用层和传输层紧耦合,但是在HTTP/2这个具体场景下,QUIC可以接管HTTP/2的拥塞控制,相较于HTTP/2 over TLS 1.3会受到TCP和HTTP/2两层的拥塞控制来说,无疑具有更直接有效的控制策略。并且,QUIC的拥塞控制是应用层可插件化的。虽然你也可以为TCP编写拥塞控制模块,但那是一个内核模块,稍不注意就会让系统崩溃。如果你有兴趣的话,实现一个QUIC的BBR拥塞控制模块是很容易的。
  3. QUIC支持连接迁移(Connection Migration),即在客户端切换网络IP以后,也能够保持连接不间断。这对于移动网络这种漫游网络特别友好,再加上QUIC在首次连接上RTT比TLS1.3低25%,因此会有更好的用户体验。虽然Multipath TCP, MPTCP也可以吃支持连接迁移,但这受限于操作系统和网络协议栈,要想普及,任重道远。
  4. QUIC支持Forward Error Correction,利用一定的数据包冗余,提供丢包时恢复丢包数据的能力。减少了包重传的数量,进而减少延迟,提高带宽利用率。如果你使用过kcptun,你会发现它也采用了FEC,对于弱网和高丢包环境下,效果尤其好。

当然,QUIC也是有缺点的。比如很多运营商对UDP的QoS级别是比TCP低的,甚至只允许DNS 53端口的UDP包,其他UDP包都是被封掉的。在IDC中,UDP的优先级一般也比TCP低。因此,即使以后大规模普及QUIC,也不会完全替代TCP+TLS,毕竟需要确保在QUIC不可用时,可以回落到TCP+TLS.

总结

在首次连接的时候,无论是TLS1.3还是QUIC都需要1-RTT,在连接复用的情况下,两者才能做到0-RTT. 在HTTP/2的应用场景中,QUIC可以有效的降低首次连接的RTT次数,并且支持连接迁移、FEC以及更加灵活高效的拥塞控制,因此可以在移动网络、弱网环境提供低延迟的用户体验。

扩展阅读

macOS无法打开app应用程序的解决办法

macOS Sierra以后(EI Capitan, High Sierra),默认只允许打开来自Mac App Store或苹果的有效开发者发布的应用。你可以在「System Preferences -> Security & Privacy」查看当前状态:

如果是从网络下载安装的app,在打开时可能会遇到这两个问题:

  • YOUR_APP is from an unidentified developer, Are you sure you want to open is?
  • YOUR_APP is damaged and can’t be opened. You should move it to the Trash.

可以尝试在终端中执行sudo spctl --master-disable(需要输入密码)以允许打开任意来源的app:

如果执行成功,「Anywhere」选项为选中状态。「Security & Privacy」状态如下:

如果需要关闭「Anywhere」选项,则在终端执行sudo spctl --master-disable.

注:打开该「Anywhere」选项有安全风险,请确保你在打开该选项是了解app的来源,只信任自己清楚来源的app.

从答题赚钱APP谈谈接口防抓包

从答题赚钱APP谈谈接口防抓包

这段时间,答题赚钱APP真的是红遍了神州大地:国民老公王思聪的冲顶大会、芝士超人、西瓜视频,甚至连老司机韩路也玩起了这个游戏😅。有利益就有动力,毕竟每场奖金都在十万、百万,虽然官方可以在最终答对人数上面掺水稀释每人的奖金,但是的确可能拿到奖金。人类,对这种可预期、强反馈的东西跟吸毒一样……于是,市面上出现了很多所谓的自动AI答题工具。大概可以分为两个流派:

  1. 通过OCR识别题目,然后用搜索引擎搜索答案告诉用户选什么。答案选择策略各异。做得比较简单的就是选搜索结果最多的那个为正确答案。
  2. 直接抓包这些APP下发的题目,然后用搜索引擎搜索答案。

可以看出,主要区别就是如何获取题目的文本。顺便吐槽一句,其实这些工具跟AI有半毛钱关系呀。对于第一种方式,是比较难防的。第二种方式解决办法主要有两种:

  1. 设计之初,使用图片下发题目,而不是直接下发题目文本;
  2. 如果已经走上了文本下发题目这条不归路,那么至少要做到接口防抓包。

这里我们谈一下接口如何防抓包。

为何可以成功抓包?

  1. 接口走HTTP,那么直接是明文传输,也不存在传输层的认证和加密问题,所见即所得。随着大家安全意识的增强,直接这么裸奔的产品越来越少。但是会有人因为各种原因就是不迁移到HTTPS,然后自己实现一个民科版的加密。我们极其不推荐这种做法,主要有以下几个原因:
    1. 大部分工程师都没有密码学背景,设计的算法基本很难完备的考虑数据机密性、完整性和不可抵赖性。
    2. 将应用层与数据传输层进行耦合不仅限制了通用性,如无法进行透明的流量转发,而且会带来非常高的系统维护和迁移成本。
  2. 接口走HTTPS。嗯,数据加密了不是?但是,通过中间人攻击(MitM)也是可以成功抓包的。这背后的基本原理是:在手机上安装一个中间人CA证书(如Charles证书) --> APP信任手机上的证书 --> 中间人可以成功解密流量进行抓包

如何防止抓包?

对于HTTPS API接口,如何防止抓包呢?既然问题出在证书信任问题上,那么解决方法就是在我们的APP中预置证书。在TLS/SSL握手时,用预置在本地的证书中的公钥校验服务器的数字签名,只有签名通过才能成功握手。由于数字签名是使用私钥生成的,而私钥只掌握在我们手上,中间人无法伪造一个有效的签名,因此攻击失败,无法抓包。

同时,为了防止预置证书被替换,在证书存储上,可以将证书进行加密后进行「嵌入存储」,如嵌入在图片中或一段语音中。这涉及到信息隐写的领域,这个话题我们有空了详细说。

预置证书/公钥更新问题

这样做虽然解决了抓包问题,但是也带来了另外一个问题:我们购买的证书都是有有效期的,到期前需要对证书进行更新。主要有两种方式:

  1. 提供预置证书更新接口。在当前证书快过期时,APP请求获取新的预置证书,这过渡时期,两个证书同时有效,直到安全完成证书切换。这种方式有一定的维护成本,且不易测试。
  2. 在APP中只预埋公钥,这样只要私钥不变,即使证书更新也不用更新该公钥。但是,这样不太符合周期性更新私钥的安全审计需求。一个折中的方法是,一次性预置多个公钥,只要任意一个公钥验证通过即可。考虑到我们的证书一般购买周期是3~5年,那么3个公钥,可以使用9~15年,同时,我们在此期间还可以发布新版本废弃老公钥,添加新公钥,这样可以使公钥一直更新下去。