[cabfpub] Pre-Ballot 169: Revised Validation Requirements

[Peter Bowen]

This doesn’t really help.  I just requested "http://www.$DOMAIN/.well-known/pki-validation/4c079484040e32529577b6a5aade31c5af6fe0c7” for the top 10000 domains from the Alexa 1M list.  More than 400 sites returned HTTP 200 in response.  Multiple of these sites included the token in HTTP Headers, meta tags in the HTML header, various locations in the HTML body, and pretty much everywhere else you can imagine.

So even filtering just for 200 is not enough.  It needs to be a request using one value and getting a different value (and not just a substring of the first value) in response.

Thanks,
Peter

> On Apr 29, 2016, at 4:28 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> A previous suggestion from the public was to explicitly only allow successful (200) results. Allowing 301 is arguably equally problematic.
> 
> On Fri, Apr 29, 2016 at 4:14 PM, Peter Bowen <pzb at amzn.com> wrote:
> Jeremy,
> 
> I’ve found a possible vulnerability with 3.2.2.4.6. Agreed-Upon Change to Website.  If the Random Value or Request Token is contained in the URI path, then certain websites will return it in the meta tag of the resulting page.  The pattern I found on a real website is:
> 
> Request http://www.example.com/.well-known/pki-validation/06ca919e1b1cf100e97fc2215c036a8c817f4443aa0afe5ca1a63db973a09e4b
> Returns 301 with Location: /search?q=.well-known%2Fpki-validation%2F06ca919e1b1cf100e97fc2215c036a8c817f4443aa0afe5ca1a63db973a09e4b
> Request http://www.example.com/search?q=.well-known%2Fpki-validation%2F06ca919e1b1cf100e97fc2215c036a8c817f4443aa0afe5ca1a63db973a09e4b
> Returns 200 with a page containing:
> <meta property="og:title" content=".well-known/pki-validation/06ca919e1b1cf100e97fc2215c036a8c817f4443aa0afe5ca1a63db973a09e4b: Search Results from Example">
> <meta property="og:url" content="http://www.example.com/search?q=.well-known%2Fpki-validation%2F06ca919e1b1cf100e97fc2215c036a8c817f4443aa0afe5ca1a63db973a09e4b”>
> 
> I think this method needs to be updated to preclude the CA from using a URL containing the Random Value or Request Token.
> 
> Thanks,
> Peter
> 
> > On Apr 26, 2016, at 2:40 PM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> >
> > Below (and attached) are the revised validation requirements. I’m looking for two endorsers.
> >
> > 3.2.2.4.6. Agreed-Upon Change to Website
> > Confirming the Applicant's control over the requested FQDN by confirming the presence of a Random Value or Request Token (contained in the content of a file or on a web page in the form of a meta tag) under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of Domain Validation, on the Authorization Domain Name that can be validated over an Authorized Port.
> >
> > If a Random Value is used, the CA or Delegated Third Party SHALL provide a Random Value unique to the certificate request and SHALL not use the Random Value after the longer of (i) 30 days or (ii) if the Applicant submitted the certificate request, the timeframe permitted for reuse of validated information relevant to the certificate (such as in Section 3.3.1 of these Guidelines or Section 11.14.3 of the EV Guidelines)
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>