On Apr 10, 2014, at 10:38 AM, John Breen <jbr...@isc.upenn.edu> wrote:
> 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? Wes was making two points, I think. The first has to do with the fact that heartbleed affects client AND server: a malicious server can grab client memory contents with a malformed heartbeat request in the same way the client can grab server memory. Wes was pointing out that the cosign clients (mod_cosign, et al) are only clients of one server (cosignd), so the scope for theft of cosign client memory is limited. The second point doesn't actually relate to cosign *credentials*--by which I understand you to mean cookies--but rather cosign *certificates*. Some weblogin environments have elected to allow cosign clients (again, I mean mod_cosign and friends) to authenticate with certificates issued by public CAs. The protected web servers in these deployments are using these same certificates for https. Wes is pointing out that if the private key for these https servers was stolen via heartbleed, attackers could ALSO authenticate to cosignd as the protected service if the weblogin administrators permit client authentication using certificates signed by public CAs. Wes, does that sum it up? andrew
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ 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
