On 04/08/2014 11:25 AM, Wesley Craig wrote: > On 08 Apr 2014, at 10:54, John Breen <jbr...@isc.upenn.edu> wrote: >> As folks are working on mitigating the heartbleed bug, I wanted to >> inquire about the exposure on the service provider side of things. Once >> the cosignd side of things are mitigated as necessary what does the >> service provider side of the problem look like? >> >> I expect the cosign service private key could potentially be exposed on >> affected systems. Is that accurate? If that is the case, I expect >> re-issuing the service certificates (after updating openssl) is the >> correct action. > Both the client and server in the SSL protected session are vulnerable to > heartbleed, however, for the client side, the leak is only to the (possibly > compromised) server. Many people use their HTTP certificates as client > certificates for mod_cosign, tho. Those would be easily obtainable from the > HTTP server running at the service provider. > > :wes So a quick clarification here...
Are we saying that a cosign service credential can not be leaked via heartbleed to a 3rd party even if the cosign client service is vulnerable? That the cosign client service credential could only be obtained by using the cosignd server as an attack vector? Why is the cosign client credential different than say an SSL certificate as far as it potentially being in memory that might be leaked? Thanks, John ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
