Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

[Ángel via dev-security-policy]

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

[Kristian Fiskerstrand via dev-security-policy]

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

[Tom via dev-security-policy]

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

[Wayne Thayer via dev-security-policy]

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

[Nick Lamb via dev-security-policy]

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

[Hanno Böck via dev-security-policy]

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

[Kurt Roeckx via dev-security-policy]

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

[Wayne Thayer via dev-security-policy]

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

[Hanno Böck via dev-security-policy]

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