Go 1.12 TLS 1.3 简单测试

发表于2019-03-03由daniel

在《TLS 1.3 当前(2018.10)支持与部署之现状》中，我们提到 Go 将在 1.12 中支持 TLS 1.3. 作为一个 Gopher, 终于在前几天盼来了 golang 1.12 的发布。

但是从 release 日志看，本次对选择性的部分支持 TLS 1.3, 且默认处于关闭状态：

Go 1.12 adds opt-in support for TLS 1.3 in the crypto/tls package as specified by RFC 8446. It can be enabled by adding the value tls13=1 to the GODEBUG environment variable. It will be enabled by default in Go 1.13.

如果要开启 TLS 1.3，需要设置环境变量：GODEBUG=tls13=1.

本次发布的 TLS 1.3 的 cipher suite 无法配置，也不支持 0-RTT 模式：

TLS 1.3 cipher suites are not configurable. All supported cipher suites are safe, and if PreferServerCipherSuites is set in Config the preference order is based on the available hardware.

Early data (also called “0-RTT mode”) is not currently supported as a client or server.

要知道，没有 0-RTT 的 TLS 1.3 是没有灵魂的，对本次版本的失望那是肯定的。但是依然在第一时间升级了 Go 版本，简单测试了一下国内网络环境下 TLS 1.3 与 1.2 的握手延迟。如果对 TLS 1.3 握手延迟还不太熟悉，可以参见拙文《TLS1.3/QUIC 是怎样做到 0-RTT 的》以及 TLS 1.3 Handshake Protocol.

测试代码

package main

import (
"crypto/tls"
"flag"
"log"
"time"
)

const (
MaxInt = int(^uint(0) &gt;&gt; 1)
MinInt = -MaxInt - 1
)

func main() {
var testCnt int
flag.IntVar(&amp;testCnt, "c", 10, "test count")
flag.Parse()

testAddr := "blog.cloudflare.com:443"

// tls 1.2
config := &amp;tls.Config{
SessionTicketsDisabled: true,
MaxVersion:             tls.VersionTLS12,
}
min12, max12, avg12 := testTLS(testCnt, testAddr, config)
log.Printf("tls 1.2 dial, min:%dms, max:%dms, avg:%dms", min12/1e6, max12/1e6, avg12/1e6)

// tls 1.3
config.MaxVersion = tls.VersionTLS13
min13, max13, avg13 := testTLS(testCnt, testAddr, config)
log.Printf("tls 1.3 dial, min:%dms, max:%dms, avg:%dms", min13/1e6, max13/1e6, avg13/1e6)

log.Printf("tls 1.3 vs 1.2: min:%.02f, max:%.02f, avg:%.02f", float32(min13)/float32(min12), float32(max13)/float32(max12), float32(avg13)/float32(avg12))

}

func testTLS(testCnt int, addr string, config *tls.Config) (min, max, avg int) {
min = MaxInt
max = MinInt
total := 0
for i := 0; i &lt; testCnt; i++ {
        hsStartTime := time.Now()
        conn, err := tls.Dial("tcp", addr, config)
        if err != nil {
            log.Fatalf("make tls connection failed:%v", err)
        }
        dialCost := int(time.Since(hsStartTime).Nanoseconds())
        if dialCost &gt; max {
max = dialCost
}
if dialCost &lt; min {
            min = dialCost
        }
        total += dialCost
        state := conn.ConnectionState()
        log.Printf("tls version:%#v", state.Version)
        conn.Close()
    }
    avg = total / testCnt
    return
}

package main

import (

"crypto/tls"

"flag"

"log"

"time"

)

const (

MaxInt = int(^uint(0) >> 1)

MinInt = -MaxInt - 1

)

func main() {

var testCnt int

flag.IntVar(&testCnt, "c", 10, "test count")

flag.Parse()

testAddr := "blog.cloudflare.com:443"

// tls 1.2

config := &tls.Config{

SessionTicketsDisabled: true,

MaxVersion: tls.VersionTLS12,

}

min12, max12, avg12 := testTLS(testCnt, testAddr, config)

log.Printf("tls 1.2 dial, min:%dms, max:%dms, avg:%dms", min12/1e6, max12/1e6, avg12/1e6)

// tls 1.3

config.MaxVersion = tls.VersionTLS13

min13, max13, avg13 := testTLS(testCnt, testAddr, config)

log.Printf("tls 1.3 dial, min:%dms, max:%dms, avg:%dms", min13/1e6, max13/1e6, avg13/1e6)

log.Printf("tls 1.3 vs 1.2: min:%.02f, max:%.02f, avg:%.02f", float32(min13)/float32(min12), float32(max13)/float32(max12), float32(avg13)/float32(avg12))

}

func testTLS(testCnt int, addr string, config *tls.Config) (min, max, avg int) {

min = MaxInt

max = MinInt

total := 0

for i := 0; i < testCnt; i++ {

hsStartTime := time.Now()

conn, err := tls.Dial("tcp", addr, config)

if err != nil {

log.Fatalf("make tls connection failed:%v", err)

}

dialCost := int(time.Since(hsStartTime).Nanoseconds())

if dialCost > max {

max = dialCost

}

if dialCost < min {

min = dialCost

}

total += dialCost

state := conn.ConnectionState()

log.Printf("tls version:%#v", state.Version)

conn.Close()

}

avg = total / testCnt

return

}

需要说明的是，这个测试是不严谨，里面没有考虑 cipher suite 以及 early data 的差异。测试结果定性意义大于定量意义。

测试结果

测试使用的目标服务器地址是 blog.cloudflare.com:443, 我的网络环境下，ping 延迟为 226 ms (1-RTT).

root@host:~/tmp# GODEBUG=tls13=1 go run tlst.go -c 20
2019/03/03 00:06:44 tls version:0x303
...
2019/03/03 00:07:02 tls 1.2 dial, min:497ms, max:2977ms, avg:952ms
2019/03/03 00:07:02 tls version:0x304
...
2019/03/03 00:07:17 tls 1.3 dial, min:320ms, max:2176ms, avg:755ms
2019/03/03 00:07:17 tls 1.3 vs 1.2: min:0.64, max:0.73, avg:0.79

root@host:~/tmp# GODEBUG=tls13=1 go run tlst.go -c 20

2019/03/03 00:06:44 tls version:0x303

...

2019/03/03 00:07:02 tls 1.2 dial, min:497ms, max:2977ms, avg:952ms

2019/03/03 00:07:02 tls version:0x304

...

2019/03/03 00:07:17 tls 1.3 dial, min:320ms, max:2176ms, avg:755ms

2019/03/03 00:07:17 tls 1.3 vs 1.2: min:0.64, max:0.73, avg:0.79

const (
    VersionSSL30 = 0x0300
    VersionTLS10 = 0x0301
    VersionTLS11 = 0x0302
    VersionTLS12 = 0x0303
    VersionTLS13 = 0x0304
)

const (

VersionSSL30 = 0x0300

VersionTLS10 = 0x0301

VersionTLS11 = 0x0302

VersionTLS12 = 0x0303

VersionTLS13 = 0x0304

)

从结果看，有如下结论：

TLS 1.3 平均比 TLS 1.2 建立连接的延迟低约 1-RTT，跟理论分析是吻合的。但是，
从 max 项可以看出，部分时候国内到目标服务器网络不稳定带来的波动比 TLS 本身协议优化的 RTT 大的多。因此，稳定高延迟的网络链路有时候比低延迟高抖动的网络更有实际意义。
TLS 建立在 TCP 基础上，TCP 的握手延迟在 TLS 层面是优化不掉的，或者说不是 TLS 的管辖范围，因此，在允许的情况下，尽量复用连接。

HTTP/3 已经箭在弦上，你准备好了吗？

发表于2019-02-06由daniel

去年的这个时候，国内的 web 网络环境开始普及和部署 HTTP/2. 时隔一年，HTTP/2 的普及程度有了显著提升，而各大CDN厂商普及的广度和速度一直走在行业前列。甚至有不少CDN厂商在直播以及部分HTTP场景还引入了 QUIC.

在拙文《当我们在谈论HTTP队头阻塞时，我们在谈论什么？》中，我们提到，HTTP/2 over QUIC 是当前唯一应用落地解决了传输层队头阻塞问题的HTTP实现。那个时候，无论是 HTTP/2 over TCP 还是 HTTP/2 over QUIC(UDP) 都被我们认为是 HTTP/2，只是传输层使用的协议不一样。这种略带暧昧的模糊叫法在2018年11月成为了历史：

在2018年10月28日的邮件列表讨论中，互联网工程任务组（IETF） HTTP和QUIC工作组主席Mark Nottingham提出了将HTTP-over-QUIC更名为HTTP/3的正式请求，以“明确地将其标识为HTTP语义的另一个绑定……使人们理解它与QUIC的不同”，并在最终确定并发布草案后，将QUIC工作组继承到HTTP工作组。在随后的几天讨论中，Mark Nottingham的提议得到了IETF成员的接受，他们在2018年11月给出了官方批准，认可HTTP-over-QUIC成为HTTP/3。

虽然看起来像是之前的 HTTP/2 over QUIC 换了一个名称（从我个人角度理解，取名为 HTTP/2.1也许更合适），但是其背后却体现了 IETF 对 HTTP 未来标准的态度和方向，也许几年以后来看这次名称的确立会更加明白其重要意义。

HTTP/3 与 HTTP/2 over QUIC 的区别

QUIC 将成为一个通用安全传输层协议

当前阶段，Google 实现的 QUIC 与 IETF 实现的 QUIC 是不兼容的。Google 版 QUIC 只能用于 HTTP/2，且在协议层面与 HTTP/2 有一些强绑定。如 QUIC 帧映射 HTTP/2 frame. 这就导致很多大厂都没有跟进 QUIC，使得 HTTP/2 over QUIC 基本只能在 Google 自家的 Chrome, Gmail 等软件中普及使用，一度给行业造成“只有Google在弄”的错觉。

纳入 IETF 以后，显然 Google 就不能这么玩了。QUIC 定位为一个通用安全传输层协议：

可以近似的认为 QUIC over UDP 将成为下一代（或替代）TLS over TCP. 也就是说， QUIC 将能应用于任何应用层协议中，只是当前阶段将优先在 HTTP 中进行应用和验证。

统一使用 TLS 1.3 作为安全协议

2018年，有几个重要的WEB标准终于尘埃落定，其中一个便是 RFC 8446 TLS 1.3. 这个标准对于降低延迟，改善用户体验，尤其是移动端的体验有非常重要的意义。在拙文《TLS1.3/QUIC 是怎样做到 0-RTT 的》中，我们提到虽然 TLS 1.3和 QUIC 都能做到 0-RTT，从而降低延迟，但是 QUIC 却自顾自地实现了一套安全协议。主要是因为当时 TLS 1.3 标准还没有发布，而 QUIC 又需要一套安全协议：

The QUIC crypto protocol is the part of QUIC that provides transport security to a connection. The QUIC crypto protocol is destined to die. It will be replaced by TLS 1.3 in the future, but QUIC needed a crypto protocol before TLS 1.3 was even started.

如今，TLS 1.3 标准已经发布，而 HTTP/3 也纳入 IETF，因此 QUIC 也就顺理成章的使用 TLS 1.3 作为其安全协议。Google 在这些方面倒是从来都不鸡贼和墨迹，点赞。

使用 QHPACK 头部压缩代替 HPACK

其实，QPACK与HPACK的设计非常类似，单独提出QPACK主要是更好的适配QUIC，同时也是 Google 将 QUIC 从与 HTTP/2 的耦合中抽离出来，与 IETF 标准完成统一的必要一步。

HTTP/3 问题与挑战

UDP 连通性问题

几乎所有的电信运营商都会“歧视” UDP 数据包，原因也很容易理解，毕竟历史上几次臭名昭著的 DDoS 攻击都是基于 UDP 的。国内某城宽带在某些区域更是直接禁止了非53端口的UDP数据包，而其他运营商及IDC即使没有封禁UDP，也是对UDP进行严格限流的。这点上不太乐观，但是我们相信随着标准的普及和推广落地，运营商会逐步改变对UDP流量的歧视策略。国外的情况会稍好一些，根据Google的数据，他们部署的QUIC降级的比例不到10%。

QUIC 不支持明文传输

对于用户来说，这是一个优势，并不是问题。对于国内内容审查环境来说是个不可忽视的坎。但QUIC以后毕竟也是基于TLS协议的，国内HTTPS都能普及下来，QUIC的普及也许会更乐观一些。

UDP 消耗资源多

当前阶段，UDP消耗的CPU资源多，且处理速度慢。这是不争的事实，但是我相信随着UDP应用的增多，内核和硬件的优化一定会跟上，直至达到或超过TCP的性能。而 QUIC 因为实在应用层实现，因此迭代速度更快，部署和更新难度和代价更小，能够一定程度缓解如TCP那样的协议僵化问题。

进一步了解 HTTP/3

如果希望全面的了解 HTTP/3，推荐 Daniel Stenberg （CURL 作者）的 HTTP/3 explained, 如果不想看英文，可以翻阅 Yi Bai 同学翻译了中文版本HTTP/3详解。

TLS 1.3 当前(2018.10)支持与部署之现状

发表于2018-10-13由daniel

今年8月10日，历经三年有余，TLS 1.3 最终版本终于得以发布——RFC 8446. 关于 RFC 的详细介绍可以进一步阅读 A Detailed Look at RFC 8446 (a.k.a. TLS 1.3). TLS 1.3 因为其在握手延迟以及安全性上的改进 (可以参考拙文《TLS1.3/QUIC 是怎样做到 0-RTT 的》)，毫不夸张的说，这是一件将深刻而长远影响互联网发展的技术里程碑。那么将 TLS 1.3 尽快平滑应用到线上环境无疑是一件势在必行的事情了。

在我日常的工作中，对于 TLS 1.3 的支持和部署主要关注两个层面：编程语言（Go, Java）、 API gateway (Nginx) 和浏览器. 下面分别介绍一下这三个层面 TLS 1.3 的支持部署现状。（因为 RFC 8446 已经发布，因此本文中说的支持如无特殊说明，都是指对最终版本 RFC 8446 的支持。）

编程语言对 TLS 1.3 的支持

Go 方面，官方在 TLS 1.3 draft 阶段一直没有跟进。因此，有一个关于对 TLS 1.3 支持的 issue 从 2015 年 open 至今都没有关闭：crypto/tls: add support for TLS 1.3. 其实 Go 发布版本和改进标准库的效率还是挺高的，对于 TLS 1.3 上的“不作为”更多是因为 Go 在兼容性上的承诺导致其并适合在最终版发布前实现互不兼容的 draft 方案。

而 Go 1.11 的发布时间（2018.08.24）与 RFC 8446 的发布时间比较接近，没有足够时间实现并发布该特性。从 golang-dev 小组讨论 Re: crypto/tls and TLS 1.3 看，由于 1.11 没有实现 TLS 1.3 ，那么 1.12 实现 TLS 1.3 基本是板上钉钉的事了：

The key scheduling fact is that the Go 1.11 feature freeze is just a week away, so we decided that it would be too rushed to merge the 1.3 patches for it. I definitely aim to have TLS 1.3 in Go 1.12.

根据惯例， Go 1.12 的发布时间将会是 2019.02~03. 如果期间你实在想用 Go 编程测试 TLS 1.3, 可以尝试使用 CloudFlare 的 tls-tris 库。根据 Go net/http 标准库维护者 Brad Fitzpatrick 的消息，这个库将会被合并到标准库作为 Go 官方 TLS 1.3 的实现。因此，如果你不得不用这个库干一些生成环境的活也大可放心，即使日后升级 Go 1.12, 接口兼容性还是有保证的。

Java 方面，由于 Java 11 出生时间好（2018.09.25）, 因此是出生就支持 TLS 1.3 RFC 8446, 具体可以参见 JEP 332: Transport Layer Security (TLS) 1.3. Java 11 是 LTS 版本，因此，如果有条件升级到 11, 推荐使用 Java 11 实现的 TLS 1.3 以及配套的 HttpClient；如果生产环境暂无法升级 Java 版本，推荐使用 OkHttp. 关于 Java Http Client 选型可以参见Java HTTP 组件库选型看这篇就够了。

Nginx 对 TLS 1.3 的支持

准确讲应该是 Nginx 所使用 SSL lib 对 TLS 1.3 的支持。在这方面，Boring SSL 跟进速度飞快，在 RFC 发布后第4天实现了对最终版本的支持。OpenSSL 虽然很早就跟进了 draft 的实现，但是对最终版本的支持需要 1.1.1-pre9 及以后的版本：

The OpenSSL git master branch (and the 1.1.1-pre9 beta version) contain our development TLSv1.3 code which is based on the final version of RFC8446 and can be used for testing purposes (i.e. it is not for production use). Earlier beta versions of OpenSSL 1.1.1 implemented draft versions of the standard. Those versions contained the macro TLS1_3_VERSION_DRAFT_TXT in the tls1.h header file which identified the specific draft version that was implemented. This macro has been removed from 1.1.1-pre9 and the current master branch.

TLSv1.3 is enabled by default in the latest development versions (there is no need to explicitly enable it). To disable it at compile time you must use the “no-tls1_3” option to “config” or “Configure”.

Although the latest 1.1.1 versions support the final standard version, other applications that support TLSv1.3 may still be using older draft versions. This is a common source of interoperability problems. If two peers supporting different TLSv1.3 draft versions attempt to communicate then they will fall back to TLSv1.2.

而第一个 OpenSSL 1.1.1 release 是在 2018.09.11, 因此如果你跟我一样是 OpenSSL 的死忠粉，当前阶段 Nginx 支持 TSL 1.3 的最佳方式是 Nginx 1.15.5 + OpenSSL 1.1.1. 而这种脏活、苦活、累活当然是交给 Docker 解决了：从源代码编译 nginx docker 镜像开启 TLS 1.3，项目地址可以参见 docker-nginx.

配置 Nginx 支持 TLS 1.3 需要注意一点：默认情况下 Nginx 因为安全原因，没有开启 TLS 1.3 0-RTT，可以通过添加 ssl_early_data on; 指令开启 0-RTT. 完整配置可以参考 nginx.conf.

浏览器对 TLS 1.3 的支持

当前阶段，Chrome 69 和 Firefox 62 都只支持到 draft 28, 而 draft 28 与最终版本是不兼容的。因此，要测试体验 TLS 1.3 final 需要使用 Chrome Beta 测试版。然后在 chrome://flags/#tls13-variant 开启 TLS 1.3 final:

行思錄 | Travel Coder

Arch, Coding, Life

分类目录归档：HTTP/2