<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 6/11/2021 5:28 AM, Peter Gutmann wrote:<br>
</p>
<blockquote type="cite"
cite="mid:SY4PR01MB62517FE0C13BA792A00ED5BCEE349@SY4PR01MB6251.ausprd01.prod.outlook.com">
<pre class="moz-quote-pre" wrap="">Jerry Leichter <a class="moz-txt-link-rfc2396E" href="mailto:leichter@lrw.com" moz-do-not-send="true"><leichter@lrw.com></a> writes:
</pre>
<blockquote type="cite" style="color: #007cff;">
<pre class="moz-quote-pre" wrap="">The paper points out that the entire technique can be avoided if the web site
uses SNI <b class="moz-txt-star"><span class="moz-txt-tag">*</span>and marks SNI as required<span class="moz-txt-tag">*</span></b>.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">You don't even need SNI, the solution is in the certificate via the
extKeyUsage extension. However as with SNI it's widely ignored, and just as
widely set to garbage values.</pre>
</blockquote>
<p>The ALPACA attack works by redirecting a client connection for
protocol X to a server for protocol Y, so the that when
interpreted as protocol X the protocol Y messages create
interesting side effects on the client. This is exactly what
application protocol negotiation via ALPN addresses. If ALPN was
widely deployed, the attack would no be possible. It is probably
not widely deployed yet, but that is coming because ALPN is pretty
much the new port number. That was in any case the experience
during the early deployment of QUIC. Several servers would be
supporting multiple application layer protocols on top of
QUIC/TLS, and using the ALPN to connect to the specified protocol.
Unknown ALPN would result in a connection failure. If everything
runs on port 443, expect to see ALPN used to demux multiple
applications, from HTTP to DNS, VPN, etc.</p>
<p>-- Christian Huitema<br>
</p>
<p><br>
</p>
</body>
</html>