[cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

Lee ler762 at gmail.com
Wed Nov 30 20:18:22 EST 2011


On 11/30/11, Rose, Greg <ggr at qualcomm.com> wrote:
>
> 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.

How did you know there was a MITM if it gave out a valid cert?

Thanks,
Lee


>
> Greg.
>
>>
>> I saw Ondrej Mikle also mentions this concept in his referenced link from
>> recent post:
>>
>> https://mail1.eff.org/pipermail/observatory/2011-November/000484.html
>>
>>> - 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?
>>
>> Adam
>>
>> 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
>>>>> mean).
>>>>
>>>> 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
>>>> system.
>>>
>>> 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
>>> http://lists.randombit.net/mailman/listinfo/cryptography
>> _______________________________________________
>> cryptography mailing list
>> cryptography at randombit.net
>> http://lists.randombit.net/mailman/listinfo/cryptography
>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>



More information about the cryptography mailing list