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

Adam Back adam at cypherspace.org
Thu Dec 1 18:11:15 EST 2011


It does at least say they need a certificate practice statement, and
hardware key generation and storage, AND "All domains must be owned by the
enterprise customer".  They can sell the ability to be a sub-CA if they want
to.  There standards seem probably as good as your average CA and precludes
MitM applications.

GeoRoot would seem to preclude what Greg thinks he saw Boingo do.

Surely the SSL Observatory has these MitM sub CA certs if they exist in the
wild and are being used to create real time MitM certs for domains the
issuer certainly doesnt own.

I'd like to know which CAs if any are issuing these sub CA certs (so I can
remove them).  It would be intereseting to see what label they put on the
certs also.


btw if client certs are being used or TLS-SRP ciphersuite these attacks
would not work because SSL negotiation would fail.  Unless the MitM could
create fake client certs on the fly also that would be acceptable to the
server.

Adam

On Thu, Dec 01, 2011 at 05:59:23PM +0000, Ben Laurie wrote:
>http://www.trustico.com/material/DS_GeoRoot_0205.pdf
>
>Well, we'll only break the dishonest ones :-)
>
>On Thu, Dec 1, 2011 at 5:48 PM, Marsh Ray <marsh at extendedsubset.com> wrote:
>> On 12/01/2011 11:09 AM, Ben Laurie wrote:
>>>
>>> On Thu, Dec 1, 2011 at 4:56 PM, Marsh Ray<marsh at extendedsubset.com>
>>> wrote:
>>>>>
>>>>>
>>>>> http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html
>>>
>>>
>>> They appear to actually be selling sub-RA functionality, but very
>>> hard to tell from the press release.
>>>
>>> Bottom line: I'm going to believe this one someone displays a cert
>>> chain.
>>
>>
>>
>> Translated:
>>
>>> GeoRoot is only available for internal use, and organizations must
>>> meet certain eligibility requirements, [...]  compliance guidelines,
>>> and hardware security specifications.
>>
>>      ^^^^^^^^
>>
>>
>>> Organizations must maintain a list Certificate Revocation List (CRL)
>>
>>  ^^^^^^^^^^
>>
>>
>>> for all certificates issued by the company.
>>
>>                       ^^^^^^^^^^^^^^^^^^^^
>>
>>
>> But don't worry,  Mozilla has a "checklist" for sub-CAs!
>>
>> https://wiki.mozilla.org/CA:SubordinateCA_checklist
>>
>>> Home » CA:SubordinateCA_checklist
>>
>>
>>> Terminology
>>>
>>> The following terminology will be used in this wiki page regarding
>>> subordinate CAs.
>>>
>>> Third-Party: The subordinate CA is operated by a third party external
>>> to the root CA organization; and/or an external third party may
>>> directly cause the issuance of a certificate within the CA
>>> hierarchy.
>>
>>
>>> Third-party private (or enterprise) subordinate CAs: This is the case
>>> where a commercial CA has enterprise customers who want to operate
>>> their own CAs for internal purposes, e.g., to issue SSL server
>>> certificates to systems running intranet applications, to issue
>>> individual SSL client certificates for employees or contractors for
>>> use in authenticating to such applications, and so on.
>>>
>>> * These sub-CAs are not functioning as public CAs, so typical Mozilla
>>> users would not encounter certificates issued by these sub-CAs in
>>
>>
>> s/would/should/
>>
>>> their normal activities.
>>> * For these sub-CAs we need assurance that
>>> they are not going to start functioning as public CAs.
>>
>>
>> As Dan would say, security comes from this "absence of the potential" for
>> this type of surprise.
>>
>> This is not security, this reliance.
>>
>>> Currently the
>>> only assurances available for this case it to ensure that these third
>>> parties are required to follow practices that satisfy the Mozilla CA
>>> Certificate Policy, and that these third parties are under an
>>> acceptable audit regime.
>>
>>
>> Promises, promises.
>>
>>> o In Bug #394919 NSS is being updated to
>>> apply dNSName constraints to the CN, in addition to the SANs.
>>> o We
>>> plan to update our policy to require CAs to constrain third-party
>>> private (or enterprise) subordinate CAs so they can only issue
>>> certificates within a specified domain. See section 4.2.1.10 of RFC
>>> 5280.
>>
>>
>> Someday.
>>
>> To be fair to Mozilla, at least they're the ones with an open policy about
>> it. I didn't find such a policy for the other popular web clients (I may not
>> have looked hard enough).
>>
>> - Marsh



More information about the cryptography mailing list