On Thursday, 30 June 2016 18:13:53 UTC+1, Peter Kurrasch wrote: > Let's be even more pointed: How do we know that *any* of the certs issued > through this ‎interface were issued to the right person for the right domain? > How can StartCom make that determination?
Assuming that * This was the only practical vulnerability that could lead to mis-issuance (other issues are listed in the article but without enough detail to be sure they were sufficient to cause mis-issuance - most certainly somebody independent of StartSSL should check these carefully) * StartSSL keep detailed sufficient records of the circumstances in which they issued certificates suitable to verify _for themselves_ what follows below * We're interested only in the same degree of confidence we have assigned to existing DV certificates, such as those verified by email to a WHOIS contact Then it seems we can achieve that by checking that the default /signfile URL was used for verification (not some arbitrary forced URL) and that no HTTP redirect was followed. This would mean either the applicant did own the site, or a hypothetical attacker was somehow able to arrange for /signfile, without redirection, to contain the desired value, which would be tricky even for most pastebin-type sites and impossible for an ordinary web site. I'm not _happy_ about this, as I understand it the CA/B already discussed a revision to the BRs that would require this sort of check to use the IETF-approved /.well-known/ prefix. Reason being it's not inconceivable that somewhere on the web is a site where an attacker can make paths like /signfile contain arbitrary text, it's a LOT less likely to have a site where they can do this to a path beginning /.well-known/acme-challenge/ Still though, it does achieve similar levels of confidence to the usual "send an email to an address we found in WHOIS and check the applicant can read it" approach we see today, and which there is seemingly no hurry to deprecate. If they don't have the records to check whether redirects were followed or whether the default path was used, then I agree they can't hope to achieve the usual levels of confidence in their own validation prior to the fix. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
