On Sun, Sep 16, 2018 at 05:35:37PM +0200, Felix Fontein wrote: > Hi, > > > > > [...] Secondly, the entropy requirement > > > > prevents ACME clients from implementing a "naive" validation > > > > server that automatically replies to challenges without > > > > participating in the creation of the initial authorization > > > > request. > > > > > > > > IMPORTANT: I'm not sure I see how this applies to the HTTP > > > > mechanism -- couldn't you write a script to reply > > > > to .well-known/acme-challenge/<foo> with <foo>.<key thumbprint> > > > > for a fixed key thumbprint? The validation server would ned to > > > > know about the ACME account in question, but not about any > > > > individual authorization request. > > > > > > It would also need to know the <foo> value, which is not provided > > > in the validation request specifically to avoid this. > > > > As I said above, "[w]ell now I'm really confused." In the example > > HTTP challenge exchange (duplicated here): > > > > GET /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0 > > Host: example.org > > > > HTTP/1.1 200 OK > > Content-Type: application/octet-stream > > > > LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI > > > > Doesn't the path in the GET include the <foo>? > > Yes, and some people are already using this to add a generic > authorization replier (which needs the thumbprint of the account key). > For example, the acme.sh client supports this "stateless mode" (as it > is called there): > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode
Okay, that matches up with my understanding and maybe un-confuses me. But does this state of affairs nullify the text in the -14 about: [...] the entropy requirement prevents ACME clients from implementing a "naive" validation server that automatically replies to challenges without participating in the creation of the initial authorization request. ? -Benjamin > (There currently is also a discussion in the Let's Encrypt community > forum about this, see > https://community.letsencrypt.org/t/xss-via-acme-implementations/72295; > this is because some implementations do not restrict the allowed input > and thus allow XSS attacks, as described here: > https://labs.detectify.com/2018/09/04/xss-using-quirky-implementations-of-acme-http-01/) > > Cheers, > Felix > > _______________________________________________ > 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
