Getting a grasp on Heartbleed and IDPs
Paul B. Henson
henson at csupomona.edu
Thu Apr 10 21:15:55 EDT 2014
> From: Cantor, Scott
> Sent: Thursday, April 10, 2014 1:24 PM
> No, it has to be in the metadata regardless. The key hygeine issue is
> reusing the XML signing key for TLS instead of using separate keys.
> You need a key that's in the metadata
I'm still a bit confused, sorry; in a different thread somebody posted:
So, to identify the certificates/keypairs involved, if I understand correctly there are:
A) the certificate/keypair used on port 443 of the idp for interaction with end-user browsers
B) the certificate/keypair use on port 4443 of the idp for back channel interaction
C) the certificate/keypair configured in relying-party.xml as the security:Credential
D) the public key listed in the IDPSSODescriptor section of the metadata
E) the public key listed in the AttributeAuthorityDescriptor section of the metadata
We can disregard A, as that is just a normal commercial certificate solely used for interaction with end-users.
Currently, in my configuration, B, C, D, and E all refer to the same certificate/keypair.
If I'm understanding correctly, C is the XML signing key, and B is the TLS key. So the recommendation is to make B and C different, but both B and C need to be in the metadata. What is the correlation between B/D and D/E? Does the XML signing key correspond with the IDPSSODescriptor metadata or the AttributeAuthorityDescriptor metadata? And then the TLS key corresponds with whatever one the XML signing key does not?
> It's not in memory when the vulnerability is in Apache and the key is in a
> Java application.
Well, the vulnerability is in openssl, not specifically Apache, so if you're running tomcat with the tomcat-native apr ssl option, the vulnerability is in the java application, right next to the key. At least for us.
More information about the users