源：https://blog.cloudflare.com/encrypted-client-hello/

注：虽然这是一篇博客，但这绝对是一篇论文

直接跳到正文请搜索“ECH的细节"

现代Internet的多数通信都进行了加密以保证内容仅能被终点(如客户端和服务器)理解。然而加密需要密钥，通信的终点需要不暴露给潜在攻击者得对密钥取得一致。完成这一被称为“密钥交换”的任务的最广泛方法，是TLS握手。

本文将会深入讨论“加密client hello”(ECH)，TLS的一个能够有效增强安全性的新扩展。目前在建立TLS连接时，一部分隐私敏感的参数是以明文协商的，这使得攻击者能够得知连接的元数据，包括终点的身份，他们如何使用连接，等。

ECH将加密整个握手过程，从而使得元数据得以保密。很重要的是，这也将使得一项[长期存在的隐私泄漏](https://blog.cloudflare.com/esni/)，即明文的服务器名称指示(SNI)，得以修复。加密SNI非常重要，因为它是指示客户端正与哪个服务器通信的最清晰的信号。然而，也许更为关键得，ECH同时也为未来的安全特性和性能改进提供了基础。

ECH is the product of close collaboration, facilitated by the IETF, between academics and the tech industry leaders, including Cloudflare, our friends at Fastly and Mozilla (both of whom are the affiliations of co-authors of the standard), and many others. This feature represents a significant upgrade to the TLS protocol, one that builds on bleeding edge technologies, like DNS-over-HTTPS, that are only now coming into their own.(无情略过)。目前，这一协议就Internet级别的部署而言尚未足够成熟。本文的目的是在全握手加密(full handshake encryption)的道路上做一处路标。

背景

(这我可以略吗)

The story of TLS is the story of the Internet. As our reliance on the Internet has grown, so the protocol has evolved to address ever-changing operational requirements, use cases, and threat models. The client and server don't just exchange a key. They negotiate a wide variety of features and parameters: the exact method of key exchange; the encryption algorithm; who is authenticated and how; which application layer protocol to use after the handshake; and much, much more. All of these parameters impact the security properties of the communication channel in one way or another.

SNI is a prime example of a parameter that impacts the channel's security. [The SNI extension](https://tools.ietf.org/html/rfc6066) is used by the client to indicate to the server the website it wants to reach. This is essential for the modern Internet, as it's common nowadays for many origin servers to sit behind a single TLS operator. In this setting, the operator uses the SNI to determine who will authenticate the connection: without it, there would be no way of knowing which TLS certificate to present to the client. The problem is that SNI leaks to the network the identity of the origin server the client wants to connect to, potentially allowing eavesdroppers to infer a lot of information about their communication. (Of course, there are other ways for a network observer to identify the origin — the origin's IP address, for example. But co-locating with other origins on the same IP address makes it much harder to use this metric to determine the origin than it is to simply inspect the SNI.)

Although protecting SNI is the impetus for ECH, it is by no means the only privacy-sensitive handshake parameter that the client and server negotiate. Another is the [ALPN extension](https://tools.ietf.org/html/rfc7301), which is used to decide which application-layer protocol to use once the TLS connection is established. The client sends the list of applications it supports — whether it's HTTPS, email, instant messaging, or the myriad other applications that use TLS for transport security — and the server selects one from this list, and sends its selection to the client. By doing so, the client and server leak to the network a clear signal of their capabilities and what the connection might be used for.

Some features are so privacy-sensitive that their inclusion in the handshake is a non-starter. [One idea that has been floated](https://tools.ietf.org/html/draft-barnes-tls-pake-04) is to replace the key exchange at the heart of TLS with [password-authenticated key-exchange (PAKE)](https://blog.cloudflare.com/opaque-oblivious-passwords/). This would allow password-based authentication to be used alongside (or in lieu of) certificate-based authentication, making TLS more robust and suitable for a wider range of applications. The privacy issue here is analogous to SNI: servers typically associate a unique identifier to each client (e.g., a username or email address) that is used to retrieve the client's credentials; and the client must, somehow, convey this identity to the server during the course of the handshake. If sent in the clear, then this personally identifiable information would be easily accessible to any network observer.

A necessary ingredient for addressing all of these privacy leaks is handshake encryption, i.e., the encryption of handshake messages in addition to application data. Sounds simple enough, but this solution presents another problem: how do the client and server pick an encryption key if, after all, the handshake is itself a means of exchanging a key? Some parameters must be sent in the clear, of course, so the goal of ECH is to encrypt all handshake parameters except those that are essential to completing the key exchange.

In order to understand ECH and the design decisions underpinning it, it helps to understand a little bit about the history of handshake encryption in TLS.

大概讲一下吧，SNI是在用来指示域名的，因为服务器不知道你具体想访问哪个网站，也就不知道该用什么证书，所以SNI要告诉服务器这个信息。ALPN是指示上层协议，比如说http/2和http/1.1，这样服务器就知道应用层该用什么协议了(ALPN也是建立HTTP/2通信时必须包含的流程)。SNI和ALPN是明文的，所以攻击者就不仅能知道你在访问bilibili.com，还能知道是不是在用h2(反正B站是支持的我刚看了)。

PAKE是一个(没人的)技术，使用PAKE的服务器永远(包括注册时)不需要得知，用户的，明文密码就可以验证身份，但如果在握手流程中使用PAKE，就会令攻击者获得能够用来区分用户身份的信息。

那么，能够解决所有这些问题的技术方案是什么呢，没错，就是握手加密。但是握手本身就是为了交换密钥的，那握手加密要用的密钥从哪来呢？那么，只将在对于密钥交换来说必要的参数上使用明文，这就是ECH了。

B站不允许外链，所以我在这里汇总下参考连接

* SNI: https://tools.ietf.org/html/rfc6066

* ALPN: https://tools.ietf.org/html/rfc7301

* PAKE: https://tools.ietf.org/html/draft-barnes-tls-pake-04

* PAKE(cloudflare): https://blog.cloudflare.com/opaque-oblivious-passwords/

TLS中的握手加密

(wdnmd你就不能一次把背景介绍完吗)

在TLS 1.3之前TLS中并不存在握手加密，In the wake of the Snowden revelations in 2013, the IETF community began to consider ways of countering the threat that mass surveillance posed to the open Internet. When the process of standardizing TLS 1.3 began in 2014, one of its design goals was to encrypt as much of the handshake as possible. 不幸的是，TLS 1.3的最终标准并未实现全握手加密, 部分参数，包括SNI，依然是以明文发送的。Let's take a closer look to see why.

The TLS 1.3 protocol flow is illustrated in Figure 1. Handshake encryption begins as soon as the client and server compute a fresh shared secret. To do this, the client sends a key share in its ClientHello message, and the server responds in its ServerHello with its own key share. Having exchanged these shares, the client and server can derive a shared secret. Each subsequent handshake message is encrypted using the handshake traffic key derived from the shared secret. Application data is encrypted using a different key, called the application traffic key, which is also derived from the shared secret. These derived keys have different security properties: to emphasize this, they are illustrated with different colors.

The first handshake message that is encrypted is the server's EncryptedExtensions. The purpose of this message is to protect the server's sensitive handshake parameters, including the server's ALPN extension, which contains the application selected from the client's ALPN list. Key-exchange parameters are sent unencrypted in the ClientHello and ServerHello.

All of the client's handshake parameters, sensitive or not, are sent in the ClientHello. Looking at Figure 1, you might be able to think of ways of reworking the handshake so that some of them can be encrypted, perhaps at the cost of additional latency (i.e., more round trips over the network). 然而, 包括SNI在内的此类扩展创造了某种“鸡与蛋”问题。

客户端在验证服务器身份(验证身份是通过Certificate和CertificateVerify进行的)，并且服务器确认shared secret(Finished消息)之前不会不会加密任何流量，这些措施确保了密钥交换的权威性，从而能够避免中间人攻击，即攻击者伪装成服务器与客户端通信从而使其可以解密信息。因为服务器需要SNI来选择证书，因此SNI必须在密钥交换被鉴权之前发送。

一般来说, 保证鉴权发生之前的握手参数的保密性只有在客户端和服务器此前以分享过密钥的条件下才可能。但这一密钥从何而来呢？

因为是密码学和信息安全概念所以保留“权威性”这一信息安全术语。参考链接：

* TLS 1.3: https://tools.ietf.org/html/rfc8446

* Pervasive Monitoring: https://tools.ietf.org/html/rfc7258

早期TLS 1.3中的全握手加密

有趣的是，full handshake encryption 曾作为TLS 1.3的核心特性提出. 在该协议的早期版本中 (draft-10, circa 2015), 服务器会在(初次)握手过程中向客户端提供一个长生存期的密钥，并在后续握手中使用该密钥(This design came from a protocol called OPTLS, which in turn was borrowed from the original QUIC proposal)。 该特性叫做 0-RTT(零往返时间)，其设计目的是允许客户端在握手过程中即可发送应用层数据(总而言之就是优化性能)。 In addition, it would have allowed the client to encrypt its first flight of handshake messages following the ClientHello, including its own EncryptedExtensions, which might have been used to protect the client's sensitive handshake parameters.

最终这一特性并未被包含入最终标准(RFC 8446, published in 2018), mainly because its usefulness was outweighed by its added complexity. 尤其需要指出，这一特性并没有对客户端获取服务器密钥的初次握手提供附加保护，初次握手的握手参数依然是明文传输的。

Nevertheless, this scheme is notable as the forerunner of other handshake encryption mechanisms, like ECH, that use public key encryption to protect sensitive ClientHello parameters. The main problem these mechanisms must solve is key distribution.

参考链接不列了，tfc都标注过了。

ECH之前的ESNI

ECH的直接前任是加密SNI(ESNI)扩展。正如名称所暗示的，ESNI的目的是为SNI提供保密性。To do so, the client would encrypt its SNI extension under the server's public key and send the ciphertext to the server. The server would attempt to decrypt the ciphertext using the secret key corresponding to its public key. If decryption were to succeed, then the server would proceed with the connection using the decrypted SNI. Otherwise, it would simply abort the handshake. The high-level flow of this simple protocol is illustrated in Figure 2.

ESNI的密钥交换基于另一个关键协议：域名解析服务(DNS)。 为了使用ESNI连接网站，客户端需要在查询A或4A记录的基础上，增加一条TXT记录查询来获得ESNI公钥。例如，为了获得crypto.dance的ESNI公钥，客户端需要查询__esni.crypto.dance的TXT记录。

$ dig _esni.crypto.dance TXT +short

"/wGuNThxACQAHQAgXzyda0XSJRQWzDG7lk/r01r1ZQy+MdNxKg/mAqSnt0EAAhMBAQQAAAAAX67XsAAAAABftsCwAAA="

The base64-encoded blob contains an ESNI public key and related parameters such as the encryption algorithm.

但如果明文的DNS无论如何都会泄漏域名信息，以此实现的ESNI又有什么意义呢？基于HTTPS的DNS(DoH)使得通过这种方法实现的ESNI成为可行, which enables encryption of DNS queries to resolvers that provide the DoH service (1.1.1.1 is an example of such a service.). DoH另一重要特性是为ESNI公钥的传输提供了权威信道，这避免了在客户端局域网络进行的缓存投毒攻击：in the absence of DoH, a local attacker could prevent the client from offering the ESNI extension by returning an empty TXT record, or coerce the client into using ESNI with a key it controls.

ESNI向前迈出了重要一步，但依然没有实现全握手加密的目标。Apart from being incomplete — it only protects SNI — it is vulnerable to a handful of sophisticated attacks, which, while hard to pull off, point to theoretical weaknesses in the protocol's design that need to be addressed.

ESNI was deployed by Cloudflare and enabled by Firefox, on an opt-in basis, in 2018, an  experience that laid bare some of the challenges with relying on DNS for key distribution. Cloudflare rotates its ESNI key every hour in order to minimize the collateral damage in case a key ever gets compromised. DNS artifacts are sometimes cached for much longer, the result of which is that there is a decent chance of a client having a stale public key. While Cloudflare's ESNI service tolerates this to a degree, every key must eventually expire. The question that the ESNI protocol left open is how the client should proceed if decryption fails and it can't access the current public key, via DNS or otherwise.

使用DNS进行密钥分发的另一个缺点是，several endpoints might be authoritative for the same origin server, but have different capabilities. 例如, "example.com"的A记录查询可能会提供两个不同IP中的一个，这两个IP分属两个不同的CDN。"_esni.example.com"可能会包含其中某一个CDN的公钥，但不可能两者都有。The DNS protocol does not provide a way of atomically tying together resource records that correspond to the same endpoint. In particular, it's possible for a client to inadvertently offer the ESNI extension to an endpoint that doesn't support it, causing the handshake to fail. Fixing this problem requires changes to the DNS protocol. (More on this below.)

ESNI的未来

在下一节中，我们将会详细描述ECH，并介绍ECH如何解决ESNI的问题。Despite its limitations, however, the practical privacy benefit that ESNI provides is significant. CF会在ECH能够用于生产环境之前继续支持ESNI。

ECH的细节

ECH的目标是加密整个ClientHello消息，从而闭合TLS 1.3和ESNI的缺口，并保护握手参数中的所有隐私敏感信息。 与ESNI类似，该协议使用基于DoH的公钥以加密客户端的初次握手。但ECH包含了对于密钥分发的改进从而使该协议对DNS缓存不一致性更加健壮。ESNI服务器会在解密ESNI失败时中止连接，而ECH服务器则尝试完成握手并为客户端提供一个能用于重试连接的公钥。

但服务器如何在无法解密ClientHello的情况下完成握手呢？如图3所述，ECH协议实际上使用了两种ClientHello消息：ClientHelloOuter，是通过明文发送的；ClientHelloInner，是加密并作为ClientHelloOuter的一个扩展发送的。服务器仅使用其中一个ClientHello完成握手。如果解密成功，那么将使用ClientHelloInner，否则使用ClientHelloOuter。

ClientHelloInner包含了客户端想要用于连接的握手参数，这包含全部的敏感数据，如源服务器的SNI(在ECH语境下称为后端服务器)，ALPN列表，诸如此类。ClientHelloOuter同样也是一个完全成熟的ClientHello消息，但它不用于完成客户端所希望的连接，而是由ECH服务提供者完成(ECH语境下称为面向客户端(client-facing)的服务器，下文简称CFS)，作为对客户端其所希望的终点因解密失败而无法访问的信号。在这种情况下，CFS向客户端发生其正确的，客户端可用于重试握手的ECH公钥，从而“纠正”客户端的配置。这一机制与0-RTT中服务器分发公钥的机制类似。

*不叫frontend叫client-facing，你咋不直接叫cloud-flare呢，学到了学到了，下次我再自称前端的时候记得提醒我。

两个ClientHello消息至少都必须包含足够用于建立鉴权的密钥交换的握手参数。尤其得，ClientHelloInner包含SNI，ClientHelloOuter同样也包含SNI，该SNI在ECH解密失败时，用于验证CFS身份。如果连接通过ClientHelloOuter建立，客户端应立刻中断连接，并以服务器提供的新的公钥重试。客户端不需要在ClientHelloOuter中指定ALPN，也不需要任何其他的，用于直到握手后行为的扩展。所有这些扩展被包含在封装的ClientHelloInner中。

这一设计，我认为，相当优雅得解决了之前的机制在安全得实施握手加密中遇到的大多数挑战。Importantly, the design of ECH was not conceived in a vacuum. The protocol reflects the diverse perspectives of the IETF community, and its development dovetails with other IETF standards that are crucial to the success of ECH. IETF牛**，ECH的成功离不开其他很多重要的IETF标准。IETF天下第一。

首先是一个重要的DNS特性，被称为HTTPS资源记录。这一特性被设计用于允许同一域名的多个HTTPS权威终点(aka CDN)公布不同的TLS能力(capability)。这使得基于DNS的密钥分发成为可能，并解决了ESNI最初设计中一个未解决的挑战。For a deep dive into this new record type and what it means for the Internet more broadly, check out Alessandro Ghedini's recent blog post on the subject.欲知后事如何，去听Alessandro Ghedini的分解吧。

然后是CFRG的混合公钥加密标准(HPKE)，其中描述了一个能够广泛用于多种应用的可扩展的公钥加密方案框架。尤其是，ECH全部的握手加密机制细节全部基于HPKE，这使得ECH大幅度简化且易于分析。(巧合的是，HPKE同样也是忘性DoH的主要组件之一)

参考链接：

* Alessandro Ghedini关于HTTPS resource record的博文: https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/

* HPKE: https://tools.ietf.org/html/draft-irtf-cfrg-hpke-06

* 忘性DoH: https://blog.cloudflare.com/oblivious-dns/

前景展望

(标题原文the road ahead，有点内味了，显然以下都是废话，但说不定有丶用)

The current ECH specification is the culmination of a multi-year collaboration. At this point, the overall design of the protocol is fairly stable. In fact, the next draft of the specification will be the first to be targeted for interop testing among implementations. Still, there remain a number of details that need to be sorted out. Let's end this post with a brief overview of the road ahead.

抗流量分析

ECH最终希望确保对不同origin的同一CFS的TLS连接不可区分这一目标。换言之，当你访问，比如说，CF，之后的某一origin server时，网络上你和CF之间的任何人都无从知道你在访问哪一个origin，或者你与origin协商的任何隐私敏感的信息。除了提供直接的隐私保护外，这一目标一旦实现，将允许TLS不损害隐私保护得实现某些新特性。

* CF: 除了我们以外的任何人(笑)

Encrypting the ClientHello is an important step towards achieving this goal, but we need to do a bit more. An important attack vector we haven't discussed yet is traffic analysis. This refers to the collection and analysis of properties of the communication channel that betray part of the ciphertext's contents, but without cracking the underlying encryption scheme. For example, the length of the encrypted ClientHello might leak enough information about the SNI for the adversary to make an educated guess as to its value (this risk is especially high for domain names that are either particularly short or particularly long). It is therefore crucial that the length of each ciphertext is independent of the values of privacy-sensitive parameters. The current ECH specification provides some mitigations, but their coverage is incomplete. Thus, improving ECH's resistance to traffic analysis is an important direction for future work.

简述：(但是)，(例如)，ClientHelloInner的长度可能会暴露信息(尤其对于名字特别短和名字特别长的域名)，因此，ECH的未来工作之一是抗流量分析。

* (所以我一开始就说了有内味了)

* 流量分析: https://tools.ietf.org/html/draft-irtf-pearg-website-fingerprinting-01

The spectre of ossification

(太长不译，只划重点)

An important open question for ECH is the impact it will have on network operations.

One of the lessons learned from the deployment of TLS 1.3 is that upgrading a core Internet protocol can trigger unexpected network behavior. Cloudflare was one of the first major TLS operators to deploy TLS 1.3 at scale; when browsers like Firefox and Chrome began to enable it on an experimental basis, they observed a significantly higher rate of connection failures compared to TLS 1.2. The root cause of these failures was network ossification, i.e., the tendency of middleboxes — network appliances between clients and servers that monitor and sometimes intercept traffic — to write software that expects traffic to look and behave a certain way. Changing the protocol before middleboxes had the chance to update their software led to middleboxes trying to parse packets they didn't recognize, triggering software bugs that, in some instances, caused connections to be dropped completely.

This problem was so widespread that, instead of waiting for network operators to update their software, the design of TLS 1.3 was altered in order to mitigate the impact of network ossification. The ingenious solution was to make TLS 1.3 "look like" another protocol that middleboxes are known to tolerate. Specifically, the wire format and even the contents of handshake messages were made to resemble TLS 1.2. These two protocols aren't identical, of course — a curious network observer can still distinguish between them — but they look and behave similar enough to ensure that the majority of existing middleboxes don't treat them differently. Empirically, it was found that this strategy reduced the connection failure rate enough to make deployment of TLS 1.3 viable.

Once again, ECH represents a significant upgrade for TLS for which the spectre of network ossification looms large. The ClientHello contains parameters, like SNI, that have existed in the handshake for a long time, and we don't yet know what the impact will be of encrypting them. In anticipation of the deployment issues ossification might cause, the ECH protocol has been designed to look as much like a standard TLS 1.3 handshake as possible. The most notable difference is the ECH extension itself: if middleboxes ignore it — as they should, if they are compliant with the TLS 1.3 standard — then the rest of the handshake will look and behave very much as usual.

It remains to be seen whether this strategy will be enough to ensure the wide-scale deployment of ECH. If so, it is notable that this new feature will help to mitigate the impact of future TLS upgrades on network operations. Encrypting the full handshake reduces the risk of ossification since it means that there are less visible protocol features for software to ossify on. We believe this will be good for the health of the Internet overall.

Conclusion

The old TLS handshake is (unintentionally) leaky. Operational requirements of both the client and server have led to privacy-sensitive parameters, like SNI, being negotiated completely in the clear and available to network observers. The ECH extension aims to close this gap by enabling encryption of the full handshake. This represents a significant upgrade to TLS, one that will help preserve end-user privacy as the protocol continues to evolve.

The ECH standard is a work-in-progress. As this work continues, Cloudflare is committed to doing its part to ensure this important upgrade for TLS reaches Internet-scale deployment.