Just to top-post on that - I did read up on a lot more references [0],
and I see that the claim is that the CA concerned issued the
intermediates by mistake. They caught one of them later on and fixed
it. The second they did not catch.
The holder of the second intermediate then installed it on a Checkpoint
device. An MITM was initiated, as evidenced by Chrome picking it up.
I'm not ready to believe that the Checkpoint software suddenly became
self-aware and started MITMing the users. Checkpoint ain't Skynet.
What seems more likely is that the holder of the intermediate had some
ideas and tried them out. And then tried to cover up.
But whatever. The short story I see so far is that the CA made a
mistake. Rectified it once, not twice. Got caught out. Boom.
iang
[0] So I could update my Risk History:
http://wiki.cacert.org/Risk/History#h2012.5
On 5/01/13 21:50 PM, Ryan Hurst wrote:
I have no more information than the rest of you but my read of what they
published is that this was not a 'legitimate MITM' case.
It sounds to me as if they are saying a customer installed a previously
purchased certificate on a firewall for a legitimate purpose -- possibly
administration or SSL termination. That this act resulted in the firewall
automatically configuring itself as a MITM gateway.
This automatic action took place because they had previously miss issued the
certificate and the firewall in question dynamically detected the certificates
'ability to be used for MITMs 'and took advantage of it.
I see five problems:
1. They miss issued a certificate.
2. They were not aware that they miss issued the certificate.
3. The Internet - more specifically the browser programs that police
certificate authorities behalf of users we're also unaware they miss issued
this certificate.
4. The only reason this was detected was because a user visited a browser
provider's website that company's browser.
5. The firewall has a feature that automatically enables MITM with out
requiring the Administrator to approve that action.
If we feel comfortable believing TurkTrust, in this specific case 1 and 2
appear to be addressed.
This leaves the question what mechanisms exist in the audits CAs are subject to
detect similar situations in the future.
These audits do mandate separation of test and production data which is
plausibly enough prevent such cases.
As such I assume this issue not being detected in the audit is a result of an
operational failure - which is what the CA seems the be claiming as well.
My position on that is : Mistakes happen, what's important is how you deal with
them. It seems in this case TurkTrust Has responded as appropriately as one
could in such a situation.
This brings us to items 3 and 4. It's my hope that the work Ben and others have
been doing on sunlight as well as the certificate observatory related projects
will empower browsers and technologists such as ourselves to address these
items as well .
As for 5, that's an item for Checkpoint and their users to consider.
Ryan Hurst
Sent from my phone, please forgive the brevity.
On Jan 5, 2013, at 7:14 AM, ianG <i...@iang.org> wrote:
HI all,
On 5/01/13 15:55 PM, Ralph Holz wrote:
On 01/05/2013 12:29 PM, Ben Laurie wrote:
Unless all the people who saw it happened to be running Chrome, then
it seems quite likely it was used maliciously, surely?
The problem is that there are many values that both "legitimately" and
"maliciously" can take. Turktrust's argument seems to be that it was
"legitimately" used for SSL interception on a firewall/proxy device.
Ah! The old "legitimate interception" argument :)
The SANs in the rogue certs that have been published seem to support
that. Whether SSL interception is good or bad is, unfortunately, open to
debate.
I thought that debate was closed - if any CA is issuing root certs for SSL
interception, that CA can expect to be dropped by the vendors. If that is not
happening, then the vendors have once again failed their users.
The users' expectation is clear - the product is purposed to stop MITMs. If it
does not, then the expectations are destroyed and we don't need the product.
Which is it? (I'm not asking you, being rhetorical here.)
That said - does Google currently hold more rogue certs than the ones
published? Chrome has some other sites pinned, too - is there actually a
list?
Ralph
iang
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
