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 protected]> wrote: > 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 > > On Fri, Nov 13, 2015 at 2:28 AM, Niklas Keller <[email protected]> wrote: > > 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 > > > > 2015-11-13 2:12 GMT+01:00 Peter Eckersley <[email protected]>: > >> > >> 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. > >> > >> On Thu, Nov 12, 2015 at 05:05:53PM -0800, Martin Thomson wrote: > >> > On 12 November 2015 at 16:44, Peter Eckersley <[email protected]> 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. > >> > > >> > _______________________________________________ > >> > Acme mailing list > >> > [email protected] > >> > https://www.ietf.org/mailman/listinfo/acme > >> > > >> > >> -- > >> Peter Eckersley [email protected] > >> Chief Computer Scientist Tel +1 415 436 9333 x131 > >> Electronic Frontier Foundation Fax +1 415 436 9993 > >> > >> _______________________________________________ > >> Acme mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/acme > > > > > > > > _______________________________________________ > > Acme mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/acme > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
