Shibboleth Identity Provider Security Advisory [4 October 2017]

[Baron Fujimoto]

On Wed, Nov 15, 2017 at 06:56:14PM +0000, Cantor, Scott wrote:
>On 11/15/17, 1:33 PM, "users on behalf of Baron Fujimoto" <users-bounces at shibboleth.net on behalf of baron at hawaii.edu> wrote:
>
>> At the risk of beating a dead horse, this is what I think I understand the
>> situation to be based on the thread so far.
>
>No, you have a major part of it backwards.
>
>> The trustfile can be the CA (bundle?). This is a better choice to use than
>> the cert for the LDAP host itself because you don't need coordinate
>> changes to the LDAP cert (e.g. expiration);
>
>No, that's a generally necessary choice, not a better choice, but I'm not going to keep contaminating this conversation with my opinions. Stipulate that you're trusting the CA and we'll move on.
>
>> the CA cert bundle is typically kept updated with Java updates, so if you keep Java relatively
>> updated, this aspect is probably handled for you.
>
>No. You will be warned if you do this, and in 4.0 it will fail.

If referencing a CA, as opposed to the cert for the LDAP host, via the
trustFile parameter will fail in future versions then we'd prefer to fix
that properly now. But it's not clear to me this is the case based on
the proscription of the "Java runtime ... default behavior" and whether
that distinguished from pointing to an actual CA certs bundle in a file.

>You MUST explicitly configure every single connection to a server with the trusted keys to be used for that connection. The JVM's trust store is, or will be, irrelevant. That is what the advisory says:
>
>"Note that as of V3.3.2, the software will now warn in most cases if the
>default JVM trust approach is used in the LDAP connector, and a future
>version will no longer support this approach, as it continues to be a
>source of security problems."

Ok. I suppose I am just trying to reconcile this with one of the
mitigation options, "Copy the server's certificate (or more typically a
CA) to a file and reference it with the trustFile attribute."

I already feel dumb for my interpretation of the thread so far, but in for
a penny, in for a pound...  This is where I'm currently at.

One (*interim?) option is to point the LDAP connector at a file containing
the LDAP host's CA in it via the trustFile attribute. But this file should
not be the CA cert bundle (because security). So we should extract the
LDAP host's CA into a not-Java-CA-cert-bundle file and reference that with
trustFile instead.

Not understood: assuming the CA for the LDAP host in the Java-supplied
bundle is valid, what is the difference between the the source of CA cert
being in the Java-supplied bundle the pointing trustFile at this catenated
bundle file, versus extracting it to some other file and referencing that
instead with the trustFile attribute? Is it possible we're
misunderstanding each other here and conflating Java runtime default
behavior with an explicit reference via trustFile to a file, provided by
Java, containing CA certs? Or I'm still fundamentally misunderstanding the
context of the CA here.

>> At least, identifying the certificate in question (for the LDAP host)
>> would have helped.
>
>An advisory cannot be a tutorial in how to configure the software but if the LDAP page needs more explanation on how to configure trust, then that's the best place to fix it.

The new materials added to the LDAPConnector docs re this topic are
helpful.

>> perhaps mentioning it as
>> a resource typically typically maintained with Java updates would have
>> also been helpful – presumably this is not uncommon. (Assuming I'm not
>> off in left field somewhere).
>
>That's exactly what you can't do...

*sigh* Hence, above where I try to determine where I'm going off the
rails.

-- 
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum