[cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
ggr at qualcomm.com
Wed Nov 30 19:47:08 EST 2011
On 2011 Nov 30, at 16:44 , Adam Back wrote:
> 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.
Yes, there are. I encountered one in a hotel at Charles de Gaulle airport a few weeks ago.
> 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<marsh at extendedsubset.com> 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 at randombit.net
> cryptography mailing list
> cryptography at randombit.net
More information about the cryptography