[cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
adam at cypherspace.org
Fri Dec 2 03:33:44 EST 2011
Well I was aware of RA things where you do your own RA and on the CA side
they limit you to issuing certs belonging to you, if I recall thawte was
selling those. (They pre-vet your ownership of some domains foocorp.com,
foocorpinc.com etc, and then you can issue www.foocorp.com, *.foocorp.com ..
however you dont get a CA private key, you get web integration with the RA
so you dont have to do the email verification dance for each cert you
Handing over a signed sub-CA is a much higher level of risk, unless perhaps
it has a constraint on the domain names of certs it can sign baked into it,
which is possible.
To hand over a blank cheque sub-CA cert that could sign gmail.com is
somewhat dangerous. But you notice that geotrust require it to be in a
hardware token, and some audits blah blah, AND more importantly that you
agree not to create certs for domains you dont own.
Start of the thread was that Greg and maybe others claim they've seen a cert
in the wild doing MitM on domains the definitionally do NOT own.
(The windows 2k box sounds scary for sure, and you better hope that's not a
general unrestricted sub-CA cert, but even then you could admit its similar
to the security practices of diginotar.)
Secure as the weakest link, and the weakest link just keeps getting lower.
It would be interesting to know if there really are CAs lax enough to issue
a sub-CA cert to a windows box with no hardware container for the private
key. (Not that it makes that much difference... hack the RA and the private
key doesnt matter so much).
The real question again is can we catch a boingo or corp lan or government
using a MitM sub-CA cert, and then we'll know which CA is complicit in
issuing it, and delist them.
On Fri, Dec 02, 2011 at 07:07:19PM +1300, Peter Gutmann wrote:
>Ben Laurie <ben at links.org> writes:
>>They appear to actually be selling sub-RA functionality, but very hard to
>>tell from the press release.
>OK, so it does appear that people seem genuinely unaware of both the fact that
>this goes on, and the scale at which it happens. Here's how it works:
>1. Your company or organisation is concerned about the fact that when people
>go to their site (even if it's an internal, company-only one), they get scary
>2. Your IT people go to a commercial CA and say "we would like to buy the
>ability to issue padlocks ourselves rather than having to buy them all off
>3. The CA goes through an extensive consulting exercise (billed to the
>company), after which they sell the company a padlock-issuing license, also
>billed to the company. The company is expected to keep records for how many
>padlocks they issue, and pay the CA a further fee based on this.
>4. Security is done via the honour system, the CA assumes the company won't do
>anything bad with their padlock-issuing capability (or at least I've never
>seen any evidence of a CA doing any checking apart from for the fact that
>they're not getting short-changed).
>This is why in the past I've repeatedly referred to "unknown numbers of
>unknown private-label CAs", we have absolutely no idea how many of these
>private-label CAs are out there or who they are or who controls them, but
>they're probably in the tens, if not hundreds, of thousands, and many are
>little more than a Windows server on a corporate LAN somewhere (and I mean
>that literally, it was odd to sit in front of a Windows 2000 box built from
>spare parts located in what used to be some sort of supplies closet and think
>"I can issue certs that chain to $famous_ca_name from this thing" :-).
>Going through the process is like getting a BS 7799 FIPS 140 certification,
>you pay the company doing the work to get you through the process, and you
>keep paying them until eventually you pass. The only difference is that while
>I've heard of rare cases of companies failing BS 7799, I've never heard of
>anyone failing to get a padlock-issuing license.
>Are people really not aware of this? I thought it was common knowledge. If
>it isn't, I'll have to adapt a writeup I've done on it, which assumes that
>this is common knowledge.
>cryptography mailing list
>cryptography at randombit.net
More information about the cryptography