[cryptography] another cert failure

Ryan Hurst ryan.hurst at globalsign.com
Sat Jan 5 16:46:52 EST 2013


It's still not clear it was willful; For example maybe they were using an enterprise CA enable the MiTM for their machines / enterprise users who knew the traffic was monitored and to fix some user reported problem they made a configuration mistake.

After all in the end these are just Base64 blobs; I can see how somebody could be unclear what each one is.

I just don't know for sure. 

But being a paranoid - as all of us likely are given our professions it does seem probable the administrator had a clue about what they were doing.

As for the number of 'CAs', that number is extremely exaggerated - what's important is not the number of certificates that exist but the number of organizations that are responsible for those certificates.

Arguably it's even more important within that set how many different infrastructures manage the associated keys.

I'm not trying to suggest that there are not a lot of organizations that have the ability to issue certificates - there are, that said those numbers are wildly inaccurate.

Another thing to consider when looking at those numbers is how many sovereign nations there are in this world. What the political status of those nations are and their relationships to each other.

How comfortable would two unfriendly nations be with trusting their national infrastructure to CA in the other country?

What about the citizens of countries where no privacy is possible due to government regimes and practices. 

It is a more complicated problem than most people understand.

Should there be a penalty? Possibly, if so it should not be one executed without a complete understanding of the problem and implications.

Ryan Hurst

Sent from my phone, please forgive the brevity.

On Jan 5, 2013, at 1:23 PM, Jeffrey Walton <noloader at gmail.com> wrote:

> On Sat, Jan 5, 2013 at 3:59 PM, Ryan Hurst <ryan.hurst at globalsign.com> wrote:
>> I've been unable to find a screenshot but this FAQ does suggest that there
>> is an explicit action required to enable HTTPS inspection:
>> https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65123
> http://www.youtube.com/watch?v=1lJBBRsc03A, time: 2:45.
> 
> Its now clear it was willful.
> 
>> As for what appropriate consequences are for TurkTrust; so far my position
>> would be that TurkTrust appears to have acted responsibly once they became
>> aware of the issue and it seems their action was not malicious or
>> representative of a systematic failure.
>> 
>> If these two things are true and heavy-handed punishment is levied it would
>> send the message to other actors in this ecosystem that responding openly
>> and responsibly would likely result in the same punishment.
> In the future, we won't need their honesty. Or the 'honesty' they want
> use to perceive.
> 
> There are over 650 roots and subordinate (is that still the case for
> Mozilla?), and we won't miss them.
> 
> Continuing Mozilla's precedent is a bad idea. Mozilla was too ignorant
> or stupid to realize they were not dealing with a 'reasonable person'
> (license here in corporate 'personhood'). Corporations are the
> equivalent of psychopaths. A corporation needs to be held responsible
> and accountable. (A good documentary, if interested:
> http://en.wikipedia.org/wiki/The_Corporation_(film)).
> 
> I wonder how many other CAs confessed to Mozilla back when Trustwave
> did. Probably 0. That's what I would have advised if I were one of the
> corporate lawyers - you never admit to anything.
> 
> Did anyone really think a CA would risk a multimillion dollar business?
> 
>> As such I would think It appropriate to consider this situation and it's
>> facts separately.
> The end result will be the industry just got reinforcement that bad
> behavior is OK. I really don't see how its going to get any
> better..... (sans some initiatives like the SSL observatory).
> 
> Jeff
> 
>> On Jan 5, 2013, at 12:44 PM, Jeffrey Walton <noloader at gmail.com> wrote:
>> 
>> On Sat, Jan 5, 2013 at 3:26 PM, Ryan Hurst <ryan.hurst at globalsign.com>
>> wrote:
>> 
>> 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.
>> 
>> I think we need a screen shot of the UI in question. I have not
>> managed a Checkpoint firewall in years, but I have my suspicions. That
>> might offer something fairly conclusive about the willfulness of the
>> end customer.
>> 
>> TurkTrust likely sold the certificates in pursuit of profits. I don't
>> think there's any doubt about that. Are they not responsible for their
>> actions (even if it was a mistake in hindsight)?
>> 
>> OT: what are folks going to do when a data breach occurs in someone
>> else's cloud provider and your PII/SSN goes flying out the window.
>> Worse, bury it in layers of corporate indirection so its nearly
>> impossible to be made whole. Are folks going to give those negligent
>> the benefit of the doubt and say its OK?
-------------- 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/8ff6f913/attachment.p7s>


More information about the cryptography mailing list