[(半)翻譯(稿)]再見ESNI，你好ECH
源：https://blog.cloudflare.com/encrypted-client-hello/
注：雖然這是一篇博客，但這絕對是一篇論文
直接跳到正文請搜索“ECH的細(xì)節(jié)"
現(xiàn)代Internet的多數(shù)通信都進(jìn)行了加密以保證內(nèi)容僅能被終點(如客戶端和服務(wù)器)理解。然而加密需要密鑰，通信的終點需要不暴露給潛在攻擊者得對密鑰取得一致。完成這一被稱為“密鑰交換”的任務(wù)的最廣泛方法，是TLS握手。
本文將會深入討論“加密client hello”(ECH)，TLS的一個能夠有效增強安全性的新擴展。目前在建立TLS連接時，一部分隱私敏感的參數(shù)是以明文協(xié)商的，這使得攻擊者能夠得知連接的元數(shù)據(jù)，包括終點的身份，他們?nèi)绾问褂眠B接，等。
ECH將加密整個握手過程，從而使得元數(shù)據(jù)得以保密。很重要的是，這也將使得一項[長期存在的隱私泄漏](https://blog.cloudflare.com/esni/)，即明文的服務(wù)器名稱指示(SNI)，得以修復(fù)。加密SNI非常重要，因為它是指示客戶端正與哪個服務(wù)器通信的最清晰的信號。然而，也許更為關(guān)鍵得，ECH同時也為未來的安全特性和性能改進(jìn)提供了基礎(chǔ)。
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.(無情略過)。目前，這一協(xié)議就Internet級別的部署而言尚未足夠成熟。本文的目的是在全握手加密(full handshake encryption)的道路上做一處路標(biāo)。
背景
(這我可以略嗎)
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是在用來指示域名的，因為服務(wù)器不知道你具體想訪問哪個網(wǎng)站，也就不知道該用什么證書，所以SNI要告訴服務(wù)器這個信息。ALPN是指示上層協(xié)議，比如說http/2和http/1.1，這樣服務(wù)器就知道應(yīng)用層該用什么協(xié)議了(ALPN也是建立HTTP/2通信時必須包含的流程)。SNI和ALPN是明文的，所以攻擊者就不僅能知道你在訪問bilibili.com，還能知道是不是在用h2(反正B站是支持的我剛看了)。
PAKE是一個(沒人的)技術(shù)，使用PAKE的服務(wù)器永遠(yuǎn)(包括注冊時)不需要得知，用戶的，明文密碼就可以驗證身份，但如果在握手流程中使用PAKE，就會令攻擊者獲得能夠用來區(qū)分用戶身份的信息。
那么，能夠解決所有這些問題的技術(shù)方案是什么呢，沒錯，就是握手加密。但是握手本身就是為了交換密鑰的，那握手加密要用的密鑰從哪來呢？那么，只將在對于密鑰交換來說必要的參數(shù)上使用明文，這就是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的最終標(biāo)準(zhǔn)并未實現(xiàn)全握手加密, 部分參數(shù)，包括SNI，依然是以明文發(fā)送的。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在內(nèi)的此類擴展創(chuàng)造了某種“雞與蛋”問題。
客戶端在驗證服務(wù)器身份(驗證身份是通過Certificate和CertificateVerify進(jìn)行的)，并且服務(wù)器確認(rèn)shared secret(Finished消息)之前不會不會加密任何流量，這些措施確保了密鑰交換的權(quán)威性，從而能夠避免中間人攻擊，即攻擊者偽裝成服務(wù)器與客戶端通信從而使其可以解密信息。因為服務(wù)器需要SNI來選擇證書，因此SNI必須在密鑰交換被鑒權(quán)之前發(fā)送。
一般來說,?保證鑒權(quán)發(fā)生之前的握手參數(shù)的保密性只有在客戶端和服務(wù)器此前以分享過密鑰的條件下才可能。但這一密鑰從何而來呢？
因為是密碼學(xué)和信息安全概念所以保留“權(quán)威性”這一信息安全術(shù)語。參考鏈接：
* 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的核心特性提出.?在該協(xié)議的早期版本中?(draft-10, circa 2015), 服務(wù)器會在(初次)握手過程中向客戶端提供一個長生存期的密鑰，并在后續(xù)握手中使用該密鑰(This design came from a protocol called OPTLS, which in turn was borrowed from the original QUIC proposal)。?該特性叫做 0-RTT(零往返時間)，其設(shè)計目的是允許客戶端在握手過程中即可發(fā)送應(yīng)用層數(shù)據(jù)(總而言之就是優(yōu)化性能)。?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.
最終這一特性并未被包含入最終標(biāo)準(zhǔn)(RFC 8446, published in 2018), mainly because its usefulness was outweighed by its added complexity. 尤其需要指出，這一特性并沒有對客戶端獲取服務(wù)器密鑰的初次握手提供附加保護，初次握手的握手參數(shù)依然是明文傳輸?shù)?/strong>。
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都標(biāo)注過了。
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的密鑰交換基于另一個關(guān)鍵協(xié)議：域名解析服務(wù)(DNS)。 為了使用ESNI連接網(wǎng)站，客戶端需要在查詢A或4A記錄的基礎(chǔ)上，增加一條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無論如何都會泄漏域名信息，以此實現(xiàn)的ESNI又有什么意義呢？基于HTTPS的DNS(DoH)使得通過這種方法實現(xiàn)的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公鑰的傳輸提供了權(quán)威信道，這避免了在客戶端局域網(wǎng)絡(luò)進(jìn)行的緩存投毒攻擊：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向前邁出了重要一步，但依然沒有實現(xiàn)全握手加密的目標(biāo)。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進(jìn)行密鑰分發(fā)的另一個缺點是，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的未來
在下一節(jié)中，我們將會詳細(xì)描述ECH，并介紹ECH如何解決ESNI的問題。Despite its limitations, however, the practical privacy benefit that ESNI provides is significant. CF會在ECH能夠用于生產(chǎn)環(huán)境之前繼續(xù)支持ESNI。
ECH的細(xì)節(jié)
ECH的目標(biāo)是加密整個ClientHello消息，從而閉合TLS 1.3和ESNI的缺口，并保護握手參數(shù)中的所有隱私敏感信息。?與ESNI類似，該協(xié)議使用基于DoH的公鑰以加密客戶端的初次握手。但ECH包含了對于密鑰分發(fā)的改進(jìn)從而使該協(xié)議對DNS緩存不一致性更加健壯。ESNI服務(wù)器會在解密ESNI失敗時中止連接，而ECH服務(wù)器則嘗試完成握手并為客戶端提供一個能用于重試連接的公鑰。
但服務(wù)器如何在無法解密ClientHello的情況下完成握手呢？如圖3所述，ECH協(xié)議實際上使用了兩種ClientHello消息：ClientHelloOuter，是通過明文發(fā)送的；ClientHelloInner，是加密并作為ClientHelloOuter的一個擴展發(fā)送的。服務(wù)器僅使用其中一個ClientHello完成握手。如果解密成功，那么將使用ClientHelloInner，否則使用ClientHelloOuter。
ClientHelloInner包含了客戶端想要用于連接的握手參數(shù)，這包含全部的敏感數(shù)據(jù)，如源服務(wù)器的SNI(在ECH語境下稱為后端服務(wù)器)，ALPN列表，諸如此類。ClientHelloOuter同樣也是一個完全成熟的ClientHello消息，但它不用于完成客戶端所希望的連接，而是由ECH服務(wù)提供者完成(ECH語境下稱為面向客戶端(client-facing)的服務(wù)器，下文簡稱CFS)，作為對客戶端其所希望的終點因解密失敗而無法訪問的信號。在這種情況下，CFS向客戶端發(fā)生其正確的，客戶端可用于重試握手的ECH公鑰，從而“糾正”客戶端的配置。這一機制與0-RTT中服務(wù)器分發(fā)公鑰的機制類似。
*不叫frontend叫client-facing，你咋不直接叫cloud-flare呢，學(xué)到了學(xué)到了，下次我再自稱前端的時候記得提醒我。
兩個ClientHello消息至少都必須包含足夠用于建立鑒權(quán)的密鑰交換的握手參數(shù)。尤其得，ClientHelloInner包含SNI，ClientHelloOuter同樣也包含SNI，該SNI在ECH解密失敗時，用于驗證CFS身份。如果連接通過ClientHelloOuter建立，客戶端應(yīng)立刻中斷連接，并以服務(wù)器提供的新的公鑰重試。客戶端不需要在ClientHelloOuter中指定ALPN，也不需要任何其他的，用于直到握手后行為的擴展。所有這些擴展被包含在封裝的ClientHelloInner中。
這一設(shè)計，我認(rèn)為，相當(dāng)優(yōu)雅得解決了之前的機制在安全得實施握手加密中遇到的大多數(shù)挑戰(zhàn)。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標(biāo)準(zhǔn)。IETF天下第一。
首先是一個重要的DNS特性，被稱為HTTPS資源記錄。這一特性被設(shè)計用于允許同一域名的多個HTTPS權(quán)威終點(aka CDN)公布不同的TLS能力(capability)。這使得基于DNS的密鑰分發(fā)成為可能，并解決了ESNI最初設(shè)計中一個未解決的挑戰(zhàn)。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的混合公鑰加密標(biāo)準(zhǔn)(HPKE)，其中描述了一個能夠廣泛用于多種應(yīng)用的可擴展的公鑰加密方案框架。尤其是，ECH全部的握手加密機制細(xì)節(jié)全部基于HPKE，這使得ECH大幅度簡化且易于分析。(巧合的是，HPKE同樣也是忘性DoH的主要組件之一)
參考鏈接：
* Alessandro Ghedini關(guān)于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/
前景展望
(標(biāo)題原文the road ahead，有點內(nèi)味了，顯然以下都是廢話，但說不定有丶用)
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連接不可區(qū)分這一目標(biāo)。換言之，當(dāng)你訪問，比如說，CF，之后的某一origin server時，網(wǎng)絡(luò)上你和CF之間的任何人都無從知道你在訪問哪一個origin，或者你與origin協(xié)商的任何隱私敏感的信息。除了提供直接的隱私保護外，這一目標(biāo)一旦實現(xiàn)，將允許TLS不損害隱私保護得實現(xiàn)某些新特性。
* 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的未來工作之一是抗流量分析。
* (所以我一開始就說了有內(nèi)味了)
* 流量分析:?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.
