Shibboleth SP 2.4.3 and ExplictKey TrustEngine - SOAP 8443 vs other

[Cantor, Scott]

On 12/1/11 11:05 AM, "Marc Thornton" <joey.granville at gmail.com> wrote:

>We have recently upgraded to Shibboleth SP 2.4.3 from Shibboleth SP
>2.3.1.  Supporting libraries had been previously upgraded to 2.4.3
>"levels" to resolve the XML signature vulnerability, hence only the
>Shibboleth SP software has been upgraded in this pass.

Unless you were building from source, you couldn't use the newer libraries
with a 2.3.1 SP. So I assume you did that, but just making the point in
case there's something off about your build, and because that leaves open
to question what the build process is.

>We are using artifact resolution to transport our assertions, hence
>SOAP/TLS validation is part of the authentication process.

Since it comes up from time to time, any reason for that?

>Since upgrading to Shibboleth SP 2.4.3, the ExplicitKey TrustEngine seems
>to work only for validating SOAP/TLS over port 8443.. attempts to
>validate against the same web server certificate over 8445 or 9443 fail
>for no apparent reason. I've confirmed that ExplicitKey TrustEngine gave
>us a successful match over non-8443 ports on the previous release.

The SP on top has nothing to do with this step. The TLS is OpenSSL, the
HTTPS is libcurl, the cert evaluation (the trust engine) is xmltooling,
and the metadata is opensaml. So if you had some particular version of
those working, and then upgraded only the SP on top, none of that would
change.

>The section of logs at debug level is below:

I don't see any sign of session resumption, so all I can say is, whatever
cert it's getting back is not what's in the metadata.

I thought libcurl on DEBUG would log the cert from the handshake though.
It's not there?

>Version of curl is curl-7.15.5-2.1.el5_3.5

Red Hat's version is fine, at least on RH5.

>As mentioned, I've dug into the source for the Shibboleth SP and other
>libraries and can't locate any instances where 8443 would be a
>"requirement" or would change the behaviour.

It isn't.

Are you using the official packages at this point?

I don't know if it's possible to do it, but I would also try swapping
which endpoint is which on the IdP end, and see if it consistently fails
with that port, or instead with the certificate.

-- Scott