Should we block Blue Coat's 'test' intermediate CA?

[awill...@mozilla.com]

http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ reports that Symantec made Blue Coat (who produce MITM-capable security kit) an intermediate CA last year. They claim its only been used for 'internal testing'. Should we take action or trust them?

[Eric Mill]

Symantec has also stated that Blue Coat never had possession of the private
key:
http://www.symantec.com/connect/blogs/symantec-protocol-keeps-private-keys-its-control

And, on an existing Mozilla bug about the issue, Rick Andrews from Symantec
stated that it would have been limited to bluecoat.com:
https://bugzilla.mozilla.org/show_bug.cgi?id=1276146

Mozilla's Salesforce disclosures include the Blue Coat intermediate, which
is listed as under Symantec's CP and CPS:
https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCerts

If the only point of the intermediate was literally for bluecoat.com,
perhaps the certificate could have used a name constraint, though I
personally suspect Rick's comment was too narrow and that it could have
been used to request (from Symantec) other domains legitimately owned by
Blue Coat.

Unless there is evidence that this intermediate is non-compliant or
unusually risky in some way, for reasons other than the name "Blue Coat" on
it, I don't see any reason for Mozilla to distrust this intermediate.

-- Eric

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

[Nick Lamb]

On Tuesday, 31 May 2016 16:19:24 UTC+1, Eric Mill wrote:
> Mozilla's Salesforce disclosures include the Blue Coat intermediate, which
> is listed as under Symantec's CP and CPS:
> https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCerts

So far as I've seen there's every reason to believe this only became news at all because Symantec finally disclosed the existence of this certificate earlier in May, and so it was added to the CT logs. Without the carrot + stick approach which has been taken for disclosure of intermediates, this CA cert would still exist (it was created nine months or so ago) but it wouldn't be known, so it wouldn't be news.

If the message sent is "once you disclose an intermediate you'll get beaten up for that" there's a powerful disincentive to disclose at all. There's plenty of hysteria about this cert based on who it was issued to, which is funny because the best example of real trust ecosystem risk we have recently is from the Disney subCA [quietly revoked by its issuer when it ceased obeying the BRs...], yet I saw precisely zero people freaked out that Disney had an unconstrained intermediate when that information was first public.

That said, so far as I understand the Mozilla requirement is actually that such intermediates be disclosed _and audited_. The present disclosure from Symantec asserts that this intermediate is covered by the same audit as for all their other intermediates, but the certificate was actually issued _long after_ the period that audit covers, so this assertion by Symantec is nonsense. We need to get CAs to be honest with us. If the situation is that you've got no audit coverage for an intermediate, you need to _fix_ that, not just pretend it's covered by an audit report that doesn't even mention the intermediate and was written months before it existed.

[Peter Bowen]

On Tue, May 31, 2016 at 9:59 AM, Nick Lamb <tiala...@gmail.com> wrote:
> That said, so far as I understand the Mozilla requirement is actually that such intermediates be disclosed _and audited_. The present disclosure from Symantec asserts that this intermediate is covered by the same audit as for all their other intermediates, but the certificate was actually issued _long after_ the period that audit covers, so this assertion by Symantec is nonsense. We need to get CAs to be honest with us. If the situation is that you've got no audit coverage for an intermediate, you need to _fix_ that, not just pretend it's covered by an audit report that doesn't even mention the intermediate and was written months before it existed.

Nick,

I don't think that is an accurate assertion. My understanding is that
there are generally yearly audits that cover all the CAs operated by a
given entity. The audit includes controls around issuance and
operation of subordinate CAs. If the entity is using the same
controls for all their CAs then issuing a new subordinate doesn't
change anything. It will be reported upon in their next audit
statement.

This has come up before and I'm still not clear what alternatives
exist. WebTrust requires that the minimum reporting period is 60 days
and it generally takes a while for the auditor to do the field work
and write the report (say 90 days). So, even if there was a
requirement to have a unique audit for a new subordinate, you would be
looking at 4-5 months of operation before there is a report.

How would you prefer to see new CA-operated subordinates handled?

Thanks,
Peter

[Phillip Hallam-Baker]

Intermediates are not independent CAs. That is a myth that EFF has
unfortunately chosen to publicize for their own political ends.

The point of having an intermediate is that it makes it possible to use the
path chain as part of the authorization mechanism. So for example, let us
say that you have chains:

AliceCA -> BobCorpCA -> smtp.BobCorp.com #1
AliceCA -> BobCorpCA -> smtp.BobCorp.com #2
AliceCA -> BobCorpCA -> imap.BobCorp.com #3

An SMTP client could in theory be configured to require the TLS connection
to the mail servers to chain through BobCorpCA.

That is the theory at least. And I have sold a lot of PKI on that theory.
After I stopped selling them customers came and pointed out to me that it
is much less use than you would hope because the intermediate is typically
a short lived cert that you have to roll at least as often as the CA cert.

What you really want to be able to do in the mail client is to tie to a
root of trust you control as an enterprise. This is one of the things I am
trying to support in the Mathematical Mesh where we use fingerprints of
keys as roots of trust.

On Tue, May 31, 2016 at 12:59 PM, Nick Lamb <tiala...@gmail.com> wrote:

> On Tuesday, 31 May 2016 16:19:24 UTC+1, Eric Mill wrote:

> > Mozilla's Salesforce disclosures include the Blue Coat intermediate,
> which
> > is listed as under Symantec's CP and CPS:
> > https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCerts
>

> So far as I've seen there's every reason to believe this only became news
> at all because Symantec finally disclosed the existence of this certificate
> earlier in May, and so it was added to the CT logs. Without the carrot +
> stick approach which has been taken for disclosure of intermediates, this
> CA cert would still exist (it was created nine months or so ago) but it
> wouldn't be known, so it wouldn't be news.
>
> If the message sent is "once you disclose an intermediate you'll get
> beaten up for that" there's a powerful disincentive to disclose at all.
> There's plenty of hysteria about this cert based on who it was issued to,
> which is funny because the best example of real trust ecosystem risk we
> have recently is from the Disney subCA [quietly revoked by its issuer when
> it ceased obeying the BRs...], yet I saw precisely zero people freaked out
> that Disney had an unconstrained intermediate when that information was
> first public.
>

> That said, so far as I understand the Mozilla requirement is actually that
> such intermediates be disclosed _and audited_. The present disclosure from
> Symantec asserts that this intermediate is covered by the same audit as for
> all their other intermediates, but the certificate was actually issued
> _long after_ the period that audit covers, so this assertion by Symantec is
> nonsense. We need to get CAs to be honest with us. If the situation is that
> you've got no audit coverage for an intermediate, you need to _fix_ that,
> not just pretend it's covered by an audit report that doesn't even mention
> the intermediate and was written months before it existed.

[Peter Gutmann]

Nick Lamb <tiala...@gmail.com> writes:

>There's plenty of hysteria about this cert based on who it was issued to,
>which is funny because the best example of real trust ecosystem risk we have
>recently is from the Disney subCA [quietly revoked by its issuer when it
>ceased obeying the BRs...], yet I saw precisely zero people freaked out that
>Disney had an unconstrained intermediate when that information was first
>public.

Was it made public? All I've been able to find are two Bugzilla entries for
the revocation:

https://bugzilla.mozilla.org/show_bug.cgi?id=1262993
https://bugzilla.mozilla.org/show_bug.cgi?id=1263127

which seems to have been done because they were using SHA-1. Was there any
more to it than that?

Peter (resisting the temptation to make a comment about Mickey-Mouse security).

[Nick Lamb]

On Wednesday, 1 June 2016 04:35:44 UTC+1, Peter Gutmann wrote:
> Was it made public? All I've been able to find are two Bugzilla entries for
> the revocation:

I deliberately wrote that it was "first public" without attributing that to any entity. The Disney intermediate was added to the CT logs in August 2015. Most likely because a Google crawler ran into a public certificate it had issued while pootling around the undergrowth of the web. But it's not inconceivable that Entrust (the root CA) or Disney decided to publish it, I don't think the logs permanently record who added a record, nor should they.

The CT logs are public both by intention and in fact, and although I'm grateful for the existence of crt.sh, doubtless other monitors would exist if it didn't. While the primary stated purpose for the monitors is to let name owners watch out for certificates that shouldn't have been issued (and Facebook already reports this worked out as intended for them) there's no doubt that having ordinary citizens, and among them a Free Press poking around in the monitors is desirable too. Transparency is worth nothing if nobody is looking.

> Peter (resisting the temptation to make a comment about Mickey-Mouse security).

As is usual for these subCAs, the "Mickey Mouse" element tends not to be about the security per se, but poor quality of issuance which imposes risks to the ecosystem. Even before it was revoked, Disney's CA managed to issue for:

wm-flor-ap689wdwdisneycom

After a couple more attempts, the operators managed to spit themselves out a certificate for the name they'd actually wanted, wm-flor-ap689wdw.disney.com at last. But what sort of clumsy "oversight" permitted this to happen in the first place?

I'm guessing Entrust would tell us they revoked wm-flor-ap689wdwdisneycom, or that anyway it was issued prior to the BRs strictly forbidding such nonsense so it wasn't "technically" a miss. But it's still hard to stomach, isn't it?

[doliv...@gmail.com]

Here is Bluecoat showing off their MITM appliance.

https://www.bluecoat.com/security-blog/2014-01-02/exploring-encrypted-skype-conversations-clear-text

[Paul Wouters]

On Tue, 31 May 2016, doliv...@gmail.com wrote:

> Here is Bluecoat showing off their MITM appliance.
>
> https://www.bluecoat.com/security-blog/2014-01-02/exploring-encrypted-skype-conversations-clear-text

Note that it only shows a MITM TLS when you install their CA. Which,
whether we like it or not, is a valid business model. For instance
it is needed for various financial compliance laws.

And decrypting the TLS only gave the guy encrypted data he still could
not read. My guess is skype just uses TLS and a way to break through
middleware, and whatever their encryption scheme is, is still inside
of that.

Paul

[Chris Palmer]

On Tue, May 31, 2016 at 10:33 AM, Phillip Hallam-Baker <
ph...@hallambaker.com> wrote:

Intermediates are not independent CAs. That is a myth that EFF has
> unfortunately chosen to publicize for their own political ends.
>

They don't stand to gain anything by pointing out that unconstrained issuer
certs are unconstrained.

> The point of having an intermediate is that it makes it possible to use the
> path chain as part of the authorization mechanism. So for example, let us
> say that you have chains:
>
> AliceCA -> BobCorpCA -> smtp.BobCorp.com #1
> AliceCA -> BobCorpCA -> smtp.BobCorp.com #2
> AliceCA -> BobCorpCA -> imap.BobCorp.com #3
>
> An SMTP client could in theory be configured to require the TLS connection
> to the mail servers to chain through BobCorpCA.
>

You are talking as if BobCorpCA were name-constrained. Which would be nice
indeed. But not the case with the BlueCoat certificate.

The constraints that matter are those that the relying party/UA applies at
run-time.

[Phillip Hallam-Baker]

On Fri, Jun 10, 2016 at 4:59 PM, Chris Palmer <pal...@google.com> wrote:

> On Tue, May 31, 2016 at 10:33 AM, Phillip Hallam-Baker <
> ph...@hallambaker.com> wrote:
>
> Intermediates are not independent CAs. That is a myth that EFF has
>> unfortunately chosen to publicize for their own political ends.
>>
>
> They don't stand to gain anything by pointing out that unconstrained
> issuer certs are unconstrained.
>

At the time name constraints were unusable because the NSA BULLRUN troll in
IETF had managed to get PKIX written so that name constraints MUST be
marked critical. Since that would have had a severe impact on a large
number of Apple devices that didn't understand name constraints at the
time, that was unacceptable.

We eventually fixed the problem by declaring the PKIX requirement to be
inapplicable.

> The point of having an intermediate is that it makes it possible to use the
>> path chain as part of the authorization mechanism. So for example, let us
>> say that you have chains:
>>
>> AliceCA -> BobCorpCA -> smtp.BobCorp.com #1
>> AliceCA -> BobCorpCA -> smtp.BobCorp.com #2
>> AliceCA -> BobCorpCA -> imap.BobCorp.com #3
>>
>> An SMTP client could in theory be configured to require the TLS connection
>> to the mail servers to chain through BobCorpCA.
>>
>
> You are talking as if BobCorpCA were name-constrained. Which would be nice
> indeed. But not the case with the BlueCoat certificate.
>
> The constraints that matter are those that the relying party/UA applies at
> run-time.
>

If the customer doesn't have control of the signing key, the use of name
constraints isn't very important. It is a failsafe more than anything.

What it does provide is a check against a reputation attack though.

[Eric Mill]

Can someone from Symantec clarify how their previous statements on Blue
Coat's lack of ownership of this intermediate's private key will continue
to apply following their acquisition of Blue Coat?

http://www.wsj.com/articles/symantec-set-to-buy-blue-coat-systems-in-4-65-billion-deal-1465774721

-- Eric

On Tue, May 31, 2016 at 11:18 AM, Eric Mill <er...@konklone.com> wrote:

> Symantec has also stated that Blue Coat never had possession of the
> private key:
>
> http://www.symantec.com/connect/blogs/symantec-protocol-keeps-private-keys-its-control
>
> And, on an existing Mozilla bug about the issue, Rick Andrews from
> Symantec stated that it would have been limited to bluecoat.com:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1276146
>

> Mozilla's Salesforce disclosures include the Blue Coat intermediate, which
> is listed as under Symantec's CP and CPS:
> https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCerts
>

> If the only point of the intermediate was literally for bluecoat.com,
> perhaps the certificate could have used a name constraint, though I
> personally suspect Rick's comment was too narrow and that it could have
> been used to request (from Symantec) other domains legitimately owned by
> Blue Coat.
>
> Unless there is evidence that this intermediate is non-compliant or
> unusually risky in some way, for reasons other than the name "Blue Coat" on
> it, I don't see any reason for Mozilla to distrust this intermediate.
>
> -- Eric
>
> On Tue, May 31, 2016 at 9:56 AM, <awill...@mozilla.com> wrote:
>
>> http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ reports that
>> Symantec made Blue Coat (who produce MITM-capable security kit) an
>> intermediate CA last year. They claim its only been used for 'internal
>> testing'. Should we take action or trust them?

>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
>

[Mat Caughron]

Adding fuel to the fire that Symantec's handling of the BlueCoat
certificate warrants client-side blocking, see Milton Smith's blog post
here:
http://www.securitycurmudgeon.com/2016/06/blue-coat-intermediate-ca-certificate.html



Mat C.

[Paul Wouters]

While not stating an opinion on the question asked, let me note that having an empty crl could be fine if all their test certificates expire within the hour.



Sent from my iPhone

> On Jun 14, 2016, at 21:02, Mat Caughron <caug...@gmail.com> wrote:
>
>
> Adding fuel to the fire that Symantec's handling of the BlueCoat
> certificate warrants client-side blocking, see Milton Smith's blog post
> here:
> http://www.securitycurmudgeon.com/2016/06/blue-coat-intermediate-ca-certificate.html
>
>
>
> Mat C.
>
>
>> On Tuesday, May 31, 2016 at 6:56:11 AM UTC-7, awill...@mozilla.com wrote:

>> http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ reports that Symantec made Blue Coat (who produce MITM-capable security kit) an intermediate CA last year. They claim its only been used for 'internal testing'. Should we take action or trust them?

[sanja...@symantec.com]

The integrity of Symantec’s public certification authority will not be
impacted as a result of the Blue Coat acquisition. Until the acquisition
is complete, Symantec and Blue Coat will continue to operate as two
separate companies. Once the transaction is complete, Symantec’s public CA
infrastructure and capabilities will continue to remain separate and
independent from Blue Coat’s technology and products. In addition,
policies and governance will be established to ensure the public CA
operations will not be used to facilitate packet inspection in the Blue
Coat offerings that will become a part of Symantec’s portfolio.

[Man Ho (Certizen)]

I think the issue or concern on Blue Coat's intermediate CA certificate
is irrelevant to "Symantec's policies and governance on its public CA
operation". The concern is on Blue Coat's intermediate CA operation.

If it's allowed to continue operation, this intermediate CA certificate
can generate any number of forge SSL certificates for any website. How
can these certificates be differentiated in CT logs? Some exception
treatment again?

Secondly, the risk of MITM to internet users will all depend on where
Blue Cost is deployed. If it is deployed in country-wide internet
gateway, all internet users of the country will be at risk.

I'd say "Wow, what a mess to the CA ecosystem!"

[Eric Mill]

On Wed, Jun 15, 2016 at 12:02 AM, <sanja...@symantec.com> wrote:

> The integrity of Symantec’s public certification authority will not be
> impacted as a result of the Blue Coat acquisition. Until the acquisition
> is complete, Symantec and Blue Coat will continue to operate as two
> separate companies. Once the transaction is complete, Symantec’s public CA
> infrastructure and capabilities will continue to remain separate and
> independent from Blue Coat’s technology and products.

Thanks for the response, Sanjay. This is a pretty general statement, and
doesn't definitively answer whether Blue Coat can be said to be "not in
possession of the private key". From what you're saying, it sounds like
they *will* enter into possession of the private key in at least a legal
sense. Depending on how you implement the business separation, BC could be
argued to be in possession of the private key in other senses too.

Symantec should update its official statement to reflect this, so that the
statement doesn't become inaccurate once the acquisition is complete.

> In addition,
> policies and governance will be established to ensure the public CA
> operations will not be used to facilitate packet inspection in the Blue
> Coat offerings that will become a part of Symantec’s portfolio.
>

I hate to pepper you with questions, but this raises several: Will this
mean technical controls that restrict issuance beyond what would otherwise
have been allowed? Will Symantec publish those policies publicly? Will
Symantec seek feedback from this community before finalizing them?

-- Eric

[Sanjay Modi]

We have posted more updates here<http://www.symantec.com/connect/blogs/symantec-s-ca-will-continue-control-keys>, specifically regarding Symantec’s acquisition of Blue Coat. To be clear, Symantec always maintained control of the private key with regards to Blue Coat’s intermediate CA, which you can find more details about here<http://www.symantec.com/connect/blogs/symantec-protocol-keeps-private-keys-its-control>. As I mentioned previously, policies and governance will be established as a part of the integration process, which will begin after the acquisition closes in Q3. At that time, Symantec will ensure that the infrastructure and capabilities will continue to remain separate and independent from Blue Coat’s technology and products. We will make appropriate public disclosures of such policies and governance once they are established.

- Sanjay

From: Eric Mill <er...@konklone.com<mailto:er...@konklone.com>>
Date: Wednesday, June 15, 2016 at 7:44 AM
To: Sanjay Modi <sanja...@symantec.com<mailto:sanja...@symantec.com>>
Cc: "mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>" <mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>>
Subject: Re: Should we block Blue Coat's 'test' intermediate CA?

On Wed, Jun 15, 2016 at 12:02 AM, <sanja...@symantec.com<mailto:sanja...@symantec.com>> wrote:
The integrity of Symantec’s public certification authority will not be
impacted as a result of the Blue Coat acquisition. Until the acquisition
is complete, Symantec and Blue Coat will continue to operate as two
separate companies. Once the transaction is complete, Symantec’s public CA
infrastructure and capabilities will continue to remain separate and
independent from Blue Coat’s technology and products.

Thanks for the response, Sanjay. This is a pretty general statement, and doesn't definitively answer whether Blue Coat can be said to be "not in possession of the private key". From what you're saying, it sounds like they *will* enter into possession of the private key in at least a legal sense. Depending on how you implement the business separation, BC could be argued to be in possession of the private key in other senses too.

Symantec should update its official statement to reflect this, so that the statement doesn't become inaccurate once the acquisition is complete.

In addition,
policies and governance will be established to ensure the public CA
operations will not be used to facilitate packet inspection in the Blue
Coat offerings that will become a part of Symantec’s portfolio.

I hate to pepper you with questions, but this raises several: Will this mean technical controls that restrict issuance beyond what would otherwise have been allowed? Will Symantec publish those policies publicly? Will Symantec seek feedback from this community before finalizing them?

-- Eric

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy



--
konklone.com<https://konklone.com> | @konklone<https://twitter.com/konklone>