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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Sun, 25 Jul 2010 20:24:38 -0400
From: Dan Kaminsky <dan@...para.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Expired certificate

On 7/25/2010 4:59 PM, Pavel Kankovsky wrote:
> 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?

Ask me that in a few days ;)

>> 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.

This is a great formulation, actually.

>> 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.

So nobody will sell you a name constrained certificate.  It's almost
like there are serious implementation issues with the extension in the
field.

>> 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.

Absolutely correct.  Whatever world X.509 is great for, it sure ain't
this one.

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

Patch management involves the same thing being put on different hosts,
and there's really no choice -- you can't run an infrastructure without
maintaining it, on some timescale anyway.

Certificate management involves different things being put on different
hosts, and there's totally a choice -- you can simply not have a
certificate at all.

There's definitely some overlap.  But remember, in the field, the data
is not subtle:  Certificates are deployed through gritted teeth.

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

To paraphrase another quote, "X.509 never fails, only X.509 deployers."

The funny thing is, I've met a decent number of the actual authors of
X.509.  They're uniformly brilliant.  Maybe it's like that old Star Trek
pilot...super advanced aliens heal humans who've crash landed on their
planet, but they didn't exactly have a guide to what they were supposed
to do...

> 
>> 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? ;)

You know, it's strange.  I never hear stories about networks being taken
down for nonpayment of electric bills, but we have straight up UI
support for certificate errors.  Why do you think that is?

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