Re: [Full-disclosure] Expired certificate

[Junk Meat <junkmeat@xxxxxxxxxxx>]

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/