[cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
ondrej.mikle at nic.cz
Mon Dec 5 04:28:09 EST 2011
On 12/05/2011 04:21 AM, Lucky Green wrote:
> On 2011-12-04 12:09, Ondrej Mikle wrote:
>> I re-did the count of CAs whose CRLs had 'CA Compromise' as revocation reason,
>> about month after Peter Eckersley did. Result was the same (counting "trusted"
>> CAs). Plus few others (some seemed to be internal company CAs; but did not chain
>> to a "trusted root").
> Most (but not all) of the CAs that I worked with over the years did not
> have anybody on the operations side full time that would know how to
> place a revocation reason into the CRL. Which is why the majority of CRL
> entries include an unspecified reason code or the ever popular reason
> code "NULL".
Matches my observations, especially when looking at CRLs of some small
CAs (company internal). I had a hunch some of those revocations could be
due to CA compromise, but from my point of view it is be only a
speculation. I appreciate sharing your experience working with CAs, it
gives me a bit more understanding in my guesswork how they operate
> Without taking anything away from the work of the folks at the EFF (I
> appreciate their effort and have been a long-time financial supporter of
> the EFF), determining the number of CA compromises from looking at "CA
> Compromise" in reason codes is like determining car theft statistics
> from the number of car thieves that turn themselves in at the police
Of course, those marked 'CA compromise' are just the detected and
admitted cases (a lower bound). However should I claim any other
revocations were due to CA compromise I'd have to back that claim with
> It does not require disclosing of any confidential information to come
> to the conclusion that more certificates have been revoked due to CA
> compromise than certs were issued due to CA compromise. Indeed, you only
> need to look through the database for certs that very publicly have been
> revoked due to CA compromise to find a some that lack that reason code
> in the CRL.
Can you elaborate on the part of "coming to the conclusion that
revocation was due to CA compromise"? In the first sentence, should the
last part say "...than certs were revoked citing CA compromise as the
reason"? (I'm having trouble parsing it)
My first idea would be to look for a batch of certs revoked in a short
time period when looking for CA compromise.
The hunch I wrote above is based on my short period (about 7 years ago)
working part-time for a company that did a lot of IT projects for
government institutions. One of the projects was a pilot application for
eGovernment (which included PKI and CA-ish stuff). Before that project I
was tasked with penetration testing for said company, so I had pretty
good idea how a hacker could obtain access. There was lot of bad blood
between management and developers, experienced people left,
inexperienced developers were responsible for gaping security holes. The
company's use of bribes to secure government contracts was an open
secret (company has gone bankrupt since then).
Did some of the CAs you worked for exhibit similar atmosphere like the
company above? I'm asking because in such environment people simply
wouldn't be motivated enough to really care about breaches and competent
people wouldn't stay there for long.
Also, a friend once mentioned he had direct access to RA/CA interface at
a telco operator issuing certs that chained to Verisign for some project
(him being project manager from another company). That gave me
impression that such interfaces are probably more common than an
"uninitiated outsider" might think. Is that guess correct?
> Lastly, I am not trying to insinuate that having your CA compromised is
> or should ever become a crime.
I agree here. Also CA claiming to have no compromise just might be the
case of not being able to detect one or be lying (which is way worse).
That's why I did not name CAs from the CRLs (wouldn't be a good
motivation to keep them honest about revocation reasons).
More information about the cryptography