On 11/01/2018 01:08, Ryan Sleevi wrote:
On Wed, Jan 10, 2018 at 6:35 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Agree.
Hence my suggestion that TLS-SNI-0next use a name under the customer's
domain (such as the name used for DNS-01), not a name under .invalid.
I thought it had been pointed out, but that doesn't actually address the
vulnerability. It presumes a hierarchal nature of certificate/account
management that simply does not align with how the real world and how real
providers work.
There are TWO related vulnerabilities at work here:
1. A lot of hosting providers allow users to provision certificates for
whatever.acme.invalid on SNI capable hosts, even though those users
are not owners of whatever domain was issued a challenge for the
number in the "whatever" part. Other than adding code to specifically
block "acme.invalid" to every software stack/configuration used by
hosting providers, this is almost unsolvable at the host provider end,
thus it may be easier to change the TLS-SNI-xx method in some way.
2. A much smaller group of hosting providers allow users to set up
hosting for subdomains of domains already provisioned for other users
(e.g. user B setting up hosting for whatever.acme.example.com when
user A is already using the host for example.com). This case is not
solved by changing the SNI challenge to be a subdomain of the domain
being validated. But since this is a smaller population of hosting
providers, getting them to at least enforce that the parent domain
user needs to authorize which other users can host a subdomain with
them is much more tractable, especially as it has obvious direct
security benefits outside the ACME context.
(Hosting providers who allow uploading certificates for the specific
DNS/SNI names of other users are a security problem in itself, as it
could allow e.g. uploading an untrusted exact domain cert to disrupt
another user's site having only a wildcard certificate).
Note that neither issue #1, nor issue #2 involves any kind of DNS
checking or walking, as it is perfectly OK for either or both involved
domains to not point their DNS at the configured server at any given
point in time. Of cause the CA would use their view of the DNS to
locate the host that will be probed for the challenge certificate, but
the actual host need not.
If a popular hosting package such as DirectAdmin suffers from issue #2,
then that would rule out the subdomain solution.
I can understand why it might seem intuitive - and, I agree, for providers
that create a lock between customer<->domain hierarchy, that might work -
but I would assert that they're not unique. And given that the concern is
precisely about those that *don't* do such bonding, it simply fails as a
solution.
In short, any solution that relies solely on the name will be technically
deficient in the real world, as this issue shows us. So any 'solution' that
proposes to shift the names around is to misunderstand that risk.
Disagree.
In the world of real hosting providers, sometimes users often don't get
to control the DNS of a domain purchased through that hosting provider,
while they might still have the ability to "purchase" (for free from
letsencrypt.org) their own certificates and the ability to configure
simple aspects of their website, such as available files.
If they can't control the DNS (for permission reasons), then they didn't
really purchase the domain. If they can't control the DNS for technical
reasons, then that's a deficiency of the hosting provider, and that doesn't
mean we should weaken the validation methods to accommodate those hosts who
can't invest in infrastructure.
Reality at many providers is like that. User's typically need to go
through hoops to transfer their domains to a 3rd party DNS hoster that
allows them to change DNS entries, and then the original hosting
provider stops helping them with their "unsupported" configuration,
thereby forcing them to switch to more expensive hosting providers too.
On the other hand, such providers will often (included or at extra fee)
allow provisioning arbitrary subdomains that are then typically added to
the HTTP(S) vhost configuration and the hosted DNS configuration, which
is good enough for TLS-SNI-modified-to-use-subdomain and HTTP-01, but
won't allow users to respond to the DNS-01 and may or may not allow or
users to respond to TLS-SNI-01 challenges (the feature allowing
responding to TLS-SNI-01 challenges is likely to suffer from security
issue #1).
The overall HTTPS-everywhere goal would fail if we restricted ACME to
only "the best" providers running "the most popular" server software in
"the latest version".
But wouldn't the backward compatibility features of TLS itself (and/or
some permissive TLS / https implementations) either ignore ALPN
extensions when they "know" they are only going to serve up HTTP/1.x
(not HTTP/SPDY) or complete the TLS handshake before deciding that they
don't have an "acme" service to connect to?
No. You've misunderstood how ALPN works then.
Just reread RFC7301. While it does say that servers SHALL reject such
connections (or at least not send back an ALPN indicating a selected
value, as if not implementing the extension), I find it likely that some
combinations of TLS implementation and application implementation will
blindly accept whatever unknown protocol identifier a client lists as
the only option.
And even if it wasn't so, most sites that do "control" the whole stack,
and run on their own dedicated machine and IP probably lack the ability
and/or patience to modify the https code in "their" web server.
Do you believe people are bespoke minting these ACME challenges on the fly?
Because that's not how it's working in the real world - it's being based on
tooling, generally directly integrated in the server to automatically
enroll, manage, and renew (and indeed, that is explicitly what is
recommended as the ACME integration). In such a model - i.e. how it works
today - that lack of ability/patience is a non-issue, because it's simply
handled by the ACME client without any additional work by the server
operator - the same as it is today.
No, but I do know that not every HTTPS server in existence supports
deep acme integration like Apache and a few other famous ones do.
Those are currently supported by using scripting to externally
reconfigure them to do their part in ACME negotiations, such as by
simply adding a TLS-SNI-01 challenge response certificate to the
existing SNI configuration of a server. But requiring them to support a
new protocol extension (in the form of a specially handled ALPN value or
otherwise) would not allow that.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
