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]
Message-Id: <65759CB9-CEA1-42EB-9BEE-EA9A4A516EDC@gmail.com>
Date: Fri, 16 Jul 2010 12:11:00 -0700
From: bk <chort0@...il.com>
To: Junk Meat <junkmeat@...hawn.com>, Daniel Sichel <daniels@...derosatel.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Expired certificate

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ