[Shib-Users] Shib 2.1 SP + 1.3 IdP attribute query problem

Tom Poage

unread,

Oct 14, 2008, 7:14:17 PM10/14/08

to shibbole...@internet2.edu

Greetings,

Does the following look familiar?

Trying to plumb up a 2.1 SP (Fedora 8) to our production 1.3 IdP
(RedHat 5). The SP is built from:

> log4shib-1.0-1.src.rpm
> opensaml-2.1-1.src.rpm
> shibboleth-2.1-1.src.rpm
> xerces-c-2.8.0-1.src.rpm
> xml-security-c-1.4.0-1.src.rpm
> xmltooling-1.1-1.src.rpm

I'm getting a session (/Shibboleth.sso/Session), but no attributes
apparently do to an SSL/TLS problem:

> 2008-10-14 15:40:50 DEBUG Shibboleth.SSO.SAML1 [3]: resolving attributes...
> 2008-10-14 15:40:50 DEBUG Shibboleth.AttributeResolver.Query [3]: attempting SAML 1.x attribute query
> 2008-10-14 15:40:50 DEBUG XMLTooling.SOAPTransport.CURL [3]: getting connection handle to https://shibboleth.ucdavis.edu:8443/shibboleth-idp/AA
> 2008-10-14 15:40:50 DEBUG XMLTooling.SOAPTransport.CURL [3]: nothing free in pool, returning new connection handle
> 2008-10-14 15:40:50 DEBUG Shibboleth.SOAPClient [3]: prepping SOAP transport for use by application (default)
> 2008-10-14 15:40:50 DEBUG XMLTooling.SOAPClient [3]: marshalled envelope:
> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><samlp:Request xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2008-10-14T22:40:50Z" MajorVersion="1" MinorVersion="1" RequestID="_827d93e991b[...]"><samlp:AttributeQuery Resource="https://....ucdavis.edu/shibboleth"><saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"><saml:NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier" NameQualifier="urn:mace:incommon:ucdavis.edu">L7OYBQ2732[...]</saml:NameIdentifier></saml:Subject></samlp:AttributeQuery></samlp:Request></S:Body></S:Envelope>
> 2008-10-14 15:40:50 DEBUG XMLTooling.SOAPTransport.CURL [3]: sending SOAP message to https://shibboleth.ucdavis.edu:8443/shibboleth-idp/AA
> 2008-10-14 15:40:50 ERROR Shibboleth.AttributeResolver.Query [3]: exception during SAML query to https://shibboleth.ucdavis.edu:8443/shibboleth-idp/AA: CURLSOAPTransport failed while contacting SOAP responder: Unknown cipher in list: ALL:!aNULL:!LOW:!EXPORT:!SSLv2
> 2008-10-14 15:40:50 ERROR Shibboleth.AttributeResolver.Query [3]: unable to obtain a SAML response from attribute authority

The IdP is using a configuration along the lines of that documented
on the Shibboleth-1 wiki:

> <VirtualHost *:8443>
> ServerName ...:8443
...
> SSLEngine on
> SSLProtocol all -SSLv2
> SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
> SSLCertificateFile ...
> SSLCertificateKeyFile ...
> SSLVerifyClient optional_no_ca
> SSLVerifyDepth 10
> SSLOptions +StdEnvVars +ExportCertData
...
> ProxyPass /shibboleth-idp/ ajp://localhost:8009/shibboleth-idp/
>
> </VirtualHost>

If I recall correctly, the Internet2 wiki is running SP 2.x; this
works fine for me through our IdP (always has).

If anyone has seen/resolved this, I'd appreciate any info.

Thanks!
Tom.
--
Tom Poage
Application Development/Middleware
University of California, Davis

Nate Klingenstein

unread,

Oct 14, 2008, 7:23:20 PM10/14/08

to shibbole...@internet2.edu

Tom,

I don't think the cipher alias EXPORT even exists, which would result in that error. There's just EXP, EXPORT40, and EXPORT56. Where did you find that list in the Wiki? I can't find it, and the example at JKIdPInstall looks okay:

SSLCipherSuite ALL:!ADH:!EXPORT56:!EXPORT40:RC4+RSA:!SSLv2:+HIGH:+MEDIUM:+LOW:+EXP

https://spaces.internet2.edu/display/SHIB/JKIdPInstall

http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslciphersuite

Wonder why we're getting so many cipher suite questions all of a sudden. :D

Nate.

Tom Poage

unread,

Oct 14, 2008, 8:37:06 PM10/14/08

to shibbole...@internet2.edu

Hi, Nate:

> On 10/14/2008 04:23 PM, Nate Klingenstein wrote:
>> Tom,
>>
>> I don't think the cipher alias EXPORT even exists, which would result in
>> that error. There's just EXP, EXPORT40, and EXPORT56. Where did you
>> find that list in the Wiki? I can't find it, and the example at
>> JKIdPInstall looks okay:

I'll have to dig to find where I (previously) found it. Hmm, maybe I
dreamed it up? :-)

This is ... interesting (on the SP):

> $ rpm -q curl
> curl-7.18.2-6.fc8
> $ curl --ciphers 'ALL:!aNULL:!LOW:!EXPORT:!SSLv2' https://shibboleth.ucdavis.edu:8443/shibboleth-idp/AA
> curl: (59) Unknown cipher in list: ALL:!aNULL:!LOW:!EXPORT:!SSLv2
> $ curl --ciphers 'ALL:!aNULL:!LOW:!EXPORT:!SSLv2' https://www.google.com/
> curl: (59) Unknown cipher in list: ALL:!aNULL:!LOW:!EXPORT:!SSLv2

Kept trying various combinations of removing ciphers from the list
and could not get it to work properly without the error. Works w/o
the ciphers command.

> $ curl --verbose https://www.google.com/
> * About to connect() to www.google.com port 443 (#0)
> * Trying 74.125.19.103... connected
> * Connected to www.google.com (74.125.19.103) port 443 (#0)
> * CAfile: /etc/pki/tls/certs/ca-bundle.crt
> CApath: none
> * SSL connection using SSL_RSA_WITH_RC4_128_MD5
...

Getting closer: an NSS error?

> $ curl --verbose --ciphers 'RSA' https://www.google.com/
> * About to connect() to www.google.com port 443 (#0)
> * Trying 74.125.19.147... connected
> * Connected to www.google.com (74.125.19.147) port 443 (#0)
> * Unknown cipher in list: RSA
> * NSS error -5978
> * Closing connection #0
> curl: (59) Unknown cipher in list: RSA

The error is CURLE_SSL_CIPHER (59) : Couldn't use specified cipher.

The ciphers are, not surprisingly, supposed to conform to
http://www.openssl.org/docs/apps/ciphers.html

In comparison:

> $ openssl ciphers -v 'ALL:!aNULL:!LOW:!EXPORT:!SSLv2'
> DHE-DSS-RC4-SHA SSLv3 Kx=DH Au=DSS Enc=RC4(128) Mac=SHA1
> DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
> DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
> AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
> DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
> DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
> AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
> KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5
> KRB5-DES-CBC3-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=MD5
> KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1
> KRB5-DES-CBC3-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=SHA1
> EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
> EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
> DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
> RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
> RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5

Note that removing the '!EXPORT' includes a handful of 40- and
56-bit ciphers:

> $ openssl ciphers -v 'ALL:!aNULL:!LOW:!SSLv2'
> DHE-DSS-RC4-SHA SSLv3 Kx=DH Au=DSS Enc=RC4(128) Mac=SHA1
> EXP1024-DHE-DSS-RC4-SHA SSLv3 Kx=DH(1024) Au=DSS Enc=RC4(56) Mac=SHA1 export
> EXP1024-RC4-SHA SSLv3 Kx=RSA(1024) Au=RSA Enc=RC4(56) Mac=SHA1 export
> EXP1024-DHE-DSS-DES-CBC-SHA SSLv3 Kx=DH(1024) Au=DSS Enc=DES(56) Mac=SHA1 export
> EXP1024-DES-CBC-SHA SSLv3 Kx=RSA(1024) Au=RSA Enc=DES(56) Mac=SHA1 export
> DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
> DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
> AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
> DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
> DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
> AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
> EXP-KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(40) Mac=MD5 export
> EXP-KRB5-RC2-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC2(40) Mac=MD5 export
> EXP-KRB5-DES-CBC-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=DES(40) Mac=MD5 export
> EXP-KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(40) Mac=SHA1 export
> EXP-KRB5-RC2-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC2(40) Mac=SHA1 export
> EXP-KRB5-DES-CBC-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=DES(40) Mac=SHA1 export
> KRB5-RC4-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=MD5
> KRB5-DES-CBC3-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=MD5
> KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1
> KRB5-DES-CBC3-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=SHA1
> EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
> EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export
> EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
> EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export
> DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
> EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export
> EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
> RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
> RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
> EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export

On the SP, curl was updated on my development SP Sep 26th (I built
the SP RPMs yesterday).

> yum.log:Sep 26 11:24:35 Updated: curl-7.18.2-6.fc8.i386
> yum.log:Sep 26 11:25:30 Updated: curl-devel-7.18.2-6.fc8.i386

Goodness, so was NSS

> yum.log:Sep 26 11:30:46 Updated: nss-3.12.1.1-1.fc8.i386
> yum.log:Sep 26 11:30:54 Updated: nss-devel-3.12.1.1-1.fc8.i386
> yum.log:Sep 26 11:31:18 Updated: nss-tools-3.12.1.1-1.fc8.i386

Soo, it sort of looks like a libcurl+NSS bug. Given that I'm _still_
:-\ running Fedora 8 on this box, I'll try to get a current copy of
libcurl (7.19.0) and build it against OpenSSL ... or some such.

Poked around the curl-library mailing list and see an issue related
to the fact that libcurl is built against NSS on Fedora 9, and that
it was/is broken. Hmm.
http://curl.haxx.se/mail/lib-2008-06/0248.html

Thanks!
Tom.

Scott Cantor

unread,

Oct 14, 2008, 11:36:04 PM10/14/08

to shibbole...@internet2.edu

> Poked around the curl-library mailing list and see an issue related
> to the fact that libcurl is built against NSS on Fedora 9, and that
> it was/is broken.

You can find the explanation of all this in the list archive, but suffice to
say the SP cannot run on top of the curl package provided by Fedora (or
later Red Hat) if they persist with this bad decision. The only fix is to
provide a corrected version of libcurl to use.

I haven't yet decided what to do about this for Red Hat 6, but I don't
support Fedora in any case.

-- Scott

Tom Poage

unread,

Oct 15, 2008, 11:05:33 AM10/15/08

to shibbole...@internet2.edu

Thanks for the additional info. Funny, I looked through the archive,
as I had vaguely recalled something to do with libcurl+NSS, but must
not have used the right search terms. Sorry for the bother.

Rebuilt the current Fedora 8 curl source RPM against OpenSSL by
tweaking the spec file a bit. Will try to test.

FWIW, I noticed a comment on one of the curl lists regarding a
different problem with Fedora 9 (curl+NSS). The response plainly
states that the curl team is interested in having it work (properly)
over NSS. We'll see if that gets any traction/attention.

I understand why Fedora is not supported. It is a two-edged sword
at times. As I think about it, so is Solaris, Windows, .... :-)

Tom.

Scott Cantor

unread,

Oct 15, 2008, 2:33:11 PM10/15/08

to shibbole...@internet2.edu

> Rebuilt the current Fedora 8 curl source RPM against OpenSSL by
> tweaking the spec file a bit. Will try to test.

As we get closer to Red Hat 6, I'm definitely going to need some guidance or advice about the best way to deal with this. I obviously need to somehow provide my own libcurl RPM. I can rename it, of course, but I can't easily rename the underlying libcurl files, so I'm not sure what the best approach would be.

> FWIW, I noticed a comment on one of the curl lists regarding a
> different problem with Fedora 9 (curl+NSS). The response plainly
> states that the curl team is interested in having it work (properly)
> over NSS. We'll see if that gets any traction/attention.

NSS simply doesn't have the same interfaces for hooking SSL validation, and at the moment, libcurl doesn't support the features I have to use. It might all work out some day in the future, but the set of things that will have to change to handle NSS is huge.

> I understand why Fedora is not supported. It is a two-edged sword
> at times. As I think about it, so is Solaris, Windows, .... :-)