blog.trnck.dev
Merge pull request #7 from filiptronicek/ft/ct-hello
authored by
Filip Troníček
and committed by
GitHub
940db4e8
bf6518a5
+140
-3
+66
_posts/2023-10-01-hello-internet.md
+66
_posts/2023-10-01-hello-internet.md
···
1
+
---
2
+
title: “Unveiling the Early Adopters of ECH and Kyber”
3
+
image: “ciphertrails_1.png"
4
+
---
5
+
6
+
As we're already accustomed to, the web becomes more secure every single day. This time around, we're discussing two emerging standards: Kyber-based hybrid post-quantum key exchange and <abbr title="Encrypted Client Hello">ECH</abbr>. Both are currently "Active Internet-Draft"s, yet they've already begun to roll out on major sites, at least one of them.
7
+
8
+
Let's start with Kyber. Now that we have quantum computers and their qubits are [ever-increasing](https://www.ibm.com/quantum/roadmap), we need to start thinking about protecting our quantum-vulnerable encryption algorithms against them. Fortunately, this neither means that your data is at risk now or that we need to replace all cryptography at use today. The algorithms vulnerable to quantum computers implementing Shor's algorithm are the ones used for key exchange, the part of an encrypted communication responsible for setting up a shared key. The biggest ones we're aiming to replace are <abbr title="Diffie-Hellman">DH</abbr>, <abbr title="Elliptic Curve Diffie-Hellman">ECDH</abbr>, and RSA.
9
+
10
+
<abbr title="The National Institute of Standards and Technology">NIST</abbr> is on track to standardize the Lattice-based CRYSTALS-Kyber algorithm as a successor to the vulnerable ones by 2024. Some very clever engineers have already embarked on real-world implementations: Signal [recently unveiled](https://signal.org/blog/pqxdh/) their take on the impending standard: Post-Quantum Extended Diffie-Hellman or PQXDH for short. The Signal protocol update features a hybrid[^1] blend of the current KEM, X25519 (ECDH), **and** CRYSTALS-Kyber, for a simple reason: new encryption standards, are often broken[^2], but rarely on day one. This approach mirrors the trajectory of the latest post-quantum hybrid key agreement algorithms for TLS: X25519Kyber512Draft00 and X25519Kyber768Draft00, both encapsulating X25519 + Kyber. They have been under beta testing by tech giants like Google and Cloudflare for over a year now. [[1](https://blog.cloudflare.com/post-quantum-for-all/)]
11
+
12
+
This means that most sites proxied through Cloudflare already support Kyber512 and Kyber768 key agreements. The list also includes Google-owned sites like YouTube and Google Drive, but to find Amazon or Microsoft's sites, you'd have to look elsewhere. Adoption is rolling out slowly but surely, but the bigger issue here are the clients: only the latest of Chrome supports it[^3], with other clients like `curl` and most programming language's network APIs still lacking any progress — most likely, we will have to wait until finalization of the [proposal](https://www.ietf.org/archive/id/draft-westerbaan-cfrg-hpke-xyber768d00-00.html) for further adoption.
13
+
14
+
Next is up ECH, which is solving an issue of the present. As you may know, technologies like [DoH](https://en.wikipedia.org/wiki/DNS_over_HTTPS) and [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) help to keep snoopers away from your network traffic. The last piece of the puzzle is ClientHello, the packet responsible for negotiating a TLS session, which contains information including the <abbr title="Server Name Indication">SNI</abbr>, describing the hostname the client is requesting a certificate for. This meant that, for anyone listening for packets traveling over the network (be that your place of work, school, or the ISP in case of your own home) they could see all the domains you were visiting. With Encrypted Client Hello, the SNI is encrypted (the encrypted part is called _inner ClientHello_) and only the common name (SNI) is requested in plaintext (_outer ClientHello_).
15
+
16
+
| Without ECH | With ECH |
17
+
| -------------------------------------- | ---------------------------------------- |
18
+
|  |  |
19
+
20
+
To summarize, ECH is a great feature for improving online privacy for many, the need to use a VPN (for personal use). It has great support among browsers, with both Chrome and Firefox leading the way[^4]. Client support is awesome to see, but in this case, we have an opposite problem to the one of Kyber PEMs: virtually no service accepts encrypted client hellos. I can only speculate about why I think that is: my opinions range from “c'mon, this was literally [released yesterday](https://blog.cloudflare.com/announcing-encrypted-client-hello/)” to the fact that this has big implications on security policies in enterprise and in places like schools, where some websites tend to be blocked. On the latter, the [Encrypted Client Hello Deployment Considerations](https://datatracker.ietf.org/doc/draft-campling-ech-deployment-considerations/) document explains these caveats in detail.
21
+
22
+
Personally, I hold ECH as a massive improvement to the overall digital landscape and would encourage anyone on Cloudflare to [flip the switch](https://dash.cloudflare.com/?to=/:account/:zone/ssl-tls/edge-certificates). For other providers, I'd wait until ECH becomes easily available for you.
23
+
24
+
I would love to make a blog post series out of this concept of web security: I named it "CipherTrail Chronicles" and hope to see you on episode 2. To close off the post on an informative note, here is an overview of some notable domains and their support status (as of September 2023)[^5]:
25
+
26
+
| Domain | Protocol | Key exchange | ECH support | Cloudflare? |
27
+
| ------------------ | -------- | --------------------- | ----------- | ----------- |
28
+
| `tiktok.com` | TLS 1.3 | X25519 | No | ❌ |
29
+
| `twitter.com` | TLS 1.3 | X25519 | No | ❌ |
30
+
| `github.com` | TLS 1.3 | X25519 | No | ❌ |
31
+
| `npmjs.com` | TLS 1.3 | X25519Kyber768Draft00 | No | ✅ |
32
+
| `cloudflare.com` | QUIC | X25519Kyber768Draft00 | No | ✅ |
33
+
| `apple.com` | TLS 1.3 | X25519 | No | ❌ |
34
+
| `netflix.com` | TLS 1.3 | X25519 | No | ❌ |
35
+
| `vercel.com` | TLS 1.3 | X25519 | No | ❌ |
36
+
| `google.com` | QUIC | X25519Kyber768Draft00 | No | ❌ |
37
+
| `instagram.com` | QUIC | X25519 | No | ❌ |
38
+
| `shopify.com` | QUIC | X25519Kyber768Draft00 | No | ✅ |
39
+
| `drive.google.com` | QUIC | X25519Kyber768Draft00 | No | ❌ |
40
+
| `youtube.com` | QUIC | X25519Kyber768Draft00 | No | ❌ |
41
+
| `interclip.app` | QUIC | X25519Kyber768Draft00 | Yes | ✅ |
42
+
43
+
Further reading:
44
+
- This blog is heavily based on the following writings from Cloudflare:
45
+
- Kyber
46
+
- [Defending against future threats: Cloudflare goes post-quantum](https://blog.cloudflare.com/post-quantum-for-all/)
47
+
- [Post-quantum cryptography goes GA](https://blog.cloudflare.com/post-quantum-cryptography-ga/)
48
+
- [NIST’s pleasant post-quantum surprise](https://blog.cloudflare.com/nist-post-quantum-surprise/)
49
+
- [The Quantum Menace](https://blog.cloudflare.com/the-quantum-menace/)
50
+
- ECH
51
+
- [ECH on Cloudflare Docs](https://developers.cloudflare.com/ssl/edge-certificates/ech/)
52
+
- [Encrypted Client Hello - the last puzzle piece to privacy](https://blog.cloudflare.com/announcing-encrypted-client-hello/)
53
+
54
+
References:
55
+
56
+
- [X25519Kyber768Draft00 hybrid post-quantum KEM for HPKE](https://www.ietf.org/archive/id/draft-westerbaan-cfrg-hpke-xyber768d00-00.html)
57
+
- Some domains taken from Cloudflare Radar's [Top 100 domains](https://radar.cloudflare.com/domains/) (on 09/30/2023)
58
+
- [PQXDH Spec](https://signal.org/docs/specifications/pqxdh/)
59
+
- [Encrypted Client Hello on Wikipedia](https://en.wikipedia.org/wiki/Server_Name_Indication)
60
+
61
+
[^1]: Hybrid means that it is a combination of two algorithms. This implies double encryption of all data, meaning that the key agreement can only be so weak as is its strongest component.
62
+
[^2]: [It](https://eprint.iacr.org/2022/214.pdf) [really](https://eprint.iacr.org/2022/975) [does](https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/round-1/official-comments/guess-again-official-comment.pdf) [happen](https://arxiv.org/abs/1805.05429), [a](https://arstechnica.com/information-technology/2022/08/sike-once-a-post-quantum-encryption-contender-is-koed-in-nist-smackdown/) [lot](https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/KRh8w03PW4E).
63
+
[^3]: Although only X25519Kyber768Draft00 is supported in Chrome.
64
+
[^4]: The only notable omission here is Safari and iOS / iPadOS in general.
65
+
[^5]: Tested on Chrome 117.0.5938.62 with both ECH and Kyber flags enabled.
66
+
+74
-3
assets/styles.scss
+74
-3
assets/styles.scss
···
16
16
--color-shadow: #f4f4f4;
17
17
--color-text: #000;
18
18
--color-text-secondary: #999;
19
-
--font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
19
+
--font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
20
+
Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
20
21
--hover-brightness: 1.2;
21
22
--justify-important: center;
22
23
--justify-normal: left;
···
26
27
--width-card-wide: 800px;
27
28
--width-content: 1080px;
28
29
}
29
-
30
30
31
31
// If a user adds a custom font, this component will stop it from bleeding into GitHub components:
32
32
.github-component {
···
89
89
text-decoration: none;
90
90
color: white !important;
91
91
}
92
+
93
+
table {
94
+
width: 100%;
95
+
border-collapse: collapse;
96
+
margin-top: 2rem;
97
+
margin-bottom: 2rem;
98
+
99
+
th,
100
+
td {
101
+
border: 1px solid #ddd;
102
+
text-align: left;
103
+
padding: 8px;
104
+
}
105
+
106
+
img {
107
+
width: 100%;
108
+
}
109
+
}
110
+
@media screen and (max-width: 600px) {
111
+
table,
112
+
thead,
113
+
tbody,
114
+
th,
115
+
td,
116
+
tr {
117
+
display: block;
118
+
}
119
+
thead tr {
120
+
position: absolute;
121
+
top: -9999px;
122
+
left: -9999px;
123
+
}
124
+
tr {
125
+
margin-bottom: 0.5rem;
126
+
}
127
+
td {
128
+
border: none;
129
+
border-bottom: 1px solid #ddd;
130
+
position: relative;
131
+
padding-left: 50%;
132
+
}
133
+
td:before {
134
+
position: absolute;
135
+
top: 6px;
136
+
left: 6px;
137
+
width: 45%;
138
+
padding-right: 10px;
139
+
white-space: nowrap;
140
+
content: attr(data-label);
141
+
}
142
+
}
143
+
92
144
@media (prefers-color-scheme: dark) {
145
+
table {
146
+
border-color: #444;
147
+
}
148
+
th,
149
+
td {
150
+
border-color: #444;
151
+
}
152
+
th {
153
+
background-color: #333;
154
+
}
155
+
tr:nth-child(even) {
156
+
background-color: #222;
157
+
}
158
+
tr:hover {
159
+
background-color: #444;
160
+
}
93
161
h1,
94
162
h2,
95
163
h3,
···
142
210
html {
143
211
content: "light";
144
212
}
213
+
th {
214
+
background-color: #f2f2f2;
215
+
}
145
216
}
146
217
@media (prefers-color-scheme: dark) {
147
218
html {
···
153
224
}
154
225
.logo:hover {
155
226
filter: brightness(var(--hover-brightness));
156
-
}
227
+
}
img/ciphertrail/no_ech.png
img/ciphertrail/no_ech.png
This is a binary file and will not be displayed.
img/ciphertrail/no_ech.webp
img/ciphertrail/no_ech.webp
This is a binary file and will not be displayed.
img/ciphertrail/with_ech.png
img/ciphertrail/with_ech.png
This is a binary file and will not be displayed.
img/ciphertrail/with_ech.webp
img/ciphertrail/with_ech.webp
This is a binary file and will not be displayed.
img/thumbnail/ciphertrails_1.png
img/thumbnail/ciphertrails_1.png
This is a binary file and will not be displayed.