Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
On 2017-12-09 at 08:59 -0700, Wayne Thayer wrote: > It can be confusing even for people following these things. That's where I > think collecting problem reporting info from audited sub-CAs in CCADB would > help. > > For everyone else, finding the correct problem reporting information is > mostly a matter of luck. Perhaps we should require an email address be > included in the end-entity certificate? Unless that info was exposed in the > browser, it would still be difficult to find, but at least it would then be > in a consistent location. Rather than an email, I think it should be a url. That could be an email through the use of mailto:, but I suspect CAs will find preferable to provide a web page where they explain what it is for, how to submit, etc. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
On 12/09/2017 01:50 AM, Kurt Roeckx via dev-security-policy wrote: > But it's not obvious to me who to contact to revoke a given > certifiate, and it would be really useful that given a certificate > it would be obvious what to do, who to contact, to get it revoked. Could it be useful to establish a practice of including such contact information in the certificate itself, e.g. requiring a URI in some standardized key containing the contact point? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
It can be confusing even for people following these things. That's where I think collecting problem reporting info from audited sub-CAs in CCADB would help. For everyone else, finding the correct problem reporting information is mostly a matter of luck. Perhaps we should require an email address be included in the end-entity certificate? Unless that info was exposed in the browser, it would still be difficult to find, but at least it would then be in a consistent location. It may be related to that bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1418451 The certificate or a easily accessible public database should contains the information of who really is responsible for the issuance and revocation of the certificate. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
On Sat, Dec 9, 2017 at 7:50 AM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Sat, 9 Dec 2017 09:51:59 +0100 > Hanno Böck via dev-security-policy > wrote: > > > On Fri, 8 Dec 2017 16:43:48 -0700 > > Wayne Thayer via dev-security-policy > > wrote: > > > > > The root CA is ultimately responsible for subordinate CAs it has > > > signed. > > > > I see a problem with that, as this is far from obvious. > > I saw "responsibility" here as meaning responsibility to the Trust > Stores on behalf of the Relying Parties. For the Relying Parties > themselves I think the right pattern is: Try filing a Problem Report > with the Issuer, if the result isn't satisfactory, complain to your > Trust Store(s). We can do the rest, can we not? > > Yes, I think we're talking about two separate problems. I was looking at this from Mozilla's perspective. > > > I'm mostly not concerned about the people following these things > > closely and are members of this list, but about random other people who > > happen to find problems. It surely seems beneficial for the certificate > > ecosystem to make sure that they can easily find the right place to > > report problems. It can be confusing even for people following these things. That's where I think collecting problem reporting info from audited sub-CAs in CCADB would help. For everyone else, finding the correct problem reporting information is mostly a matter of luck. Perhaps we should require an email address be included in the end-entity certificate? Unless that info was exposed in the browser, it would still be difficult to find, but at least it would then be in a consistent location. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
On Sat, 9 Dec 2017 09:51:59 +0100 Hanno Böck via dev-security-policy wrote: > On Fri, 8 Dec 2017 16:43:48 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > The root CA is ultimately responsible for subordinate CAs it has > > signed. > > I see a problem with that, as this is far from obvious. I saw "responsibility" here as meaning responsibility to the Trust Stores on behalf of the Relying Parties. For the Relying Parties themselves I think the right pattern is: Try filing a Problem Report with the Issuer, if the result isn't satisfactory, complain to your Trust Store(s). We can do the rest, can we not? The Trust Stores have just as much reason to distrust a root CA which can't keep its subCAs from breaking the rules as they do if this root CA were to break the rules directly themselves. That's sort-of the lesson from Symantec too, right albeit in their case the problem was RAs? It should be in the Root CA's interest to make sure that every sub-ordinate CA, whether physically under its control or not, is properly operated, and if there's a suspicion that it's not being properly operated, to get that sorted out. Handling problem reports is part of the proper operation of the CA. It may be that root CAs decide the best way to _achieve_ this objective [for a subCA they don't actually intend as simply a cross-signature to bootstrap another root] is to insist upon being the point of contact for Problem Reports, and they'll pass them on, so this way they have oversight. Or that they insist on the Problem Reports going to an alias, Exchange DL or similar that sends a copy to the root CA, I don't think we need to dictate how this is done, only to re-emphasise that as the root CA making sure the Problem Reports are handled properly is ultimately your responsibility, however you discharge it, not a situation for buck passing. We definitely mustn't be shy about problems affecting another business with a Trust Store. If Microsoft's executive management has any sense there is an institutional firewall between their Trust Store and their Certificate Authority functions, and the former is able to make decisions independent of their potential impact on the latter. If a root CA finds that it is politically uncomfortable to have two very different relationships (Programme Member: Trust Programme / CA: subCA) to the same public company, well, that's unfortunate, and I would suggest the less awkward way forward is to bring the subCA relationship to an ordered close. Perhaps Microsoft shouldn't be in both games (and if so, the same for Google), but that again is not a problem for Mozilla. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
On Fri, 8 Dec 2017 16:43:48 -0700 Wayne Thayer via dev-security-policy wrote: > The root CA is ultimately responsible for subordinate CAs it has > signed. I see a problem with that, as this is far from obvious. If a random person discovers a problem with a certificate it seems quite natural to go to the place that issued it. If you see a certificate issued by Microsoft then why would you believe that anyone other than Microsoft is responsible for that? (Add to that that in order to find out that it's ultimately Digicert that is responsible you'd have to first figure out that the root is "Baltimore Cybertrust", then figure out that this is a company that no longer exists and that the root has been bought by Digicert at some point.) IMHO we're seeing a very problematic practice here. On the one Hand CAs offer that companies can get their own "branded" certificates that are "issued" by them, on the other hand that's not really the case and all the responsibility is still with the CA. For the user - and also for potential reporters of security problems - this is obfuscating things. I'm mostly not concerned about the people following these things closely and are members of this list, but about random other people who happen to find problems. It surely seems beneficial for the certificate ecosystem to make sure that they can easily find the right place to report problems. -- 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
Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
On Fri, Dec 08, 2017 at 11:55:46PM +0100, Hanno Böck via dev-security-policy wrote: > So I wonder: If a CA signs an intermediate - are they responsible > making sure that reports brought to the subca are properly handled? My first reaction would be if you sign it, you take responsibility. That would be either handling it yourself, or making sure that it's handled properly by the intermediate. But it's not obvious to me who to contact to revoke a given certifiate, and it would be really useful that given a certificate it would be obvious what to do, who to contact, to get it revoked. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
On Fri, Dec 8, 2017 at 3:55 PM, Hanno Böck via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > So I wonder: If a CA signs an intermediate - are they responsible > making sure that reports brought to the subca are properly handled? > > The root CA is ultimately responsible for subordinate CAs it has signed. That's why I asked DigiCert for an incident report via https://bugzilla.mozilla.org/show_bug.cgi?id=1424305 Having said that, I do think there are a few opportunities for improvement here. DigiCert couldn't directly revoke the compromised certificates, so I think it makes sense to add problem reporting mechanisms for subordinate CAs to CCADB when they differ from the root. That would also help when the problem reporting mechanism is buried in the CPS or when a general email address is published but there is no indication that it is the one the CA monitors 24x7 for certificate problem reports (both issues apply here). Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
Hi, I guess this is of interest to the members of this list: https://www.golem.de/news/microsoft-dynamics-365-wildcard-certificate-with-a-private-key-for-everyone-1712-131544.html https://medium.com/matthias-gliwka/microsoft-leaks-tls-private-key-for-cloud-erp-product-10b56f7d648 tl;dr Microsoft used a shared wildcard certificate in a cloud ERP product (Dynamics 365 for Operations). In the "sandbox" version customers were allowed to log in via RDP and thus it was possible to extract the private key. The finder of this bug tried several months unsuccessfully to inform Microsoft about this issue. Eventually he got in contact with me, I reported it to Mozilla's bugzilla and it was sorted out. https://bugzilla.mozilla.org/show_bug.cgi?id=1421820 The certificate was issued indirectly by DigiCert. This raises imho again an interesting issue about Sub-CAs. The BRs say that after a private key compromise a cert shall be revoked within 24 hours. This clearly didn't happen. While it is probably no big deal if it takes sometimes a bit longer, in this case it was several months. So I wonder: If a CA signs an intermediate - are they responsible making sure that reports brought to the subca are properly handled? -- 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