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] [day] [month] [year] [list]

Date: Sun, 1 Aug 2010 21:38:46 +0200 (CEST)
From: Pavel Kankovsky <peak@...o.troja.mff.cuni.cz>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Expired certificate

On Sun, 25 Jul 2010, Dan Kaminsky wrote:

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

Has one week been enough for you? :)

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

Obviously not serious enough to prevent their use by US Federal Bridge CA.
See <http://www.idmanagement.gov/fpkipa/documents/FBCA_CP_RFC3647.pdf>

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

Governments and big companies *are* hierarchical and bureacratic and X.509
was developed for them.

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

Can't you? The world is full of unpatched systems. You can even find
systems where patches are not installed because it is running a piece of
mission critical software and they would lose support if they installed
any patches (I am not making this up).

> Certificate management involves different things being put on different
> hosts, [...]

This is a red herring. When you have got a bag of certificates, it is
trivial to pick the right certificate for every host and check it
automatically both before and after deployment. And everything else but
the bits (place where the cert is installed, services that need to be
restarted etc.) can stay identical.

> [...] and there's totally a choice -- you can simply not have a
> certificate at all.

Yes. And you can teach your users to check all server public keys
manually. You can also make a choice to send everything in cleartext and
set all passwords to "123456" because it will make your life much easier.

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

I do not say X.509 never fails, I question 

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

There are various cases of epic fails related to electric bills but I
admit I have not found a clear example affecting IT infrastructure 
directly.

Replace interrupted power supply with expired domain registration and
you'll be able to find dozens of incidents, all of them affecting IT for
obvious reasons--and some of them involving big names like Microsoft and
Google.

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