Re: Certificate for com and it

2018-02-08 Thread Ryan Sleevi via dev-security-policy 
On Thu, Feb 8, 2018 at 3:14 PM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, 8 Feb 2018 15:50:08 +
> Gervase Markham via dev-security-policy
>  wrote:
>
> > In this case, the certificates are revoked in Firefox via OneCRL and
> > Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be
> > noticed.
>
> Hi Gerv,
>
> Independent of this specific case, which I guess is mostly harmless, I
> find this worrying.
>
> Let's assume something like this happens:
> * CA xyz, which is trusted by Mozilla and other root stores, issues a
>   sub-certificate for company SuperShady Inc. Immediately after that
>   CA xyz asks Mozilla to include it into OneCRL and Google to include
>   it in CRLsets.
> * SuperShady Inc. starts selling certificates. Their offer is that you
>   can get a certificate for every domain you want, the price depends on
>   how popular the domain is. If you pay enough you can get a
>   certificate that's valid for google.com or facebook.com.
> * SuperShady Inc. advertises their certificates with the fact that
>   while they won't be valid in mainstream browsers due to revocation
>   lists they still work in many situations, i.e. they will be
>   considered valid by commandline tools or API calls from many
>   programming languages as they don't include a mechanism like OneCRL.
>
> I'm aware that this goes into the tricky topic of people consuming the
> Mozilla CA root store without implementing the full certificate
> validation logic, which is already a problem with deprecated CAs like
> the old Symantec roots that are phased out.
> But this is much more sever. While we don't expect that the
> Symantec roots have been operated with the care we expect from a CA we
> also don't have any indication that they're used for outright malicious
> purposes.
>
> Yet I feel what you and others here are implying is that once a subca
> is part of OneCRL and revoked they're no longer bound to any standards
> at all.
>

How is this different from CA xyz asks for their root to be removed from
Mozilla products and other root stores, but applications and devices use
older versions?

The simple answer is that those commandline tools and API calls for
programming language are responsible for their application security. They
always have been. They don't get a free pass now. A root store is as much a
product decision as the choice of programming language to write it in.

The same argument you're making here is if CA xyz revokes SuperShady Inc's
certificate. The same commandline tools and APIs for programming languages
don't do revocation checking (often times because their design is such that
it's impossible for them to do so, because making network requests is the
caller's job or shouldn't be done in the batch processing)

We've had the discussion on m.d.s.p. in a variety of ways in the past
regarding consumption of the root stores and program decisions. There's
even a FAQ about it to cover this question which is periodically raised, as
it is now -
https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F

"""Therefore, anyone considering bundling Mozilla's root store with other
software needs to be aware of the issues surrounding providing a root
store, and committed to making sure that they maintain security for their
users by carefully observing Mozilla's actions and taking appropriate steps
of their own. On a best-efforts basis, Mozilla maintains a list of the
additional things users of our store might need to consider. """

OneCRL is a way that attempts to address impact and risk for Mozilla
Firefox users. It is not inherently going to be guaranteed to be
appropriate for other use cases - each application vendor needs to evaluate
their community of users, the expectations, the stability contracts, the
impacts, etc when it decides to handle revocation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate for com and it

2018-02-08 Thread Hanno Böck via dev-security-policy 
On Thu, 8 Feb 2018 15:50:08 +
Gervase Markham via dev-security-policy
 wrote:

> In this case, the certificates are revoked in Firefox via OneCRL and
> Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be
> noticed.

Hi Gerv,

Independent of this specific case, which I guess is mostly harmless, I
find this worrying.

Let's assume something like this happens:
* CA xyz, which is trusted by Mozilla and other root stores, issues a
  sub-certificate for company SuperShady Inc. Immediately after that
  CA xyz asks Mozilla to include it into OneCRL and Google to include
  it in CRLsets.
* SuperShady Inc. starts selling certificates. Their offer is that you
  can get a certificate for every domain you want, the price depends on
  how popular the domain is. If you pay enough you can get a
  certificate that's valid for google.com or facebook.com.
* SuperShady Inc. advertises their certificates with the fact that
  while they won't be valid in mainstream browsers due to revocation
  lists they still work in many situations, i.e. they will be
  considered valid by commandline tools or API calls from many
  programming languages as they don't include a mechanism like OneCRL.

I'm aware that this goes into the tricky topic of people consuming the
Mozilla CA root store without implementing the full certificate
validation logic, which is already a problem with deprecated CAs like
the old Symantec roots that are phased out.
But this is much more sever. While we don't expect that the
Symantec roots have been operated with the care we expect from a CA we
also don't have any indication that they're used for outright malicious
purposes.

Yet I feel what you and others here are implying is that once a subca
is part of OneCRL and revoked they're no longer bound to any standards
at all.

-- 
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 for com and it

2018-02-08 Thread Wayne Thayer via dev-security-policy 
On Thu, Feb 8, 2018 at 8:54 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote:
>
>> On 08/02/18 13:47, Hanno Böck wrote:
>>
>> OneCRL additions normally have an associated bug but I can't see one for
>> this...
>>
>
> https://crt.sh/mozilla-onecrl (which parses the OneCRL JSON feed)
> suggests https://bugzilla.mozilla.org/show_bug.cgi?id=1432467.
>
> This bug explains the recent addition of this subordinate CA to OneCRL:
https://bugzilla.mozilla.org/show_bug.cgi?id=1397969

Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate for com and it

2018-02-08 Thread Rob Stradling via dev-security-policy 

On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote:

On 08/02/18 13:47, Hanno Böck wrote:

Is a revoked intermediate cert a license for operating a yolo CA that
signs everything? Given the fragility of revocation checking I'd find
that a problematic precedent.


In this case, the certificates are revoked in Firefox via OneCRL and
Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be
noticed.


The OCSP seems operational and replies with "Good" and the issuance
happened before it's being added to OneCRL.


If the cert itself has not been revoked by its issuer, "Good" is an
entirely reasonably response...


I don't find a reference why this intermediate had been added to
OneCRL, but I think this deserves more clarification what's going on
here.


OneCRL additions normally have an associated bug but I can't see one for
this...


https://crt.sh/mozilla-onecrl (which parses the OneCRL JSON feed) 
suggests https://bugzilla.mozilla.org/show_bug.cgi?id=1432467.


--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate for com and it

2018-02-08 Thread Gervase Markham via dev-security-policy 
On 08/02/18 13:47, Hanno Böck wrote:
> Is a revoked intermediate cert a license for operating a yolo CA that
> signs everything? Given the fragility of revocation checking I'd find
> that a problematic precedent.

In this case, the certificates are revoked in Firefox via OneCRL and
Chrome via CRLSets (AIUI) and so the revocations are guaranteed to be
noticed.

> The OCSP seems operational and replies with "Good" and the issuance
> happened before it's being added to OneCRL.

If the cert itself has not been revoked by its issuer, "Good" is an
entirely reasonably response...

> I don't find a reference why this intermediate had been added to
> OneCRL, but I think this deserves more clarification what's going on
> here.

OneCRL additions normally have an associated bug but I can't see one for
this...

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate for com and it

2018-02-08 Thread Hanno Böck via dev-security-policy 
Hi,

On Tue, 6 Feb 2018 16:56:48 +0100
Kurt Roeckx via dev-security-policy
 wrote:
> I should probably more clear, the certificates of the CA have been
> revoked.

I'm wondering what that means.

Is a revoked intermediate cert a license for operating a yolo CA that
signs everything? Given the fragility of revocation checking I'd find
that a problematic precedent.

The OCSP seems operational and replies with "Good" and the issuance
happened before it's being added to OneCRL.
I don't find a reference why this intermediate had been added to
OneCRL, but I think this deserves more clarification what's going on
here.

-- 
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 for com and it

2018-02-06 Thread Kurt Roeckx via dev-security-policy 

On 6/02/2018 16:52, Kurt Roeckx wrote:

On 6/02/2018 12:20, Hanno Böck wrote:

Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is
a subca of Baltimore Cybertrust, which belongs to Digicert.


That certificate is revoked, not trusted by Mozilla or chrome.


I should probably more clear, the certificates of the CA have been revoked.


Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate for com and it

2018-02-06 Thread Kurt Roeckx via dev-security-policy 

On 6/02/2018 12:20, Hanno Böck wrote:

Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is
a subca of Baltimore Cybertrust, which belongs to Digicert.


That certificate is revoked, not trusted by Mozilla or chrome.


Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificate for com and it

2018-02-06 Thread Hanno Böck via dev-security-policy 
This certificate
https://crt.sh/?id=282908507
is issued for the names "com" and "it".

It also contains other suspicious hostnames:
sip.fideuram
sip.consule
sip.consultant.fideura

I don't think these TLDs exist.

Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is
a subca of Baltimore Cybertrust, which belongs to Digicert.

Source: https://twitter.com/OhDearApp/status/960520419831894016

-- 
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