[SSL Observatory] Diginotar broken arrow as a tour-de-force of PKI fail
Larry Seltzer
larry at larryseltzer.com
Tue Sep 6 18:22:38 PDT 2011
DANE's nice, but it effectively required DNSSEC, no?
On Tue, Sep 6, 2011 at 8:15 PM, Robert Malmgren <rom at romab.com> wrote:
> On 9/7/11 1:36 AM, Larry Seltzer wrote:
>
> I've never heard of pinning before. There is a proposed IETF spec for a DNS
> record to specify an authorized CA:
> http://tools.ietf.org/html/draft-hallambaker-donotissue-03
>
> Some big names on it, but I'm not sure it's actually gone anywhere.
>
>
> Check out the DANE specification
>
> https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/?include_text=1
>
> That, maybe together with HASTLS, is another mechanism to allow the
> certificate holder to tell the world what they should know about the
> original provider/signer of the certificate.
>
>
> LJS
>
>
> --r
>
>
> On Mon, Sep 5, 2011 at 7:35 PM, Ian G <iang at iang.org> wrote:
>
>> On 5/09/11 7:23 PM, Gervase Markham wrote:
>>
>> The thing which makes the entire system as weak as its weakest link is
>>> the lack of CA pinning.
>>>
>>
>>
>> Just a question of understanding: how is the CA pinning information
>> delivered to the browser?
>>
>> (For those who don't know, I also had to look it up too :) CA pinning is
>> where a particular CA is the only one permitted to issue certs for a
>> website. I think, it's a very new feature, in some browsers only?)
>>
>> An HSM or smart card that does anything the PC that it's attached to
>>>> tells
>>>> it to is only slightly more secure than simply storing the key
>>>> directly on
>>>> the PC. You need to do more to secure a high-value signing process
>>>> than
>>>> sprinkling smart card/HSM pixie dust around and declaring victory.
>>>>
>>>
>>> This is true, but I'm not sure it's particularly relevant.
>>>
>>
>> Well, what's relevant is whether the security processes are doing the job.
>> Evidence over the last year says no. Why?
>>
>> What Peter's saying is that there are signs that the processes are weaker
>> than they appear. One clue is when they go for expensive solutions rather
>> than smart solutions, and declare it done.
>>
>> (Who claims
>>> that HSMs are magic pixie dust?)
>>>
>>
>> CABForum, in BR15.6. "CA must use a HSM" approx.
>>
>> Monkey-see-monkey-do. Which, amusingly, contradicts most of the rest of
>> section 15 :)
>>
>> Lack of breach disclosure requirements for CAs means that they'll cover
>>>> problems up if they can get away with it:
>>>>
>>>
>>> Do you think that remains true?
>>>
>>
>> We don't know. There is no full disclosure mechanism, so we don't know
>> what is disclosed and what not. and even when the full disclosure mechanism
>> is in place, we'll need 20 or so events to gain confidence in it.
>>
>> Recall SB1386? It actually didn't do anything until 2 years had passed.
>> Then someone paniced. And attitudes shifted...
>>
>> Comodo didn't cover their problems up,
>>>
>>
>> Have they released the full report of the issue? Has Mozilla?
>>
>> Or do we just know the headline, and what people have dug up against their
>> best wishes?
>>
>> You saw the chat on mozilla list, another CA declined to report, dressed
>> up by lots of buts, ifs, maybes, not-us's and other rantings.
>>
>> Non-disclosure is certainly in place.
>>
>> and are still in business. DigiNotar covered theirs up, and are not.
>>> Covering up is a massive business gamble, because if anyone finds the
>>> certs in the wild (as happened here), you are toast. Particularly given
>>> that browsers are deploying more technologies like pinning which makes
>>> this sort of attack easier to find, it would be a brave CA who covered a
>>> breach up after the lesson we had last week. You'd have to be pretty
>>> darn confident any misissued certs didn't get obtained by the attackers
>>> - and if they didn't get out, is there actually a problem?
>>>
>>
>>
>> What is of current concern is that CAs may now be "disclosing" to the
>> vendors. And calling that disclosure.
>>
>> This is of concern for several reasons: firstly, it likely puts the
>> vendors in a very difficult position, even to the point of corrupting them.
>> Secondly, it creates a liability-shifting mechanism: the broken CA can now
>> point to this as its industry-standard disclosure mechanism (regardless of
>> utility and user damages) which reduces its own liability, without a
>> commensurate payment; and the vendor now has to take on the risk of suits.
>> Thirdly, it's being done in an ad hoc knee jerk fashion, again in secret,
>> and there is no particular faith that the parties involved will be able to
>> keep their interests of the table.
>>
>> (For Mozilla alone, private disclosure goes against their principles.)
>>
>> I'm not denying that disclosure to vendors may help. But I have no faith
>> in the risk managers at the other side to analyse that risk.
>>
>> If you feel that they can do a good job, post their risk analysis.
>>
>> Right, I thought so, they haven't done one. All vendors are in breach of
>> BR. Doesn't auger well does it :)
>>
>> there's nothing protecting the user. Even the most trivial checks by
>>>> browsers would have caught the fake Google wildcard cert that started
>>>> all
>>>> this.
>>>>
>>>
>>> What sort of "trivial checks" are you suggesting?
>>>
>>
>> Perhaps CA pinning! But in the browser :)
>>
>>
>> Diginotar both passed audits in order to get on the browser gravy
>>>> train and
>>>> then passed a second level of auditing after the compromise was
>>>> discovered.
>>>> The auditors somehow missed that fact that the Diginotar site showed a
>>>> two-
>>>> year history of compromise by multiple hacking groups, something that
>>>> a
>>>> bunch of random commentators on blogs had no problem finding.
>>>>
>>>
>>> I think there are definitely searching questions to ask of DigiNotar's
>>> auditors.
>>>
>>
>> :) and, any other CA audited by that organisation. And any CA audited to
>> that standard....
>>
>> And ... wait, all of them! Oops!
>>
>> Short story -- you won't be able to blame the auditor for this.
>>
>> Sure, you can embarrass them a lot! But, it's pretty obvious on one
>> reading of webtrust that it's a farce. It's also pretty obvious reading BR
>> that an audit would not have picked this up.
>>
>> We could do it ten times over and it's still be the same thing. Audit
>> isn't up to solving this problem, it's only up to lifting the basic game of
>> low-end CAs to some reasonable best-practices level at the governance side.
>>
>> (Another sign that the processes aren't doing the job is that CABForum's
>> solution is to add more audits. We're up to 4, now, right? WebTrust, BR,
>> EV, vendor. Would 5 do it? 6?)
>>
>>
>> available. There is no fallback. Site owners who are concerned about
>>>> the
>>>> security of their users can't do anything, because the browser vendors
>>>> have
>>>> chosen to prevent them from employing any other option (I can't, for
>>>> example, turn on TLS-PSK or TLS-SRP in my server, because no browsers
>>>> support it - it would make the CAs look bad if it were deployed).
>>>>
>>>
>>> Patches welcome? (Or did we reject them already? :-)
>>>
>>
>> Yep, I'm afraid that's the case ;)
>>
>> It's at the attitude level, not any particular patch. Patches aren't
>> welcome. E.g., CA pinning was proposed in the mid-00s and people were told
>> to go away. And take their code with them...
>>
>> I mean, we could be wrong. But who's going to take the chance and spend a
>> month on code, or a year, only to be told no? Again? Who's gonna bother to
>> fight through the human-shield to get to the coders?
>>
>> It's up to the vendors, really. We wait and we watch and we groan.
>>
>>
>>
>> iang
>>
>
>
>
> --
> ---
> Robert Malmgren Encrypted e-mail preferred
> E-mail: rom at romab.com PGP RSA 4096, id: 0x5B979EF5
> Cellular: +46(0)708-330378 Fingerprint: DE59 D86C 4CAF 2E59 A64E
> Jabber: rom at romab.com 5476 2360 F1B4 5B97 9EF5
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/observatory/attachments/20110906/ea1e9991/attachment.html>
More information about the Observatory
mailing list