2015-11-13 14:56 GMT+01:00 Richard Barnes <[email protected]>: > 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).
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
