Are there really any CAs which issue sub-CA for "deep packet inspection" aka
doing MitM and issue certs on the fly for everything going through them:
gmail, hotmail, online banking etc.

I saw Ondrej Mikle also mentions this concept in his referenced link from
recent post:

- SSL inspection/MitM boxes sometimes show up before being configured
(Blue Coat, SonicWall, Watchguard Fireware)

How do they know you're going to put the cert in a blue coat box and inflict
that only to your employees vs steal banking passwords and money of users in
an airport?

Do blue coat and other MitM proxies mentioned on this list recently actually
support on the fly cert generation and putting a CA cert in there?

I was presuming that to do so they user would have to self-sign a CA cert
and "upgrade" their browsers on their corporate installs by adding their
self-signed MitM cert to the trusted CA set in their standard image/install
set.  (Which is obnoxious but fair enough).

But for a CA to intentionally issue an unrestricted sub-CA cert for
installing in MitM boxes - that sounds outright lethal.  How much do you
trust the box security, the operators of the box.  Do they sell such sub-CAs
to Iran, Syria via shady intermediaries?

What do these sub-CA certs cost? What do I have to say or sign to get one? Will they sell it to me to monitor my kids? Employees of a small startup?


On Wed, Nov 30, 2011 at 01:30:40PM -0600, Marsh Ray wrote:
On 11/30/2011 12:01 PM, Ben Laurie wrote:
On Wed, Nov 30, 2011 at 5:16 PM, Marsh Ray<>  wrote:

Perhaps you define this category of "publicly visible certs" as "certs
which display without warnings on default-configured browsers when
presented by the correct site".
On the other hand, one could interpret this category of "publicly
visible certs" as "certs visible to the public", i.e., "certs served by
legitimate servers on routable IPs located via public DNS". But this
interpretation would be much weaker (and I don't think that's what you

Although I rather like your first definition, this one seems closer to
the truth: it may be that some sites which currently validate
correctly in default-configured browsers would choose not to in our

The certs I am worried about though are the certs that were issued in secret (e.g. Comodo and friends) and are never "publicly visible" until they are used in an attack.

If the attack is sufficiently targeted, it may be the case that no one other than the victim ever sees the cert at all. In the event of a mass MitM attack (e.g. *.ir), the attacker would likely have free use of his previously-hidden cert for at least as long as the combined reporting, reaction, and revocation latency.

It's not clear how this proposal is actually an improvement on the current system in this regard.

On the other hand, if you *did* engage the CAs and get their buy-in, they could pledge to update the log promptly with every cert they issued. Specific CA certs could be configured with this flag in the browser's trusted store. This would allow a missing audit proof to be treated as a hard stop and would seem to be a more meaningful distinction among CAs than the current EV scheme. (The few CAs I've spoken were really grasping for ways with which the 'better' CAs could distinguish themselves in the industry.)

Additionally, such a flag could be added to HSTS. Rather than pinning to a specific CA ("I will only use this one CA ever"), a site could pin itself to the use of a CA that promised to participate in the auditing. This would reduce some of the DoS potential inherent in CA pinning yet still allow browsers to catch that critical transition from "provably logged cert" to "non-logged cert".

But the proposal does nothing _directly_ to prevent a CA from issuing a
cert, right? And since browsers aren't logging the certs as they find
them, this doesn't inform the owner of the domain either.

Instead it seems to be a hoped-for effect of "default-configured
browsers will raise hell if they are presented with a non-logged cert
and CAs will feel compelled to go along with the audit logging".

CAs do not have to go along with anything, the log will accept a cert
from anyone - which obviously includes the owner of the cert.

There would need to be a way for end-users to report new certs via their browser, much like they report browser crashes today. Wouldn't some users want it? I think it would be good to involve the users in this process as much as is practical.

they'll have to put the certs they
issue in the logs too, right?

Someone will, yes.

Wouldn't they have to put the certs they sign in the public log? They
don't have to do this today.

No, but their certs are already publicly visible today.

I don't believe this is the case. It's one of the big problems with the system we have today.

Consider a sub-CA which is issed for the purpose of a company's deep-inspecting firewall (e.g., a BlueCoat). The device will use the sub-CA to issue new certs on-the-fly for each new website that the internal network clients browse to. The rest of the world (hopefully) never sees those certs.

Yet this log of the certs that it has generated is highly confidential. It contains info about the browsing history of the entire company, e.g., parts suppliers, financial institutions, use your imagination.

The current crop of "trusted" CAs refuse to give the names or even the count of the sub-CAs they've sold. They only require that the party to which they sell them agree in a contract to use them accordingly.

I'm all for saying that these sub-CAs need to be put on the boat to the island of lost toys like the toxic plastic that they are. But I wouldn't expect the parties that currently enjoy this privilege to go quietly. :-)

- Marsh
cryptography mailing list
cryptography mailing list

Reply via email to