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/
