Shibboleth Identity Provider Security Advisory 20130417: Metadata Provider 'disregardSslCertificate' Option

[Brent Putman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Shibboleth Security Advisory [ 17 April 2013 ]

Identity Provider HTTPS Connections In Metadata Providers May Exhibit
Unexpected Behavior When Used With The 'disregardSslCertificate' Option
=======================================================================

The HTTPMetadataProvider and FileBackedHTTPMetadataProvider implementations
in the IdP support a configuration option 'disregardSslCertificate' to
disable TLS certificate trust evaluation when the provider is configured
with a URL containing an HTTPS scheme. It was discovered that, due to
limitations of the Jakara Commons HttpClient 3.x API, this option has a
global effect on all metadata providers configured with URLs having an HTTPS
scheme.

This will result in unintended behavior of the provider with respect to
TLS certificate trust evaluation if there are multiple metadata providers
defined in relying-party.xml with HTTPS schemes and mixed usage of the
'disregardSslCertificate' option amongst them (meaning some providers
have an effective value of 'disregardSslCertificate=true' and some have
an effective value of 'disregardSslCertificate=false').

The exact undesired behavior will vary with IdP version. For versions up
to and including 2.3.8, all HTTPS providers will have certificate trust
evaluation disabled if there is at least one provider with
'disregardSslCertificate=true'. For versions 2.4.0 and greater, the effective
setting of 'disregardSslCertificate' on the HTTPS provider defined last
in document order within relying-party.xml will determine the setting
in effect for all HTTPS providers.


Affected Versions
=================
All versions of the Identity Provider 2.x

Note that if the remote metadata being retrieved with the provider is
signed using an XML signature by the metadata publisher or source, and
the provider is properly configured to validate this metadata signature,
then this issue has greatly reduced practical significance. In this case,
the use of HTTPS is unnecessary for authentication of the metadata source,
and any issues such as this concerning transport layer security, such as
certificate trust evaluation and hostname verification, are largely irrelevant.

Recommendations
===============
The best remediation is to publish and consume only signed metadata along
with appropriately-configured signature validation within the metadata provider.

Otherwise, all HTTP-based metadata providers which use an HTTPS scheme should be
configured with the same effective setting for 'disregardSslCertificate'.  
The consequence is that all HTTPS providers must and will use the same TLS
certificate trust processing behavior as determined by the value of this option.

The Shibboleth developer team recognizes that this requirement is not ideal.
The issue will be fixed in IdP 3.x with a change to use Apache HttpClient 4.x,
whose API does not suffer from the limitations of the (now end-of-life) Jakarta
Commons HttpClient 3.x.


Credits
=======
Brent Putman, Georgetown University

URL for this Security Advisory
http://shibboleth.net/community/advisories/secadv_20130417.txt


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEAREKAAYFAlFu5iIACgkQTTdwW2HLCz9rPQCfbwBk45CCjQ1G9X6KrHZMUkKX
pEkAn0HmngXx5BL6hs6RjlP4x8hFpbuJ
=nGiK
-----END PGP SIGNATURE-----