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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
