[cryptography] another cert failure

Ryan Hurst ryan.hurst at globalsign.com
Sat Jan 5 15:26:15 EST 2013


Ian, I do agree with you that the dynamic configurations of them firewall is the most suspect part of the story.

I'm inclined to give them the benefit of the doubt based on my experience managing some UI related efforts inside of Windows -- aka today modern software makes an effort to intuit user intent based off of action.

That said I don't know about you but I've never used an intuitive firewall short of IP tables ;)

Ryan Hurst


Sent from my phone, please forgive the brevity.

On Jan 5, 2013, at 12:10 PM, ianG <iang at iang.org> wrote:

> 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 <iang at 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 at randombit.net
>>> http://lists.randombit.net/mailman/listinfo/cryptography
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2098 bytes
Desc: not available
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130105/de3262b0/attachment.p7s>


More information about the cryptography mailing list