Message-Id: <EEE6F98D-C015-4678-8E0B-3CF4F9E84F64@doxpara.com>
Date: Sat, 17 Jul 2010 09:23:18 -0700
From: Dan Kaminsky <dan@...para.com>
To: Junk Meat <junkmeat@...hawn.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Expired certificate

Junk,

    X.509 always has another way it falls over in the field.   
Expiration management is one of those ways. In theory, it's no big  
deal to swap out an expired cert for a valid one.

    In reality, it's a time bomb, of the sort that usually doesn't  
exist. Does the output of gcc have a 'run by' date?  Will your Cisco  
router simply fail to move traffic six months from now?  Perhaps the  
only thing vaguely akin to certificate failure is hard drive failure  
-- but imagine if drives *intentionally* committed suicide one day  
after warranty expire. People would go nuts!

Somehow, this is all OK in X.509.

Doing an emergency change to production machine is difficult in the  
best of times, when there's an actual outage and the clock is ticking.  
In this case, the outage is basically a policy outage. The box is up,  
it can receive traffic, it's just the other guy needs to handle the  
error differently. So, they're asking for that.

If you're curious *why* it's such a pain in the ass to make unplanned  
changes, it's because of the following process, repeated over and over  
again:

1) Someone needs to make a small change
2) He decides to be a bad ass and just does it
3) There's an outage because the guy screwed up
4) So said guy can keep his job, the outage is blamed on policy that  
clearly needs to be made stronger

Repeat until outage rate drops to accepable levels.



On Jul 17, 2010, at 8:56 AM, Junk Meat <junkmeat@...hawn.com> wrote:

> What part of my thread suggests making unplanned changes in a live
> environment?  All that was said was the re-issuance of a certificate  
> and
> it's installation is a relatively simple process.  So you believe its
> alright to let a certificate remain expired for two weeks?
>
> Don't worry about educating me, there is nothing you have said that I
> don't already know...  it doesn't even sound like you have anything
> intelligent to articulate besides petty criticism and contemptuous  
> remarks.
>
>
> On 7/16/2010 5:16 PM, bk wrote:
>> So basically you advocate making unplanned changes whenever someone  
>> feels like it?
>>
>> The only problem here is that they let the cert expire.  Being  
>> responsible about conducting maintenance, instead of having a knee- 
>> jerk reaction, isn't to be faulted.
>>
>> If you think you can write better secure file transfer software, no  
>> one is stopping you.  You'll make a fortune.  Just remember it has  
>> to support more than half a dozen different protocols, support  
>> dozens of nodes talking to the same storage backends, synchronize  
>> data across datacenters, support triggered actions at multiple  
>> places in the transaction across multiple protocols, support  
>> multiple payload encryption protocols, allow single-sign-on  
>> authentication with third-party vendors, etc, etc, etc.  Oh yeah,  
>> it all has to pass independent code-review by external auditors.   
>> At that rate, supporting instant application of new certs in a  
>> multi-tiered environment with bi-directional trust is a cake-walk  
>> in comparison.
>>
>> Simple, right?
>>
>> I'm done educating you.  I know the software and I know what I'm  
>> talking about; clearly you know neither.
>>
>> On Jul 16, 2010, at 12:49 PM, Junk Meat wrote:
>>
>>
>>> chort or whatever your name is, some of us know what we're doing  
>>> and don't need to wait 2 weeks for a lousy ssl cert update much  
>>> less a daemon restart... give me a break.
>>>
>>> Quit defending the State of California, if they were so up on  
>>> security they shouldn't have passed SB1386 or any other  
>>> legislation for that matter.  Certificate authorities notify their  
>>> customers well in advance of expiring certs, multiple times in  
>>> fact, there's no excuse for that and then expecting your clients  
>>> to violate best practice afterward.  As far as change control and  
>>> system complexity, wise organizations keep things simple not  
>>> overly complex.
>>>
>>> Shawn Dermenjian
>>>
>>> On 7/16/2010 3:11 PM, bk wrote:
>>>
>>>> Maybe you should know what you're talking about before you  
>>>> speculate.  Most daemons require a restart when you change their  
>>>> cert.  When you're talking about a service that has guaranteed up- 
>>>> time, it can only be taken down for scheduled maintenance.   
>>>> Changing production systems on a whim totally fails the 'A' in  
>>>> 'CIA' (and possibly the 'I' too).  Wise organizations implement  
>>>> change-control policies to keep their critical systems from being  
>>>> run-amok by ad-hoc changes.
>>>>
>>>> I'm familiar with the software State of California is using for a  
>>>> lot of their secure file transfers and changing the certificate  
>>>> is not as simple as you think (although the software is extremely  
>>>> secure).  There are several cross-certification trust  
>>>> relationships that need to be established for the software to  
>>>> continue working after replacing certs.
>>>>
>>>> The risk of connecting to a machine with an expired cert is that  
>>>> the cert may have been revoked.  That's why there are expiration  
>>>> dates on certs.  Even if you're using a CRL, you cannot have the  
>>>> CRL contain every cert that was revoked for all of eternity.  The  
>>>> CRL only contains certs from when they were revoked until when  
>>>> they expire.  That keeps CRLs slightly manageable (although OCSP  
>>>> is a much better solution).
>>>>
>>>> If you're still connecting to the same IP and getting the same  
>>>> cert (check the serial number and/or fingerprint), then at least  
>>>> you're sending data to where you always have in the past.  What  
>>>> you want to be weary of is if the serial number and/or  
>>>> fingerprint change and the cert is still invalid (those will  
>>>> probably both change when the cert is re-issued, but then the  
>>>> cert chain and not-before/not-after dates should be legit).
>>>>
>>>> --
>>>> chort
>>>>
>>>> On Jul 16, 2010, at 11:31 AM, Junk Meat wrote:
>>>>
>>>>
>>>>
>>>>> Your right Dan, encryption still does take place.  However, its  
>>>>> hard to
>>>>> understand why renewing
>>>>> a certificate would take so long.  It should take no longer then  
>>>>> 1/2
>>>>> hour to receive a renewed
>>>>> ssl cert from a certificate authority in my opinion and maybe a  
>>>>> few
>>>>> minutes to push it out depending
>>>>> on the device that is publishing the cert.
>>>>>
>>>>> You should tell them that your security policy prevents you from  
>>>>> making
>>>>> a secure ftp transfer to a third
>>>>> party with an expired certificate that contains non-public  
>>>>> information
>>>>> and see how fast they renew
>>>>> their certificate.
>>>>>
>>>>> Basically you are now taking responsibility for any breach in  
>>>>> the slight
>>>>> chance that anything does
>>>>> happen (man-in-the-middle, or otherwise) because you now know  
>>>>> about the
>>>>> problem.  Have them
>>>>> acknowledge the expired ssl certificate on their end and sign- 
>>>>> off on any
>>>>> potential litigation that may
>>>>> result if a breach does happen to occur.
>>>>>
>>>>> -Shawn Dermenjian
>>>>>
>>>>>
>>>>> On 7/16/2010 1:10 PM, Daniel Sichel wrote:
>>>>>
>>>>>
>>>>>> OK, I am in the Golden state (California) where things are not  
>>>>>> so golden
>>>>>> at the moment.
>>>>>> I deal with a state agency and use their "secure" ftp site.
>>>>>> Their certificate has expired and won't be renewed for a few  
>>>>>> weeks, but
>>>>>> they want me to continue to ftp stuff
>>>>>> Using their expired cert.
>>>>>>
>>>>>> So, as a relative n00b,  what are the risks?
>>>>>>
>>>>>> Does it still encrypt even though, obviously, it can't be  
>>>>>> verified?
>>>>>>
>>>>>> My guess is that this still encrypts, but there is no  
>>>>>> authentication,
>>>>>> possibly creating a man in the middle opportunity for some
>>>>>> Nefarious person with evil intent (nobody I know, or who is on  
>>>>>> this
>>>>>> list, of course).
>>>>>>
>>>>>>
>>>>>> Anyway, any info would be welcome from the cognoscenti who  
>>>>>> subscribe
>>>>>> here.
>>>>>>
>>>>>> Thanks,
>>>>>> Dan Sichel
>>>>>>
>>>>>> _______________________________________________
>>>>>> Full-Disclosure - We believe in it.
>>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Full-Disclosure - We believe in it.
>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
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