RE: New certificate from compromised key
Thanks. We've revoked the cert and are looking into what happened and will post more information as we figure out what happened. -Original Message- From: dev-security-policy On Behalf Of Hanno Böck via dev-security-policy Sent: Friday, August 17, 2018 7:16 PM To: dev-security-policy@lists.mozilla.org Subject: New certificate from compromised key Hi, Some of you may remember the discussion about embedded private keys in Blizzard's battle.net software here: https://clicktime.symantec.com/a/1/XSDo7RID7Ms9aljAAOVAKoWLKhovvM_IrWUufr3rx9Y=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D=https%3A%2F%2Fgroups.google.com%2Fforum%2F%23%21msg%2Fmozilla.dev.security.policy%2Fpk039T_wPrI%2FVYi629oGCwAJ One of the certificates with a compromised key back then was issued by Digicert: https://clicktime.symantec.com/a/1/8QluDmhQ8mTJ30JiFIlP9Ea07fo7BeZ76x4vHiRQ4Es=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D=https%3A%2F%2Fcrt.sh%2F%3Fid%3D287530764 I noticed that a new certificate for a different domain, but with that same private key has been issued: https://clicktime.symantec.com/a/1/UztZ9c6dq7VDtqVztbSn0ztsSjdjchyTG87cjFnvYyc=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D=https%3A%2F%2Fcrt.sh%2F%3Fid%3D638323656 I tried to report it to rev...@digicert.com - but that address was replying with an error message... -- Hanno Böck https://clicktime.symantec.com/a/1/RJ969RojJELZVkzGgzMk2SN78MqUTvCuXRkZHP0djk4=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D=https%3A%2F%2Fhboeck.de%2F mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://clicktime.symantec.com/a/1/hc7xtvs26hqWeA42At7XWr7eeiDnWj1n6xCl__YKAGc=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-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
New certificate from compromised key
Hi, Some of you may remember the discussion about embedded private keys in Blizzard's battle.net software here: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/pk039T_wPrI/VYi629oGCwAJ One of the certificates with a compromised key back then was issued by Digicert: https://crt.sh/?id=287530764 I noticed that a new certificate for a different domain, but with that same private key has been issued: https://crt.sh/?id=638323656 I tried to report it to rev...@digicert.com - but that address was replying with an error message... -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
GoDaddy Revocation Disclosure
Revoke Disclosure GoDaddy has been proactively performing self-audits. As part of this process, we identified a vulnerability in our code that would allow our validation controls to be bypassed. This bug would allow for a Random Value that was generated for intended use with Method 3.2.2.4.6 and 3.2.2.4.7 and was validated using Method 3.2.2.4.2 by persons who were not confirmed as the domain contact. This bug was introduced November 2014 and was leveraged to issue a total of 865 certificates. The bug was closed hours after identification, and in parallel we started the scope and revocation activities. In accordance with CA/B Forum BR, section 4.9.1.1, all miss-issued certificates were revoked within 24 hours of identification. A timeline of the Events for Revocation are as follows: 8/13 9:30am – Exploit issue surfaced as possible revocation event. 8/13 9:30-4pm – Issue scope identification (at this point it was unknown), gathering certificate list 8/13 4pm – Certificate list finalized for revoke total 825 certs, Revoke notification sent to cert owners. 8/14 1:30pm – All certificates revoked. Further research identified 40 certificates which contained re-use of suspect validation information. 8/15 – 2pm – Additional certificates identified due to re-use. 8/15 – 2:30pm – Customers notified of pending revoke. 8/16 – 12:30pm – All certificated revoked. We stand ready to answer any questions or concerns. Daymion Certificate list which can be found in CRT.sh: Domain,CRT.sh link www.makancoaching.co.uk,https://crt.sh/?id=486518293 www.superguttervac.co.uk,https://crt.sh/?id=484345622 www.aloftimaging.co.uk,https://crt.sh/?id=486443992 www.inverroycrisismanagement.com,https://crt.sh/?id=505471354 *.lumeter.co.uk,https://crt.sh/?id=575952063 theredstartprimaryschool.co.uk,https://crt.sh/?id=448982417 www.glscoatings.co.uk,https://crt.sh/?id=471607541 www.thelittlecakekitchen.co.uk,https://crt.sh/?id=622887520 bri-lyncsbs1.corp.uxc.com.au,https://crt.sh/?id=445612142 mel-lyncsbs1.corp.uxc.com.au,https://crt.sh/?id=445611906 syd-lyncsbs1.corp.uxc.com.au,https://crt.sh/?id=445589055 www.photislight.co.uk,https://crt.sh/?id=627260711 sportsandplayconsulting.co.uk,https://crt.sh/?id=432887146 *.mca.uk.net,https://crt.sh/?id=476788955 www.underdogcoffee.co.uk,https://crt.sh/?id=445809844 www.kiyoraspa.co.uk,https://crt.sh/?id=448128056 www.kinesisclinic.co.uk,https://crt.sh/?id=444013056 www.homegenies.co.uk,https://crt.sh/?id=490198693 activemountaineering.co.uk,https://crt.sh/?id=452604481 www.brightonshellfish.co.uk,https://crt.sh/?id=48433 www.electroquip.co.uk,https://crt.sh/?id=454680891 www.melbournederbyshire.co.uk,https://crt.sh/?id=459144464 iih.org.uk,https://crt.sh/?id=452613519 *.growhub.co.uk,https://crt.sh/?id=445804391 www.weaversguesthouse.co.uk,https://crt.sh/?id=516764585 *.ctc-solutions.co.uk,https://crt.sh/?id=508837605 thothmail.saqqara.co.uk,https://crt.sh/?id=627917932 www.ringwoodhallhotel.com,https://crt.sh/?id=456471228 remote.yachtingpages.com,https://crt.sh/?id=453013515 www.waynesecigsupplies.co.uk,https://crt.sh/?id=484348665 www.thoth.saqqara.co.uk,https://crt.sh/?id=477514633 remote.mara.uk.com,https://crt.sh/?id=491400207 www.needfulthings.uk.com,https://crt.sh/?id=458812648 www.sensoryapphouse.com,https://crt.sh/?id=460684499 www.youcanbecome.co.uk,https://crt.sh/?id=486521955 *.speechbuilder.co.uk,https://crt.sh/?id=465020837 www.somerville-house.co.uk,https://crt.sh/?id=513011072 www.cameoclassics.co.uk,https://crt.sh/?id=627503851 praxis-godesberger-allee.de,https://crt.sh/?id=491408016 www.hydra-te.co.uk,https://crt.sh/?id=505470107 *.mca.uk.net,https://crt.sh/?id=476788955 *.mhsserver5.com,https://crt.sh/?id=575963842 www.dormagen-anwalt.de,https://crt.sh/?id=487910728 rosenbaumgruppe.eu,https://crt.sh/?id=484075777 remote.micheloud.net,https://crt.sh/?id=491387626 webmail.janssensmarket.com,https://crt.sh/?id=527896643 www.collegeinabox.co.uk,https://crt.sh/?id=500425581 www.lepetitcapelier.com,https://crt.sh/?id=497736247 www.total-michel.com,https://crt.sh/?id=486035156 www.thetoolbox.uk.com,https://crt.sh/?id=486038438 www.theinformer.org.uk,https://crt.sh/?id=488179681 outlook.comprovide.de,https://crt.sh/?id=575914237 www.vellastar.com,https://crt.sh/?id=493898204 mail.iarg.com.au,https://crt.sh/?id=501369255 www.iplacenotes.com,https://crt.sh/?id=487635287 isiportalorders.com,https://crt.sh/?id=496718880 www.ostsee-grundbesitz.de,https://crt.sh/?id=518520334 invia-koeln.de,https://crt.sh/?id=489938629 www.nikkihalliwell.com,https://crt.sh/?id=510581809 www.mckennaxmedia.co.uk,https://crt.sh/?id=513220692 www.indigoplumbingandheating.co.uk,https://crt.sh/?id=553607579 essentialtwenty.co.uk,https://crt.sh/?id=488171957 www.topthornarena.co.uk,https://crt.sh/?id=497039944 www.marstallwache.de,https://crt.sh/?id=512736683 www.feuerwehr-heinrichsheim.de,https://crt.sh/?id=551287541 kaizenlaw.co.uk,https://crt.sh/?id=492950320
Re: A vision of an entirely different WebPKI of the future...
On Friday, August 17, 2018 at 2:01:55 AM UTC-5, Peter Gutmann wrote: > That was actually debated by one country, that whenever anyone bought a domain > they'd automatically get a certificate for it included. Makes perfect sense, > owning the domain is a pretty good proof of ownership of the domain for > certificate purposes. It eventually sank under the cost and complexity of > registrars being allowed to operate CAs that were trusted by browsers [0]. That's very interesting. I would be curious to know the timing of this. Was this before or after massive deployment of DNSSEC by the registries? Also, I wish to clarify one tiny point again: I submit that only the Registries would be operating CAs and performing signature operations. Registrars would merely interface with the registries. This is an important and noteworthy distinction as there are far fewer Registries than Registrars (and additionally the burdens and complexities of operating as a Registry are significantly greater than the challenges of running a Registrar). As to the questions of the complexity of gaining trust by the browsers, I assume this question arose because the discussion centered around trying to fit such a scheme to the current WebPKI and its assumptions. I'm inclined to believe that if the browsers and the Registries and/or ICANN on their behalf wanted to create a secure and trustable mechanism that it could happen. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: A vision of an entirely different WebPKI of the future...
On Thursday, August 16, 2018 at 6:18:47 PM UTC-5, Jakob Bohm wrote: > The main cause of this seems to be that CT has allowed much more > vigorous prosecution of even the smallest mistake. Your argument > is a sensationalist attack on an thoroughly honest industry. I certainly didn't mean it as an attack. I do agree that CT has allowed for greater scrutiny and in turn we find more issues. Some of those issues are insignificant, some are of concern. I did not mean to in any way imply that there is currently a controversy involving malfeasance at a CA. In fact, my proposal stemmed in equal part from the concern that today's domain validation methods are susceptible to problems in network service layers which are known to be insecure and where vulnerabilities have been demonstrated. > That is a viewpoint promoted almost exclusively by a company that has > way too much power and is the subject of some serious public > prosecution. Cow-towing to that mastodont is not buy-in or agreement, > merely fear. In this particular aspect, I suspect you and I substantially agree. I don't hold any strong opinion against that particular company, but they certainly can bring much weight to any argument they make. I do see both sides of the argument. I'm on the record in several other threads in this group advocating for the value of strong identity in WebPKI certificates and advocating for continued inclusion of this information. My overall position on that has not changed and to reiterate clearly, one again, I'm definitely on the other side of that argument versus that certain large company. Having said that, IF and only IF consensus arrived in the other direction -- that the only meaningful subject identifiers in WebPKI certificates are the covered domain labels -- then I would assert that it makes sense to pursue a WebPKI in which the existing authority hierarchy be directly responsible for certificates within that hierarchy and in a manner constrained directly to the limits of each Registry's authority over the DNS. This, I believe, would be preferable to a multi-party system in which the best practices, at best, determine issuing authority on the basis of insecure proxies and consequences of the authoritative data. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: A vision of an entirely different WebPKI of the future...
Matthew Hardeman via dev-security-policy writes: >What if the various user agents' root programs all lobbied ICANN to impose a >new technical requirement upon TLD REGISTRY operators? That was actually debated by one country, that whenever anyone bought a domain they'd automatically get a certificate for it included. Makes perfect sense, owning the domain is a pretty good proof of ownership of the domain for certificate purposes. It eventually sank under the cost and complexity of registrars being allowed to operate CAs that were trusted by browsers [0]. Peter. [0] Some details simplified, and identities protected. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
