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
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
