Shibboleth Identity Provider Security Advisory [4 October 2017]

Baron Fujimoto baron at hawaii.edu
Tue Nov 21 22:41:41 EST 2017


On Thu, Nov 16, 2017 at 03:05:39PM -1000, Baron Fujimoto wrote:
>On Thu, Nov 16, 2017 at 03:08:39PM +0000, Cantor, Scott wrote:
>>> 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.
>>
>>If by "leave it to Java" you meant "set tustFile to the cacerts file", then yes, I misunderstood you because you didn't say anything about actually pointing the IdP at the file. What most people mean by "leave it to Java" is "do nothing and wave hands in magic gesture". That is what we're not supporting.
>>
>>But having said that, no, you can't do this. Java's cacerts file is a keystore. The trustFile setting doesn't support them, as far as I can tell, it supports PEM and DER formats via a Spring Resource path (file, classpath, HTTP resource, etc.)
>>
>>The source of your confusion seems to be not *how* to configure it, but where you get the CA file(s) from. Yes, you could in theory let Java supply them via certs. No, in practice, you can't, because it's not in a usable format.
>>
>>It's also not wise, because pointing a server trust setting at 150 CAs, some of which are probably operated by somebody in Albania with a laptop, is decidedly unwise.
>>
>>But if you want to write an extractor to pull out all the certs from cacerts into a big PEM concatenated file and run that every time you updated Java, yes, you could do that.
>
>Ah, ok, now I feel like I finally have a clear grasp of this. Thank you
>all for your patience. I also found the nugget about the why the complete
>default set of CAs is discouraged very helpful.

Upon attempting to finally mitigate this with the addition of the
trustFile attribute to the LDAP DataConnector I encounter a
SAXParseException in attribute-resolver.xml caused by, "Attribute
'trustFile' is not allowed to appear in element 'resolver:DataConnector'".

Reviewing the LDAPConnector page at
<https://wiki.shibboleth.net/confluence/display/IDP30/LDAPConnector>
suggests that the trustFile attribute is a feature of V3.3 (if that's what
the superscripts mean)?

Given that we are using V3.2.1, does that mean our mitigation option,
short of upgrading our IdP, is to replace the version of ldaptive inside
the deployed warfile with the latest ldaptive version?

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


More information about the users mailing list