Getting a grasp on Heartbleed and IDPs
ndk at internet2.edu
Thu Apr 10 13:25:35 EDT 2014
Wherein Apache was protecting 8443, of course. Sorry. If you're a Tomcat-only IdP deployment, your exposure from this vulnerability is basically nil.
On Apr 10, 2014, at 11:14 AM, Nate Klingenstein <ndk at internet2.edu>
> Any deployer using the IdP's private key to secure mutual TLS connections on 8443 is very impacted because it was typically the IdP's signing key used to secure those connections. The collateral damage in terms of rekeying for individuals is a worse deployment problem but a less significant vulnerability.
> I agree regarding the viability of passwords.
> On Apr 10, 2014, at 11:09 AM, Michael Schwartz <mike at gluu.org>
>> This blog provides a good analysis to understand the impact of
>> Heartbleed: http://www.gluu.co/cacert-heartbleed
>> The private SAML IDP key in the JVM's memory (i.e. tomcat) would not be
>> exposed to the Apache httpd process.
>> However, if the web server's private key is compromised, then you have
>> HTTP, not HTTPS!
>> Password credentials could have leaked. After patching and re-keying the
>> server, people should be advised to reset their password credentials.
>> I think this is the biggest impact.
>> It highlights the cost of our societal over-reliance on
>> passwords--basically the cost of doing nothing. Passwords stolen from
>> one site are used elsewhere. So even if your web server wasn't
>> compromised, a person maybe has the same password in a server that was.
>> So the integrity of password authentication has managed to slip to a new
>> all-time low.
>> - Mike
>> Michael Schwartz
>> Founder / CEO
>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users