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

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 <bryanlivingston@gmail.com
> 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.
>
> 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.
>
> [image: Inline image 1]
>
> 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
>
> On Thu, Nov 12, 2015 at 5:44 PM, Peter Eckersley <pde@eff.org> wrote:
>
>> 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                            pde@eff.org
>> Chief Computer Scientist          Tel  +1 415 436 9333 x131
>> Electronic Frontier Foundation    Fax  +1 415 436 9993
>>
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>

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

Attachment: image.png