Getting a grasp on Heartbleed and IDPs

[Paul B. Henson]

On Thu, Apr 10, 2014 at 11:05:07AM -0700, Cantor, Scott wrote:

> >And Scott, good suggestion on separate TLS and signing certs.
> 
> It's less a good suggestion and more like "oops, we finally got burned by
> not following good key practices, maybe we should get on the ball".

To clarify, it is a poor practice to use the idp keypair used in the
metadata to also serve as the HTTPS certificate for the backchannel 8443
connection?

Our deployment currently does that; I didn't initially set it up, but my
(evidentally flawed) understanding was that you were supposed to use the
idp cert for the backchannel connection so remote SP's could validate it
based on the metadata.

So what is the recommended certificate for the backchannel https
connection? The same global root CA signed cert as used on port 443?
Some other random self-signed certificate? How does the remote SP
validate the 8443 connection if it's using some other self-signed
certificate for which it does not have the public key? Or is the data
transferred already secure, and the sole point of SSL on the backchannel
is to get a client cert to pass down to the application, such that it's
immaterial what certificate is used?

Currently, the tomcat install guide at:

https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare

shows the example configuration for 8443 as including:

           keystoreFile="IDP_HOME/credentials/idp.jks"

and the sample relying-party.xml included in the shibboleth distribution
includes:

        <security:PrivateKey>$IDP_HOME$/credentials/idp.key</security:PrivateKey>
        <security:Certificate>$IDP_HOME$/credentials/idp.crt</security:Certificate>

Given no other discussion of the certificate for port 8443, this
certainly leads one to believe it should be the same idp.crt as
used in metadata, but stuffed into a java keystore. If you're not
supposed to do that, it would be nice if the documentation more clearly
called out what you are supposed to do.

Thanks...

BTW, given the "If you're paranoid, assume anything in process memory
space might have leaked" perspective, does it really matter if you
weren't using the idp signing key as a TLS key, given it was presumably
in memory and potentially leaked?


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768