[Cryptography] ALPACA

[Viktor Dukhovni]

> On 10 Jun 2021, at 9:34 am, Jerry Leichter <leichter at lrw.com> wrote:
> 
>> Well, TLS certificates can validate arbitrary Subject Alternative Names,
>> which can be more specific that just a hostname.  The real issue is that
>> hostnames are the only things that the CA/B forum issuers (i.e.  Let's
>> Encrypt) know how to issue DV certificates for....
> The paper points out that the entire technique can be avoided if the web site uses SNI *and marks SNI as required*.  The problem is that (a) "SNI required" is almost never used in practice; (b) even if requested, many existing servers don't enforce it, even some that say they do.  Of course, these two facts are self-reinforcing.

SNI, even if the receiving server were to refuse unexpected SNI values,
is only a partial solution to misuse of a single certificate for multiple
services.

When a wildcard certificate is used for multiple logical hosts, each one
can check the SNI value to make sure that it is the intended target of
the connection.  But when the same (logical) host supports multiple services
(SMTP, HTTP, POP, IMAP, ...), the SNI value will be same for all of them.

Operators would have to be careful to make sure to always define a separate
service-specific logical name to the underlying host, and deploy at most
one service per name.  That goes beyond the level of diligence one can
reasonably expect.

The real solution is to not reuse certificates, which is tricky when
multiple services run on the same logical host.  Certificate naming
limited to just the hostname without any service indication gets in
the way.

ALPN and/or DANE can help, but the issue will be with us for some time.

-- 
	Viktor.