Re: [Acme] Content-Type and file extensions for HTTP01 challenges
Bryan Livingston <bryanlivingston@gmail.com> Fri, 13 November 2015 00:57 UTC
Return-Path: <bryanlivingston@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B636D1B3B76 for <acme@ietfa.amsl.com>; Thu, 12 Nov 2015 16:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjuNvWWdet-z for <acme@ietfa.amsl.com>; Thu, 12 Nov 2015 16:57:38 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44071B3B74 for <acme@ietf.org>; Thu, 12 Nov 2015 16:57:36 -0800 (PST)
Received: by lbblt2 with SMTP id lt2so45559711lbb.3 for <acme@ietf.org>; Thu, 12 Nov 2015 16:57:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MR9z0+36RGlxoXC+K3siMpjLVBncHrNn9L2Yzn3YyuU=; b=Spx68bYtZJc7OsTld60tJlpg+tDEVWIgup/f/oEEL4GOuwjN4PUfZqy0oHG86gMCU+ QCsDphMcEi5QY8lXyWUBF3Ehf0gS21Hsi/rYvQfzu2kZgr1Ly18Jvs8QGlriJYYzH6JQ QjYvbIZK0AVRtUXteNMPOY2vzYGC5laKKu2CQSe7FOY9rdhQMd9wNriNZWEWkTChVlnC QbYdgir8eP5FKnbtpci8UKYy8tmp+IDt9jkR9AkP10LtkAVOOwY59744/OlCT5HfqrZ/ sXHZrv6y+/ul0ISKeezBATdNnnlUptOI4YJudDZqC2WTNRzFNXu5ER14j+VyfyiVgRhE gllQ==
MIME-Version: 1.0
X-Received: by 10.112.149.5 with SMTP id tw5mr8837142lbb.50.1447376254811; Thu, 12 Nov 2015 16:57:34 -0800 (PST)
Received: by 10.25.37.19 with HTTP; Thu, 12 Nov 2015 16:57:34 -0800 (PST)
In-Reply-To: <20151113004436.GB18430@eff.org>
References: <20151113004436.GB18430@eff.org>
Date: Thu, 12 Nov 2015 17:57:34 -0700
Message-ID: <CABsBmKMv0fJ5Sf4p3UCWFpnhaBsWgrWtHC9SxEPAZVv2cYHArQ@mail.gmail.com>
From: Bryan Livingston <bryanlivingston@gmail.com>
To: Peter Eckersley <pde@eff.org>
Content-Type: multipart/related; boundary="047d7b3434d28672080524618bcc"
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/AtiF2Cnkz7-_oJomGrvk1PrO2ZU>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] Content-Type and file extensions for HTTP01 challenges
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2015 00:57:40 -0000
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] Content-Type and file extensions for HTTP0… Peter Eckersley
- Re: [Acme] Content-Type and file extensions for H… Richard Barnes
- Re: [Acme] Content-Type and file extensions for H… Bryan Livingston
- Re: [Acme] Content-Type and file extensions for H… Richard Barnes
- Re: [Acme] Content-Type and file extensions for H… Martin Thomson
- Re: [Acme] Content-Type and file extensions for H… Peter Eckersley
- Re: [Acme] Content-Type and file extensions for H… Niklas Keller
- Re: [Acme] Content-Type and file extensions for H… Richard Barnes
- Re: [Acme] Content-Type and file extensions for H… Bryan Livingston
- Re: [Acme] Content-Type and file extensions for H… Niklas Keller
- Re: [Acme] Content-Type and file extensions for H… Russ Housley
- Re: [Acme] Content-Type and file extensions for H… Bryan Livingston
- Re: [Acme] Content-Type and file extensions for H… Salz, Rich
- Re: [Acme] Content-Type and file extensions for H… Warren Kumari
- Re: [Acme] Content-Type and file extensions for H… Niklas Keller
- Re: [Acme] Content-Type and file extensions for H… Peter Eckersley
- Re: [Acme] Content-Type and file extensions for H… Niklas Keller
- Re: [Acme] Content-Type and file extensions for H… Bryan Livingston
- Re: [Acme] Content-Type and file extensions for H… Ted Hardie
- Re: [Acme] Content-Type and file extensions for H… Niklas Keller
- Re: [Acme] Content-Type and file extensions for H… Martin Thomson
- Re: [Acme] Content-Type and file extensions for H… Bryan Livingston
- Re: [Acme] Content-Type and file extensions for H… Niklas Keller
- Re: [Acme] Content-Type and file extensions for H… Bryan Livingston
- Re: [Acme] Content-Type and file extensions for H… Niklas Keller
- Re: [Acme] Content-Type and file extensions for H… Salz, Rich
- Re: [Acme] Content-Type and file extensions for H… Niklas Keller
- Re: [Acme] Content-Type and file extensions for H… Salz, Rich
- Re: [Acme] Content-Type and file extensions for H… Bryan Livingston