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

From: Peter Eckersley <[email-masked]>
Date: Thu, 12 Nov 2015 16:44:36 -0800

https://github.com/ietf-wg-acme/acme/pull/40 was just merged, but we
didn't actually get consensus that dropping Content-Type restrictions
altogether was a good idea.  

The options are:

 0.keep the old spec (Content-Type application/jose+json, no file 
   extensions allowed)

 1 keep the application/jose+json Content-Type requirement, add or allow
   a .jose file extension in the challenge

 2 switch to text/plain but add or allow a .txt file extension

 3 drop all Content-Type requirements (PR #40)

 4 leave the matter totally up to the CA (it can tell the client if
   there's a Content-Type requirement, and if so what it is)

I believe the purpose of the Content-Type requirement was to mitigate
against file-dropping attacks in web applications.  Everyone agrees that
option 0 is a bad spot on the security/usability tradeoff.  But is 3 the
best answer?  Can we keep some anti-file-dropping protection without
making manual authentication a pain?  Or are the two inherently the same
thing?

-- 
Peter Eckersley                            [email-masked]
Chief Computer Scientist          Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

---

From: Richard Barnes <[email-masked]>
Date: Thu, 12 Nov 2015 19:55:26 -0500

Sorry if I pulled the trigger on that one a bit early.  Happy to
revise, as always.

I think there was pretty feeling in the room at the IETF meeting that
Content-Type checking was not doing much.  Are we aware of any actual
scenarios where untrusted entities can write to .well-known
directories?  Because my base inclination is to encourage web admins
to protect against file dropping attacks by, well, not allowing users
to drop files in arbitrary locations.

--Richard

On Thu, Nov 12, 2015 at 7:44 PM, Peter Eckersley <[email-masked]> wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Bryan Livingston <[email-masked]>
Date: Thu, 12 Nov 2015 17:57:34 -0700

I'd like to advocate for 2 or 3 with a .txt extension added as it will just
work in all known default IIS configurations.

On IIS if there's no mime type (and there's not a mime type for
extensionless files by default) then no file can be served. So adding a
web.config file is manditory for us.

But that can still cause problems. Here's a screenshot of what happens of
the user happened to already have an extensionless mime type set on their
server.

On top of that there's still the problem of the handler mappings, which is
caused by ASP.net eating all the extensionless requests, even if there's a
static file present. The fix for that is described here:
http://stackoverflow.com/questions/11473632/extensionless-image-file-not-visible-in-iis7-5

---

From: Richard Barnes <[email-masked]>
Date: Thu, 12 Nov 2015 20:01:37 -0500

Hey Bryan,

Thanks for bringing these issues up.  Just to be clear, you're not running
into a requirement to set a Content-Type, right?  Rather, it's that IIS
doesn't handle file names without extensions very gracefully.

Apologies for not knowing IIS, but is there a way to do some local config
to have IIS treat the extensionless files correctly? A .htaccess file, by
analogy to Apache.

This obviously isn't the right list for discussing detailed deployment
issues, but I'd like to figure out if it's possible to hack around these
problems before we bake them into the spec.

--Richard

On Thu, Nov 12, 2015 at 7:57 PM, Bryan Livingston <[email-masked]
> wrote:

> I'd like to advocate for 2 or 3 with a .txt extension added as it will
> just work in all known default IIS configurations.
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Nov 2015 17:05:53 -0800

On 12 November 2015 at 16:44, Peter Eckersley <[email-masked]> wrote:
> But is 3 the best answer?

Of those presented, I think so.  I know that this isn't a great answer
(it's bad already, so bad must be OK), but being able to drop things
into .well-known opens a raft of other interesting attacks.

More seriously, I think that the other options all have deployment
complications that far outweigh the marginal benefit that extra
checking might provide.

---

From: Peter Eckersley <[email-masked]>
Date: Thu, 12 Nov 2015 17:12:59 -0800

I should have added another option, 3b, drop the Content-Type
restriction but allow file extensions.

Sounds like that would be a win on IIS.

---

From: Niklas Keller <[email-masked]>
Date: Fri, 13 Nov 2015 08:28:53 +0100

Once we add an extension, there will be default mime types in server
implementations for it for any webroot file. Where's the gain then? A
dropped file will just use the configured type. If you want to keep the
protection, we'll have to check the content type but don't allow an
extension, which would be bad for some servers to configure as others
pointed out, mainly IIS.

Regards, Niklas

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Nov 2015 08:56:43 -0500

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.

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).

--Richard

[1] http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml#well-known-uris-1

---

From: Bryan Livingston <[email-masked]>
Date: Fri, 13 Nov 2015 07:09:04 -0700

I was hoping that the server could just add a .txt to the end of the answer
string location that it ask the client to make available on the web server.
My client would just work with no changes in that case, and the python
client might as well.

On Fri, Nov 13, 2015 at 6:56 AM, Richard Barnes <[email-masked]> wrote:

> [1]
> http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml#well-known-uris-1
>

---

From: Niklas Keller <[email-masked]>
Date: Fri, 13 Nov 2015 15:24:12 +0100

> 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

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Nov 2015 09:56:52 -0500

> restriction but allow file extensions.

+1

This seems like the best balance.

Russ

---

From: Bryan Livingston <[email-masked]>
Date: Wed, 18 Nov 2015 08:56:46 -0700

Here's yet another problem reported by a user that would be solved by
switching to .txt answer locations.

https://github.com/Lone-Coder/letsencrypt-win-simple/issues/7

Typically web servers are already setup to host robots.txt so placing a
.txt file on a server should be the least demanding config wise.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Nov 2015 16:00:30 +0000

I am inclined to say that if the URL is arbitrary, why is it wrong to use something that will commonly be trivial to set up?  In other words, not as chair, I’m in favor of .txt
                /r$

---

From: Warren Kumari <[email-masked]>
Date: Wed, 18 Nov 2015 18:15:49 +0200

> .txt file on a server should be the least demanding config wise.

+1.

I initially had failures when trying to do manual, because my apache was
sending some weird content type. Apparently I'd configured this a long time
back, when installing some odd CMS package...

W

> On Fri, Nov 13, 2015 at 7:56 AM, Russ Housley <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Niklas Keller <[email-masked]>
Date: Wed, 18 Nov 2015 17:51:55 +0100

+1 for .txt, there are servers configured to serve only specific file
extensions.

Regards, Niklas

---

From: Peter Eckersley <[email-masked]>
Date: Wed, 18 Nov 2015 10:00:11 -0800

Sounds like we have emerging consensus around this version of 3b.  Does
anyone know of anything it breaks?

---

From: Niklas Keller <[email-masked]>
Date: Wed, 18 Nov 2015 19:37:57 +0100

> anyone know of anything it breaks?

Apart from any current implementation? Nope.

---

From: Bryan Livingston <[email-masked]>
Date: Wed, 18 Nov 2015 11:40:41 -0700

It wouldn't break my client if the ACME servers started appending .txt to
the answer location. I'm just taking that string and using it as a
filename. Does the python client do the same?

---

From: Ted Hardie <[email-masked]>
Date: Wed, 18 Nov 2015 10:45:01 -0800

On Wed, Nov 18, 2015 at 10:00 AM, Peter Eckersley <[email-masked]> wrote:

> > _

​So, the original 3b was "3b, drop the Content-Type
restriction but allow file extensions.​" That would allow both text/plain
(with a suffix of .txt if desired) and the original  application/jose+json
(with an appropriate suffix if desired).

Everyone seems to be +1'ing .txt, though, which would be "Switch content
type to text/plain, marked with a suffix as well as a content/type".

Is there anyone arguing for a different content type than text/plain at
this point?

regards,

Ted

> ______________________________________________
> > Acme mailing list
> > [email-masked]

---

From: Niklas Keller <[email-masked]>
Date: Wed, 18 Nov 2015 20:03:29 +0100

How would the transition work? Which URI does the server query then? Both?
Or would the client just send the extension in the challenge answer?

Regards, Niklas

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Nov 2015 12:00:58 -0800

> Or would the client just send the extension in the challenge answer?

Presumably, this would be a -02 or -03 version of the protocol and the
challenge would be identified as "http-02".

---

From: Bryan Livingston <[email-masked]>
Date: Wed, 18 Nov 2015 13:05:48 -0700

I was thinking that the Authorize Challenge token generated by the server
could have a .txt appended to it. Would the clients just work in that case,
and maybe not need to create a new challenge type?

---

From: Niklas Keller <[email-masked]>
Date: Wed, 18 Nov 2015 21:19:35 +0100

> and maybe not need to create a new challenge type?

No, that's not compatible, because the token is base64url encoded, that
doesn't include dots.

Regards, Niklas

---

From: Bryan Livingston <[email-masked]>
Date: Thu, 19 Nov 2015 10:56:48 -0700

We could have the ACME server look for both a .txt and extensenless answer,
if we'd rather not create an http-02 type at this time.

---

From: Niklas Keller <[email-masked]>
Date: Thu, 19 Nov 2015 18:05:50 +0000

I'd prefer that currently, way better than having a lot of different specs
with only minimal differences.

Bryan Livingston <[email-masked]> schrieb am Do., 19. Nov. 2015
18:56:

> We could have the ACME server look for both a .txt and extensenless
> answer, if we'd rather not create an http-02 type at this time.
>
>>> I was thinking that the Authorize Challenge token generated by the
>>> server could have a .txt appended to it. Would the clients just work in
>>> that case, and maybe not need to create a new challenge type?
>>>
>>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Nov 2015 19:23:34 +0000

Ø  I'd prefer that currently, way better than having a lot of different specs with only minimal differences.
We’re not going to have lots of different specs, we’re just bumping the version number because there are already deployments.  We should end up with just one.  Requiring complicated behavior as worse than bumping the revision number.

---

From: Niklas Keller <[email-masked]>
Date: Thu, 19 Nov 2015 20:34:43 +0100

2015-11-19 20:23 GMT+01:00 Salz, Rich <[email-masked]>:

> We’re not going to have lots of different specs, we’re just bumping the
> version number because there are already deployments.  We should end up
> with just one.  Requiring complicated behavior as worse than bumping the
> revision number.
>

Might not that bad as long as CAs offer both versions. But we have other
pending changes? because of insecure? DVSNI challenges. They should maybe
coordinated and updated at once.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Nov 2015 19:46:30 +0000

Ø  Might not that bad as long as CAs offer both versions. But we have other pending changes? because of insecure? DVSNI challenges. They should maybe coordinated and updated at once.

This is an RFC-in-progress.  We’re likely to settle on one version of each type.