[Acme] HTTP redirects in validation [Was: Re: FW: Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)]

[Ilari Liusvaara <[e-mail]>]

On Thu, Aug 30, 2018 at 12:06:35PM +0000, Tim Hollebeek wrote:

> In the interest of openness, CAs were asked to disclose their
> current redirect behavior as a basis for a discussion about what
> the requirements should be.  Two CAs have done so.  Others are
> strongly encouraged to do so.

AFAIK, Let's Encrypt follows most HTTP-level (HTTP 3xx) redirects.
Including between TLDs (e.g. example.com -> foo.example is valid
and followed). However, port can not be specified and numeric IP
addresses can not be used. Of schemes, only http:// and https:// are
allowed.

I do not know all the specifics, including the precise list of status
codes (I would presume 301, 302, 303, 307 and 308) or the recursion
limit (I would presume it is at least 5).

The Let's Encrypt integration guide (aimed at big provoders that
want to get certificates on behalf of their customers) specifically
mentions redirects as a way to handle validation with multi-server
farms.

> There is no explicit text allowing them, so it could be argued that
> the BRs currently don’t allow following redirects.  On the other
> hand, redirects are part of HTTP, so the argument can also be made
> that “retrieving a web page” can involve arbitrary redirects,
> including potentially things like meta refresh and javascript.  The
> fact that such a diverse range of interpretations are possible is
> something we’d love to fix.

Even if following redirects are interpretted to be part of HTTP, that
only applies to 301 (and its alias 308), 302 (with its alias 307) and
303 redirects (and potential future ones). Not to any content-side
redirects from browser world.

The behavior of curl (a very widely-used non-browser HTTP client) is
to not follow any redirects by default. It does have option to
follow 3xx redirects (the 301 and 302 handling is buggy, but the bugs
are not relevant here and there exists further options to fix that).
It can not follow non-3xx "redirects" under any circumstancs.

> In particular, non-HTTP redirects that involve parsing page content
> introduce a great deal of complexity and risk into the validation
> process, and I’d like to clarify that that definitely isn’t allowed.

In general, it is good idea to be very picky about validation page
content (like ACME HTTP-01 is). This makes exploiting bad redirects
harder (especially non-injective ones, which are ocassionally seen).

Based on my (most probably wrong) reading of method 6, CAs can use
substring match for the required content. Which would make exploiting
some kinds of bad redirects for misvalidation much easier.

(That is not the only problem with method 6, it also contains language
(on ADN) very similar to very troublesome language in methods 9 and
10.)

> Redirects to a location outside of the domain being validated are
> viewed with particular suspicion by many, including me.  Redirects
> within the same domain seem less problematic, and indeed useful for
> handling large numbers of domains.  Though it’s not clear this solves
> a use case that is not already handled by the ability to validate
> and Authorization Domain Name and use it for subdomains.

The name to get a certificate for can be delegated user name (e.g.,
via CNAME), and in that case, the hoster can not use any related name.

Also, ACME does not let one specify what ADN to use in case there are
multiple possibilities for ADN to use in given validation.

Now, any reverse proxy (including Apache and Nginx) has a facility to
essentially perform invisble redirects on the server side (where the
server forwards the query to somewhere else and sends back the
response). I do not know to what degree one could replace redirects
used for validation in multi-server environments with such facilities.
However, I am aware of one security protocol, where one has to be able
to use such facility if one delegates, as configuration needs to be
consistent, and redirects are banned entierely.

> The main reason to allow redirects within a domain is if there is a
> unilateral redirect from example.com to www.example.com
> <http://www.example.com> , which is of course incredibly common.  It
> seems one should be able to validate example.com using that redirect.

I have no data on potentially exploitable redirects on-domain versus
off-domain, but I can say that even some http://foo.example to
https://foo.example redirects are exploitable (especially with
substring matching, but sometimes even without that).

The following two types of redirects seem practicularly troublesome:

- Redirect is from above validation directory (usually via global
  redirect of any resource on name). http:// to https:// redirects
  and redirects from example.com to www.example.com are usually of
  this kind. In contrast, redirects specific to validation directory
  are very probably secure.
- Redirects that are not injective (multiple source URLs map to the
  same target URL.). These are invariably from above validation
  directory redirects.

Then I saw somebody argue that redirecting .well-known globally
is misconfiguration. And indeed, that place is grab-bag of different
things, some of which prohibit redirects, some which leave things
implicit and some that explicitly follow redirects.



-Ilari