[Cryptography] Blue Coat has been issued a MITM encryption certificate

[Ray Dillinger]

  (attributions unclear so I left them out).

>> As in, what is the effect on systems out there in the wild as opposed
>> to  what does the spec say. Is there a difference and if so for what
>> systems?


> A CA certificate containing a BasicConstraints with
> pathLenConstraint=0 means that this CA certificate can only be used
> to verify an end-entity certificate, or a CA certificate that doesn't
> issue any certificate, but not a CA certificate that itself would
> issue another certificate (either CA or end-entity).
> 

Symantec keeping the Blue Coat private keys is an interesting
twist for a certificate at that level.  In theory that should
prevent them from issuing a cert for a different domain.  In
practice it depends on what kind of cert they were issued.
If the crypto is weak enough they could crack the private
key themselves and I don't know how much software still accepts
that weak-ass crypto. More likely, given their business
model, they'll have bribed somebody who got them the key
"off the record," so they can now issue keys that software
will recognize as being from Symantec, and Symantec, who
didn't "officially" provide the key, isn't liable for what
they do with it. Nice arrangement.

Alert, I'm making standard "must be an excessively
suspicious paranoid to do security" assumptions here; it may
not be this bad. But actually, I think it's worse than that.
I think this is probably the system operating as designed.

The CA cert system used by x.509 was proposed in response
to the need for an "introduction" system for customers and
merchants with no prior relationship.  But what emerged from
committee is self-evidently not designed to do exactly that
job.

If it were designed to do that job then CAs would be used
when doing introductions (or establishing new keys on a
new device) and key management would be done by both the
parties to the contact after that, with certificate
pinning on both sides.

I don't doubt that this protocol was debated by people
the majority of whom acted in good faith. But I have long
assumed that the debate was unduly influenced by, and the
swing votes cast by, actors who didn't have that job as
their primary concern.  Among these actors were CAs who
intended to profit from increased dependency of everyone
on their services, but I don't think they were the only
ones.

I have, for a long time, considered the CA system to be,
first and foremost, a tool for concentrating the ability
to perform MITM attacks to a set of known and controllable
CA's, and thereby make certain that MITM attacks are
available to government actors while protecting ordinary
customers from all but the most influential crooks.

Unfortunately the set of CA's rapidly became uncontrolled,
with the effect that many CA's are now frankly run by crooks
and the ability to perform MITM attacks is available on
the black market for crooks with no political influence
and only a little money.

We've been patching X.509 for its many holes and failures
for a long time, most recently with (FINALLY) certificate
pinning - the beginnings of key management by the parties
to the contact.  Still conspicuously missing are persistent
customer keys/self-certs that the businesses can "pin"
and associate with particular accounts on their side.

Maybe if we keep patching we'll eventually get to something
that does the job that X.509 was supposed to do.  But we
could have started with something a hell of a lot closer
to fulfilling the requirements.

			Bear



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160531/affd3eb6/attachment.sig>