-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathupdates.html
344 lines (333 loc) · 9.33 KB
/
updates.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="description" content="">
<meta name="author" content="">
<link rel="apple-touch-icon" sizes="180x180" href="media/img/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="media/img/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="media/img/favicon-16x16.png">
<link rel="manifest" href="media/img/site.webmanifest">
<meta name="theme-color" content="#ffffff">
<title>ALPACA Attack</title>
<link href="media/css/style.css" rel="stylesheet" type="text/css">
</head>
<body>
<header id="top">
<h1>ALPACA Attack</h1>
<div class="logo"></div>
</header>
<section id="intro">
<ul class="toc">
<li><a href="index.html#paper">Paper</a></li>
<li><a href="index.html#question-answer">Q&A</a></li>
<li><a href="libs.html">How to ALPN/SNI</a></li>
<li><a href="updates.html">Updates!</a></li>
</ul>
</section>
<section>
<h2>ALPACA Updates</h2>
<p>Here we give updates on the ALPACA attack.</p>
<ul>
<li><a href="#reeval">Reevaluation 2021 (by Jannik Hölling)</a>
</li>
</ul>
<h2 id="reeval">Reevaluation 2021 by Jannik Hölling</h2>
<p>In 2021, Jannik Hölling revisited the ALPACA attack in his bachelor
thesis under supervision by Juraj Somorovsky at the Paderborn University.
In his thesis, Jannik examined the feasibility of the recommended
countermeasures (ALPN, SNI) in TLS libraries, the state of countermeasures
in TLS applications, and the deployment level of these countermeasures on
the Internet. A big thanks to Jannik for these results! If you have any questions
for him, you can contact him at jannik.hoelling(at)uni-paderborn(dot)de.
</p>
<h3>TLS Libraries</h3>
<p>With respect to TLS libraries, Jannik found that all ten examined TLS libraries
allowed the strict validation of the ALPN extension. Three libraries required a manual
validation after the handshake in the client, and a callback function that is used
during the handshake in the server. Three other libraries supported strict ALPN
validation as an optional feature, and for the remaining four this was the standard behavior.</p>
<table>
<thead>
<tr>
<th>Library</th>
<th>Strict ALPN Client</th>
<th>Strict ALPN Server</th>
<th>TLS Alert 120</th>
</tr>
</thead>
<tbody>
<tr>
<td>OpenSSL 1.1.1</td>
<td>Manual (Post-Handshake)</td>
<td>Callback</td>
<td>Standard</td>
</tr>
<tr>
<td>BoringSSL</td>
<td><s>Manual (Post-Handshake)</s> <a href="https://git.amongbytes.com/kris/boringssl/commit/3e51757de2bf9beef7d249f22d255e4dd9ddb012">Standard</a></td>
<td>Callback</td>
<td>Standard</td>
</tr>
<tr>
<td>Botan 2.18.1</td>
<td>Manual (Post-Handshake)</td>
<td>Callback</td>
<td>Standard</td>
</tr>
<tr>
<td>GnuTLS 3.7.1</td>
<td>Option</td>
<td>Option</td>
<td>Manual (Post-Handshake)</td>
</tr>
<tr>
<td>BearSSL 0.6</td>
<td>Option</td>
<td>Option</td>
<td>Standard</td>
</tr>
<tr>
<td>wolfSSL 4.8.1</td>
<td>Option</td>
<td>Option</td>
<td>Standard</td>
</tr>
<tr>
<td>mbedTLS 2.18</td>
<td>Standard</td>
<td>Standard</td>
<td>Standard</td>
</tr>
<tr>
<td>Java 11</td>
<td>Standard</td>
<td>Standard</td>
<td>Standard</td>
</tr>
<tr>
<td>Go 1.17</td>
<td>Standard</td>
<td>Standard</td>
<td>Standard</td>
</tr>
<tr>
<td>Rustls 0.20</td>
<td>Standard</td>
<td>Standard</td>
<td>Standard</td>
</tr>
</tbody>
</table>
<p>For SNI support, Jannik found that the situation is more diverse and complicated.
Although all libraries allowed strict SNI validation, many required a callback function in the server.
For Java 11, strict SNI validation in the client was only an option for HTTPS, while other application
level protocols require manual validation after the handshake. Three libraries (BearSSL, Go, Rustls)
do not allow to send the proper TLS alert 112 in case of validation failure in the server.</p>
<table>
<thead>
<tr>
<th>Library</th>
<th>Strict SNI Client</th>
<th>Strict SNI Server</th>
<th>TLS Alert 112</th>
</tr>
</thead>
<tbody>
<tr>
<td>OpenSSL 1.1.1</td>
<td>Option</td>
<td>Callback</td>
<td>Standard</td>
</tr>
<tr>
<td>BoringSSL</td>
<td>Option</td>
<td>Callback</td>
<td>Standard</td>
</tr>
<tr>
<td>Botan 2.18.1</td>
<td>Standard</td>
<td>Callback</td>
<td>Standard</td>
</tr>
<tr>
<td>GnuTLS 3.7.1</td>
<td>Standard</td>
<td>Callback</td>
<td>Manual (Post-Handshake)</td>
</tr>
<tr>
<td>BearSSL 0.6</td>
<td>Standard</td>
<td>Callback</td>
<td style="background-color:#fffc9e;">Not Possible</td>
</tr>
<tr>
<td>wolfSSL 4.8.1</td>
<td>Option</td>
<td>Standard</td>
<td>Standard</td>
</tr>
<tr>
<td>mbedTLS 2.18</td>
<td>Option</td>
<td>Callback</td>
<td>Standard</td>
</tr>
<tr>
<td>Java 11</td>
<td>Manual (Post-Handshake)</td>
<td>Option</td>
<td>Standard</td>
</tr>
<tr>
<td>Go 1.17</td>
<td>Standard</td>
<td>Manual (Post-Handshake)</td>
<td style="background-color:#fffc9e;">Not Possible</td>
</tr>
<tr>
<td>Rustls 0.20</td>
<td>Standard</td>
<td>Manual (Post-Handshake)</td>
<td style="background-color:#fffc9e;">Not Possible</td>
</tr>
</tbody>
</table>
<p>Jannik recommends that TLS libraries implement optional
or standard support for ALPN and SNI strict validation,
so that callback functions and manual post-handshake
validation are not necessary. Libraries that do not support
sending the alert should provide a possibility to do so.
</p>
<h3>TLS Application Servers</h3>
<p>For application servers using TLS, Jannik found that of 14 servers, five (nginx,
exim, Filezilla, vsftp and Courier) now implemented strict
ALPN validation as a countermeasure to the ALPACA attack.
In addition, LightHTTPD already supported strict ALPN validation before
the ALPACA publication.</p>
<p>Sendmail only implemented countermeasures at the application protocol
level, and did not yet implement ALPN or SNI strict validation.</p>
<p>ProFTP and vsftpd were the only servers that implement strict SNI validation.</p>
<p>All servers with strict validation send the correct alert, except for FileZilla (which is using GnuTLS).</p>
<p>Jannik also found a <a href="https://bugs.exim.org/show_bug.cgi?id=2815">bug in Exim's ALPN serialization</a> that was the result of a misunderstanding of the TLS library documentation.
<p>In summary, only vsftp implemented strict ALPN and SNI validation fully, while the other application servers have room for improvements.</p>
<table>
<thead>
<tr>
<th>Server</th>
<th>ALPN</th>
<th>SNI</th>
<th>Comment</th>
</tr>
</thead>
<tbody>
<tr>
<td>nginx 1.21.4</td>
<td>Strict</td>
<td>Permissive</td>
<td></td>
</tr>
<tr>
<td>Apache 2.4.51</td>
<td>Permissive</td>
<td>Permissive</td>
<td></td>
</tr>
<tr>
<td>Lighthttpd 1.4.59</td>
<td>Strict</td>
<td>Permissive</td>
<td></td>
</tr>
<tr>
<td>Sendmail 8.17.1</td>
<td>No Support</td>
<td>No Support</td>
<td></td>
</tr>
<tr>
<td>Postfix 3.6.3</td>
<td>No Support</td>
<td>Permissive</td>
<td></td>
</tr>
<tr>
<td>Exim 4.95</td>
<td>Strict</td>
<td>Permissive</td>
<td>Bug in Serialization</td>
</tr>
<tr>
<td>OpenSMTP 6.8.0</td>
<td>Permissive</td>
<td>Permissive</td>
<td></td>
</tr>
<tr>
<td>Dovecot 2.3.13</td>
<td>No Support</td>
<td>Permissive</td>
<td></td>
</tr>
<tr>
<td>Courier 1.1.5</td>
<td>Strict</td>
<td>Permissive</td>
<td></td>
</tr>
<tr>
<td>Cyrus 3.4.2</td>
<td>Permissive</td>
<td>SNI</td>
<td>ALPN Strict for HTTPS</td>
</tr>
<tr>
<td>Pure-FTPd 1.0.49</td>
<td>No Support</td>
<td>Permissive</td>
<td></td>
</tr>
<tr>
<td>ProFTPD v1.3.8rc2</td>
<td>Permissive</td>
<td>Strict</td>
<td></td>
</tr>
<tr>
<td>FileZilla Server 1.1.0</td>
<td>Strict</td>
<td>Permissive</td>
<td></td>
</tr>
<tr>
<td>vsftpd 3.0.5</td>
<td>Strict</td>
<td>Strict</td>
<td></td>
</tr>
</tbody>
</table>
<h3>Internet Scan</h3>
<p>Finally, Jannik also scanned the IPv4 address space for application servers with ALPN and SNI support.
His scan demonstrates that by the end of 2021, almost no application servers have been updated with
strict ALPN or SNI validation. The one exception is the update of Exim 4.95, which caused 0.39%
of all STMPS servers on port 465 to implement strict ALPN validation.
</p>
</section>
<footer>
<p class="text-muted">Last updated 2021-02-16. The ALPACA
website is free to use under
a <a href="//creativecommons.org/publicdomain/zero/1.0/">CC0</a>
license. Web design by <a href="http://sarahmadden.com/">Sarah
Madden</a> and Christian Dresen. Adapted for ALPACA by Marcus
Brinkmann. The ALPACA logo was designed
by <a href="https://www.fiverr.com/tnhs_project">tnhs_project</a>.
| <a href="imprint.html">Imprint</a></p>
</footer>
</body>
</html>