Thanks Wayne
From: Wayne Thayer <wtha...@mozilla.com> Sent: Friday, March 1, 2019 10:00 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance https://bugzilla.mozilla.org/show_bug.cgi?id=1531817 has been created to track this issue. On Wed, Feb 27, 2019 at 10:52 PM Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Hi Cynthia, We've figured out what happened with your certificate but are still looking at whether other certificates were issued using the same process. I don't have enough information to file an incident report yet, but I wanted to give you the update I promised earlier. Basically, here's what happened: 1. A validation agent took an email address provided during a chat session with you and set that email as a WHOIS admin email address. This email qualified as a constructed email (admin@domain) 2. The system marked the WHOIS as unavailable for automated parsing (generally, this happens if we are being throttled or the WHOIS info is behind a CAPTCHA), which allows a validation agent to manually upload a WHOIS document 3. The WHOIS document uploaded was a screen capture of WHOIS information that did not match the domain being requested but was close enough that the mis-match went unnoticed. 4. The validation agent specified the approval scope as id-addr.arpa which is normal for a domain approved by the admin listed in WHOIS. As a constructed email, the approval scope should have been limited to the scope set by the constructed address. 5. The validation agent specified that the email address listed in WHOIS matched the email address provided by you (admin@domain) and sent the email to authorize the legit cert 6 . When the validation completed successfully, the validation authorized your account for all certificates with the in-addr.arpa domain. This was because the scope was improperly set based on the validation agent's improper specification of the source of the email address. 7. During the review, no one noticed that the WHOIS document did not match the verification email nor did anyone notice that the email used for verification was actually a constructed email instead of the WHOIS admin email. 8. The mis-issued certificate essentially "piggy-backed" on the previous verification because of the erroneous approval scope set by the validation staff. Make sense? We shut down manual WHOIS verification while we figure out how to improve the process and eliminate validation mistakes like this. We'll post another update after we figure out how to improve the process and after the data review is complete. Jeremy -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org <mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Cynthia Revström via dev-security-policy Sent: Tuesday, February 26, 2019 4:17 PM To: Matthew Hardeman <mharde...@gmail.com <mailto:mharde...@gmail.com> > Cc: dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> ; b...@benjojo.co.uk <mailto:b...@benjojo.co.uk> Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance I am not so sure that is proper to have .arpa domains in the SANs. But I think the larger issue I think is that this might allow for non in-addr.arpa domains to be used as well. It was just that I just tried to get a cert for my domain for a test to see if that would be issued. And upon verifying the domain via email, I saw that on the page linked in the email it had an option along the lines of "Authorize in-addr.arpa for all orders on account #123456" (not that exact text but the same meaning). Now I am not sure if this would work, but I suspect if for example I got DNS control over cynthia.site.google.com <http://cynthia.site.google.com> , I could get a cert for google.com <http://google.com> if this is a systemic issue and not just a one off. - Cynthia On 2019-02-27 00:10, Matthew Hardeman wrote: > Is it even proper to have a SAN dnsName in in-addr.arpa ever? > > While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it > rarely has anything other than PTR and NS records defined. > > Here this was clearly achieved by creating a CNAME record for > 69.168.110.79.in-addr.arpa pointed to cynthia.re <http://cynthia.re> > <http://cynthia.re>. > > I've never seen any software or documentation anywhere attempting to > utilize a reverse-IP formatted in-addr.arpa address as though it were > a normal host name for resolution. I wonder whether this isn't a case > that should just be treated as an invalid domain for purposes of SAN > dnsName (like .local). > > On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy > <dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > <mailto:dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> >> wrote: > > Thanks Cynthia. We are investigating and will report back shortly. > ________________________________ > From: dev-security-policy > <dev-security-policy-boun...@lists.mozilla.org > <mailto:dev-security-policy-boun...@lists.mozilla.org> > <mailto:dev-security-policy-boun...@lists.mozilla.org > <mailto:dev-security-policy-boun...@lists.mozilla.org> >> on behalf > of Cynthia Revström via dev-security-policy > <dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > <mailto:dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> >> > Sent: Tuesday, February 26, 2019 12:02:20 PM > To: dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > <mailto:dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > > Cc: b...@benjojo.co.uk <mailto:b...@benjojo.co.uk> > <mailto:b...@benjojo.co.uk <mailto:b...@benjojo.co.uk> > > Subject: Possible DigiCert in-addr.arpa Mis-issuance > > Hello dev.security.policy > > > Apologies if I have made any mistakes in how I post, this is my first > time posting here. Anyway: > > > I have managed to issue a certificate with a FQDN in the SAN that I do > not have control of via Digicert. > > > The precert is here: https://crt.sh/?id=1231411316 > > SHA256: > 651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1 > > > I have notified Digicert who responded back with a generic response > followed by the certificate being revoked through OCSP. However I > believe that this should be wider investigated, since this cert was > issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area > that I do control though reverse DNS. > > > When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed > that the whole of in-addr.arpa became validated on my account, instead > of just my small section of it (168.110.79.in-addr.arpa at best). > > > To test if digicert had just in fact mis-validated a FQDN, I > tested with > the reverse DNS address of 192.168.1.1, and it worked and Digicert > issued me a certificate with 1.1.168.192.in-addr.arpa on it. > > > Is there anything else dev.security.policy needs to do with this? This > seems like a clear case of mis issuance. It's also not clear if > in-addr.arpa should even be issuable. > > > I would like to take a moment to thank Ben Cartwright-Cox and > igloo22225 > in pointing out this violation. > > > Regards > > Cynthia Revström > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > <mailto:dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > <mailto:dev-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
