full-disclosure - Re: Expired certificate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100725215146.97F.0@paddy.troja.mff.cuni.cz>
Date: Sun, 25 Jul 2010 22:59:03 +0200 (CEST)
From: Pavel Kankovsky <peak@...o.troja.mff.cuni.cz>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Expired certificate

On Sat, 24 Jul 2010, Dan Kaminsky wrote:

> And what do you think is doing revocation checking?
> Hint:  Even fewer things than are doing chain validation.

So... no one is doing revocation checking and expiration is evil.
How are we supposed to get rid of invalid certificates?

> The problem is that we assume that security doesn't have to be convenient.

Let me paraphrase one famous sentence: security should be made as
convenient as possible but not more convenient.

> Intermediate certs?  You mean those god-mode can-sign-anything certs
> that are sold for a pile of money, a wink, and a smile?

No. See RFC 3280 Internet X.509 Public Key Infrastructure, section
4.2.1.11 Name Constraints. Any PKIX-compliant application must recognize
this extension.

> Everyone loves blaming the business guys.  Nope.  When it comes to
> X.509, we nerds blew it.

"We blew" it in the sense that X.509 is designed for a strictly
hierarchical bureaucratic environment, not for an open world where
commercial CAs are supposed to compete within a shared namespace.

> > got 500 server that need patches installed
> Windows Update / BigFix, move on with your life.

Your model organization has to go through the following six steps to 
replace every individual expiring certificate:

> 1) A purchase must be made, of the thing to be changed
> 2) A meeting must be scheduled, to organize the change (especially if, 
> as you suggest, an external organization tracks these things)
> 3) An administrator must be tapped to implement the change in non-peak
> time
> 4) The change must happen
> 5) The change must be tested and validated
> 6) The new expiration time must be confirmed for tracking purposes

yet it allows large-scale deployment of patches without any meetings,
planning, testing, and validation? You must be kidding.

> See, here's the problem:  You're all talking about what *could* be the
> case.  I'm telling what *is* the case. 

You should decide whether you want to blame X.509 itself or a 
particular way it is used.

> Expiration is one of a number of serious and genuinely unique
> operational hazards in X.509.

When you fail to pay your electric bill every month, they will cut
your power supply. All your computers will stop working. Is it a 
"genuinely unique operational hazard" too? ;)

-- 
Pavel Kankovsky aka Peak                          / Jeremiah 9:21        \
"For death is come up into our MS Windows(tm)..." \ 21st century edition /

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/