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

On Tue, 20 Jul 2010, Marsh Ray wrote:

> The usual logic given for this and other types of mandatory password 
> expiration schemes is that it limits the time of exposure when the 
> credentials are compromised. These days this reasoning makes less sense 
> when the attacker might only need to use his unauthorized access for 
> 50ms or so to install a persistent backdoor.

There are still other risks.

Old copies of keys (or passwords) can be disclosed accidently or during an
attack. (With the recent explosive growth of storage capacity it is a
little bit too easy to keep many old forgotten copies of sensitive files.)
Advances in cryptology and computing power can make old keys unsafe.
People may neglect to revoke certificates that have become invalid (e.g.
a personal certificate for someone who has deceased).

And of course the risk of private key being stolen and being abused even
after the compromised system has been cleaned up. There are situations
where it is not possible to assume the other party is able to keep an up
to date copy of CRL and check it (moreover, the lack of expiration date
would make CRLs grow beyond any limit).

> Drivers licenses, (as Pavel said) passports, most kinds of real-world
> credentials expire. In the computer field we deal with 10+ orders of
> magnitude on the time axis (10 years vs 100 ms) so normal policies don't
> scale well.

Even in the realm of passports et al. 10 years is way too long to prevent
abuse. But it helps to reduce the number of documents that might be
accepted as valid despite having been lost or stolen, carrying photographs
too old to allow reliable verification or containing information that is
not valid any longer.

The problem is a conflict between security and convenience.

Ironically, online communication allows a rather elegant solution: you can
have a hierarchy of certificates starting with short-lived certs for
routine operation issued online by the lowest level of intermediate CAs
with each level offering less automation to reduce exposure and longer
lifetimes to make up for lost convenience.

Unfortunately, this approach (while being quite feasible from the
technical POV) appears to be incompatible with the business model of
existing CAs.


On Thu, 22 Jul 2010, Dan Kaminsky wrote:

> Suppose I have five hundred web servers with five hundred expiration
> dates, strewn out roughly uniformly over a three year period.  That
> means, I have about one expiration every two days.
>
> Now, to run a change: [...]
>
> Lets say this is 8 man hours.  That means this is 4,000 man hours of
> work. Assume the employee doing this work has an average cost to the
> company of $60/hr (remember, you need to roughly double the cost of a
> full time employee, after you factor in benefits, payroll taxes, etc).

If you have got 500 servers that need renewed certificates then you have 
got 500 server that need patches installed, not to mention other routine 
admin tasks. If you need 8 man hours per server to renew one certificate, 
how many man hours per server do you need to deploy one patch?


On Fri, 23 Jul 2010, Meadow wrote:

> If your organization really did have the expiration staggered at every
> 2 days, then you should take a bunch of servers (grouped by
> segment/application/whatever makes sense in your environment) and renew
> all the certs on that group of servers at once, even if they aren't all
> quite expired yet.  You should also fire your program manager.  The
> savings in labor and down-time would make up for the one-time cost of
> renewing some certs prematurely.

Many (if not most) CAs let you renew a certificate two or three months
before its expiration and give you the remaining time back. One who needs
to renew one certificate every other day can do it once in 2 or 3 months 
in batches of up to 30 or 45 renewals without losing anything.


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

Powered by blists - more mailing lists