Re: [Acme] Content-Type and file extensions for HTTP01 challenges

[Niklas Keller <[e-mail]>]

2015-11-13 14:56 GMT+01:00 Richard Barnes <[e-mail]>:

> Like I said before, the question here is not dropped file protection.
> That's something that admins need to prevent explicitly.  (If you're
> allowing untrusted clients to write to .well-known, they can already
> hijack your domain in several ways [1].)  The question here is whether
> we need to allow file extensions to avoid issues in deployment with
> some servers.
>
> I would still like to avoid adding a file extension, but supposing we
> did, what would it look like?  We can't just have the client
> unilaterally add an extension without telling the server, since the
> server needs to know what URI to query to get the validation response.
> ISTM that the right answer here would be to generalize and have the
> client specify the file name within .well-known/acme-challenge/ and
> send it to the server in its response.
>

Is there any reason to avoid a file extension? If we don't care about the
content-type header, it doesn't matter. If we want a specific content-type
header, a file extension seems like the best idea to me.

If we decide on an extension, there should be one and then the server
knows the URI again, I don't see any problem here.

Regards, Niklas


> I'm not crazy about that solution, but I could probably live with it
> if we decide that it's too hard for admins to hack around having a
> standard name.  The only additional threat scenario that occurs to me
> is if there's some name within .well-known/acme-challenge/ that an
> untrusted client could co-opt into serving his challenge response
> (e.g., a simlink to untrusted).