Shibboleth Service Provider Security Advisory [15 June 2009]

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Shibboleth Service Provider Security Advisory [15 June 2009]

Cantor, Scott E.
Shibboleth Service Provider Security Advisory [15 June 2009]

Updated versions of the Shibboleth 1.3.x and 2.x Service Provider
software are now available which correct a security issue.

This advisory pertains ONLY to sites running the SP software in
conjunction with Microsoft's Internet Information Server (IIS)
web server. All IIS and Windows versions are believed to be affected,
primarily in conjunction with ASP.NET applications. While classic ASP
and some other development tools are believed near-term safe, all IIS
deployers should review this advisory and take appropriate steps.

There are no known issues affecting non-IIS deployments, including
all non-Windows deployments, and Apache on Windows.

This is a MAJOR security issue and deployers are urged to review
the information below and upgrade their installations at the soonest
possible time. Critical applications that may be vulnerable should be
taken offline until the upgrade is performed.


Shibboleth SP software on IIS vulnerable to header spoofing
============================================================
On IIS, Shibboleth publishes user attributes associated with
sessions into HTTP request headers, based on header names defined
in Attribute Acceptance Policy (1.3.x) or Attribute Mapping (2.x)
files. These headers are transformed into CGI variables based
on mapping rules defined by the CGI specification. A number of
built-in headers are set by the SP as well.

The mapping between headers and CGI variables is not exact, and there
are multiple header names that can map to the same variable. IIS in
particular handles underscores and hyphens in header names in an
unusual and problematic way, and behaves differently with respect
to ASP.NET scripts than with classic ASP and other tested languages.

The code in Shibboleth that is designed to clear out the potential
headers that could contain authentication and attribute information
cannot handle the underscore/hyphen distinction efficiently and
cannot protect against such spoofing for the affected ASP.NET
environment.

This means that a client could supply a spoofed header with the
right name and fool an application into believing that the header
was set by the Shibboleth software.

All versions of Shibboleth used with IIS are vulnerable to this issue
when an affected application language is used. At this time, only ASP.NET
is known to be affected, but it's likely that others may be affected now
or in the future.

However, the specific headers affected are ONLY those containing either
a hyphen or an underscore (not including the leading underscore following
the HTTP prefix).

For example, the built-in header "HTTP_SHIB_IDENTITY_PROVIDER" *is*
vulnerable, but a mapped header name of "HTTP_GIVENNAME" would *not* be.


Recommendations
---------------

Because this is a complex issue, and there are a variety of work-arounds
both pre- and post-update, please refer to this wiki topic for detailed
information on assessing vulnerability and the trade-offs of various
approaches:

https://spaces.internet2.edu/display/SHIB2/secadv_20090615

This should address most questions and provide advice on both short-term
and longer-term measures, including safe coding practices. If in doubt,
feel free to contact the support list, or if you require confidential
advice, feel free to use the "security reporting form" at
http://shibboleth.internet2.edu/shib-sec-contact.cfm

As a general recommendation:

Affected sites using 1.3.x should upgrade to the latest patched release,
1.3.2.

Affected sites using 2.x should upgrade to the latest patched release,
2.2.

Having done so, you will have a measure of protection while researching
your exposure to the problem and how to address it. But this is NOT a
complete fix and deployers are urged to review the topic above to fully
address the issue. It is likely that the new "safeHeaderNames" option will
need to be enabled (it is on by default in new installations) and that
applications hosted on IIS will require changes in the header names they
are accessing to completely address the problem.

As only Windows sites are affected in a security sense, note that the
simplest way to patch is with the post-install ZIP archives available
from the official download site. Updated installers are also available.

http://shibboleth.internet2.edu/downloads.html

At the time of writing, RPMs and other package formats may not yet be
available, since the urgency of the update is a Windows-only issue.
Source tarballs will however be posted, and other official packages will
follow as time permits.


URL for this Security Advisory:
http://shibboleth.internet2.edu/secadv/secadv_20090615.txt

Reply | Threaded
Open this post in threaded view
|

Re: Shibboleth Service Provider Security Advisory [15 June 2009]

Ina Müller
Scott, could you clarify the following situation:

- Windows Server 2003, IIS6, SP 2.1

- the ids in our attribute-map.xml all follow the pattern id="Shib-xxx"

- the ASP.NET application relies only on header variables fetched from
the NameValueCollection System.Web.HttpRequest.Headers and so these
variables have the keys "Shib-surName", "Shib-email", ... .

Even the built-in headers then have keys "Shib-Identity-Provider",
"Shib-Authentication-Instant", ... when accessed via the
NameValueCollection of System.Web.HttpRequest.Headers - no HTTP prefix
and no underscore!
And REMOTE_USER from ApplicationDefaults in shibboleth2.xml is mapped to
key "remote-user".

- and yes, I know: if I access shib attributes via HttpRequest.Headers
or HttpRequest.ServerVariables, the keys in the NameValueCollection are
named as you describe: HTTP_SHIB_APPLICATION_ID, HTTP_SHIB_COMMONNAME,
HTTP_REMOTE_USER, ...

So my question: is my application vulnerable, when only relying on the
"Shib-xxx" keys in System.Web.HttpRequest.Headers?

Ina





Scott Cantor wrote:

> Shibboleth Service Provider Security Advisory [15 June 2009]
>
> Updated versions of the Shibboleth 1.3.x and 2.x Service Provider
> software are now available which correct a security issue.
>
> This advisory pertains ONLY to sites running the SP software in
> conjunction with Microsoft's Internet Information Server (IIS)
> web server. All IIS and Windows versions are believed to be affected,
> primarily in conjunction with ASP.NET applications. While classic ASP
> and some other development tools are believed near-term safe, all IIS
> deployers should review this advisory and take appropriate steps.
>
> There are no known issues affecting non-IIS deployments, including
> all non-Windows deployments, and Apache on Windows.
>
> This is a MAJOR security issue and deployers are urged to review
> the information below and upgrade their installations at the soonest
> possible time. Critical applications that may be vulnerable should be
> taken offline until the upgrade is performed.
>
>
> Shibboleth SP software on IIS vulnerable to header spoofing
> ============================================================
> On IIS, Shibboleth publishes user attributes associated with
> sessions into HTTP request headers, based on header names defined
> in Attribute Acceptance Policy (1.3.x) or Attribute Mapping (2.x)
> files. These headers are transformed into CGI variables based
> on mapping rules defined by the CGI specification. A number of
> built-in headers are set by the SP as well.
>
> The mapping between headers and CGI variables is not exact, and there
> are multiple header names that can map to the same variable. IIS in
> particular handles underscores and hyphens in header names in an
> unusual and problematic way, and behaves differently with respect
> to ASP.NET scripts than with classic ASP and other tested languages.
>
> The code in Shibboleth that is designed to clear out the potential
> headers that could contain authentication and attribute information
> cannot handle the underscore/hyphen distinction efficiently and
> cannot protect against such spoofing for the affected ASP.NET
> environment.
>
> This means that a client could supply a spoofed header with the
> right name and fool an application into believing that the header
> was set by the Shibboleth software.
>
> All versions of Shibboleth used with IIS are vulnerable to this issue
> when an affected application language is used. At this time, only ASP.NET
> is known to be affected, but it's likely that others may be affected now
> or in the future.
>
> However, the specific headers affected are ONLY those containing either
> a hyphen or an underscore (not including the leading underscore following
> the HTTP prefix).
>
> For example, the built-in header "HTTP_SHIB_IDENTITY_PROVIDER" *is*
> vulnerable, but a mapped header name of "HTTP_GIVENNAME" would *not* be.
>
>
> Recommendations
> ---------------
>
> Because this is a complex issue, and there are a variety of work-arounds
> both pre- and post-update, please refer to this wiki topic for detailed
> information on assessing vulnerability and the trade-offs of various
> approaches:
>
> https://spaces.internet2.edu/display/SHIB2/secadv_20090615
>
> This should address most questions and provide advice on both short-term
> and longer-term measures, including safe coding practices. If in doubt,
> feel free to contact the support list, or if you require confidential
> advice, feel free to use the "security reporting form" at
> http://shibboleth.internet2.edu/shib-sec-contact.cfm
>
> As a general recommendation:
>
> Affected sites using 1.3.x should upgrade to the latest patched release,
> 1.3.2.
>
> Affected sites using 2.x should upgrade to the latest patched release,
> 2.2.
>
> Having done so, you will have a measure of protection while researching
> your exposure to the problem and how to address it. But this is NOT a
> complete fix and deployers are urged to review the topic above to fully
> address the issue. It is likely that the new "safeHeaderNames" option will
> need to be enabled (it is on by default in new installations) and that
> applications hosted on IIS will require changes in the header names they
> are accessing to completely address the problem.
>
> As only Windows sites are affected in a security sense, note that the
> simplest way to patch is with the post-install ZIP archives available
> from the official download site. Updated installers are also available.
>
> http://shibboleth.internet2.edu/downloads.html
>
> At the time of writing, RPMs and other package formats may not yet be
> available, since the urgency of the update is a Windows-only issue.
> Source tarballs will however be posted, and other official packages will
> follow as time permits.
>
>
> URL for this Security Advisory:
> http://shibboleth.internet2.edu/secadv/secadv_20090615.txt
>

--
------------------------------------------
Ina Müller
Zentrum für Datenverarbeitung
Netze und Netzdienste
Wächterstr. 76
D-72074 Tübingen

[hidden email]
07071 / 29 70 345
------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Shibboleth Service Provider Security Advisory [15 June 2009]

Ina Müller

> - and yes, I know: if I access shib attributes via HttpRequest.Headers
> or HttpRequest.ServerVariables, the keys in the NameValueCollection are
> named as you describe: HTTP_SHIB_APPLICATION_ID, HTTP_SHIB_COMMONNAME,
> HTTP_REMOTE_USER, ...

typing error :-)

* HttpRequest.Params or HttpRequest.ServerVariables have keys HTTP_
* HttpRequest.Headers have keys without HTTP_ or underscores
Reply | Threaded
Open this post in threaded view
|

RE: Shibboleth Service Provider Security Advisory [15 June 2009]

Cantor, Scott E.
In reply to this post by Ina Müller
Ina Müller wrote on 2009-06-17:
> - the ASP.NET application relies only on header variables fetched from
> the NameValueCollection System.Web.HttpRequest.Headers and so these
> variables have the keys "Shib-surName", "Shib-email", ... .

I don't know, but my guess is that it's not as vulnerable because it's
accessing the headers by the literal name I'm using internally. But that's
all it is, a guess. It could be not only vulnerable but impossible to
protect.

I'll try to run some tests.

> Even the built-in headers then have keys "Shib-Identity-Provider",
> "Shib-Authentication-Instant", ... when accessed via the
> NameValueCollection of System.Web.HttpRequest.Headers - no HTTP prefix
> and no underscore!
> And REMOTE_USER from ApplicationDefaults in shibboleth2.xml is mapped to
> key "remote-user".

Yes, that's what I would expect from what you're describing.

> So my question: is my application vulnerable, when only relying on the
> "Shib-xxx" keys in System.Web.HttpRequest.Headers?

If I can determine the answer, I'll update the relevant material. If that's
a workable solution, I'll note it, but don't wait to upgrade. The only
impact would be the ability to keep that safeHeaderNames flag off.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Shibboleth Service Provider Security Advisory [15 June 2009]

Cantor, Scott E.
In reply to this post by Ina Müller
> Ina Müller wrote on 2009-06-17:
>> So my question: is my application vulnerable, when only relying on the
>> "Shib-xxx" keys in System.Web.HttpRequest.Headers?

It appears to be safe, even to the point of handling case differences. This
would be the advisable mechanism to use, so I'll update the wiki and the
advisory. Thank you for bringing that to my attention.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Shibboleth Service Provider Security Advisory [15 June 2009]

Sohail Bashadi
We are running Windows 2000 Server and I did not understand the following statement on the wiki:

Windows 2000 and Earlier
------------------------
On older Windows versions, in addition to the above, you will also need to add a setting to that same configuration element named spoofKey containing a long, random string of characters. Without that setting, your web server will fail to load the filter with an error in the Windows event log.

What does the statement 'you will also need to add a setting to that same configuration element named spoofKey containing a long, random string of characters' mean? Are there any examples of this? Where exactly do I need to set this config?

Any pointers are greatly appreciated.

Thanks,
Sohail
-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Wednesday, June 17, 2009 9:41 AM
To: [hidden email]
Subject: RE: [Shib-Users] Shibboleth Service Provider Security Advisory [15 June 2009]

> Ina Müller wrote on 2009-06-17:
>> So my question: is my application vulnerable, when only relying on the
>> "Shib-xxx" keys in System.Web.HttpRequest.Headers?

It appears to be safe, even to the point of handling case differences. This
would be the advisable mechanism to use, so I'll update the wiki and the
advisory. Thank you for bringing that to my attention.

-- Scott



Reply | Threaded
Open this post in threaded view
|

Re: Shibboleth Service Provider Security Advisory [15 June 2009]

Peter Schober
* Sohail Bashadi <[hidden email]> [2009-06-17 17:59]:
> What does the statement 'you will also need to add a setting to that
> same configuration element named spoofKey containing a long, random
> string of characters' mean? Are there any examples of this? Where
> exactly do I need to set this config?

https://spaces.internet2.edu/display/SHIB2/NativeSPInProcess
-peter
Reply | Threaded
Open this post in threaded view
|

RE: Shibboleth Service Provider Security Advisory [15 June 2009]

Cantor, Scott E.
In reply to this post by Sohail Bashadi
Sohail Bashadi wrote on 2009-06-17:
> What does the statement 'you will also need to add a setting to that same
> configuration element named spoofKey containing a long, random string of
> characters' mean? Are there any examples of this? Where exactly do I need
to
> set this config?

https://spaces.internet2.edu/display/SHIB2/NativeSPInProcess

2.x:
<InProcess ... spoofKey="longrandomstuff" ... >

1.3:
<Local ... spoofKey="longrandomstuff" ... >

-- Scott


Reply | Threaded
Open this post in threaded view
|

SSL handshake error after updating to 1.3.2 - Re: Shibboleth Service Provider Security Advisory [15 June 2009]

Grady, Michael Allen
In reply to this post by Cantor, Scott E.
So we updated a Windows Shib SP that was at version 1.3.1 to 1.3.2  
using the postinstall zip file:
  http://shibboleth.internet2.edu/downloads/shibboleth/cppsp/1.3.2/ 
win32/shibboleth-sp-1.3.2-win32-postinstall.zip

following the instructions at:
  https://spaces.internet2.edu/display/SHIB2/NativeSPWindowsUpgrade

and then updating shibboleth.xml appropriately. And then trying to  
authenticate to an IdP we know our setup has been working with (the  
UIUC IdP). The authentication assertion is working fine, but when the  
SP goes to get an attribute assertion from the AA endpoint, we are  
getting an SSL handshake error (lines from the shibd.log on the SP  
follow). Any pointers as to what to look into/do to resolve this?

----
2009-06-17 13:29:08 DEBUG Shibboleth.ShibBrowserProfile [12]  
sessionNew: searching metadata for assertion issuer...
2009-06-17 13:29:08 DEBUG Shibboleth.ShibBrowserProfile [12]  
sessionNew: matched assertion issuer against metadata
2009-06-17 13:29:08 DEBUG Shibboleth.ShibBrowserProfile [12]  
sessionNew: passing signed response to trust layer
2009-06-17 13:29:08 DEBUG Shibboleth.Trust.Basic [12] sessionNew:  
validating signature with KeyDescriptors
2009-06-17 13:29:08 DEBUG Shibboleth.Trust.Basic [12] sessionNew:  
KeyDescriptor resolved into a key, trying it...
2009-06-17 13:29:08 DEBUG Shibboleth.Trust.Basic [12] sessionNew:  
signature verified with KeyDescriptor
2009-06-17 13:29:08 INFO Shibboleth.ShibBrowserProfile [12]  
sessionNew: verified digital signature over SSO response
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [12] sessionNew:  
caching new entry for application default:  
"_e388743ad71df49988c9339c176f4749"
2009-06-17 13:29:08 INFO shibtarget.SessionCache [12] sessionNew: new  
session created with session ID (_e388743ad71df49988c9339c176f4749)
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [12] sessionNew:  
NameID (_099e811c1561a73b42b2c967710ed23e), IdP  
(urn:mace:incommon:uiuc.edu), Address (128.174.84.43)
2009-06-17 13:29:08 DEBUG shibtarget.Listener [12] sessionNew: new  
session id: _e388743ad71df49988c9339c176f4749
2009-06-17 13:29:08 DEBUG shibtarget.Listener [13] sessionGet:  
checking for session: _e388743ad71df49988c9339c176f4749@128.174.84.43
2009-06-17 13:29:08 DEBUG shibtarget.Listener [13] sessionGet:  
application: default
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [13] sessionGet:  
searching memory cache for key (_e388743ad71df49988c9339c176f4749)
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [13] sessionGet:  
Match found
2009-06-17 13:29:08 DEBUG shibtarget.Listener [13] sessionGet:  
Checking address against 128.174.84.43
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [13] sessionGet:  
testing session (ID: _e388743ad71df49988c9339c176f4749)  
(lifetime=7200, timeout=3600)
2009-06-17 13:29:08 DEBUG shibtarget.Listener [13] sessionGet:  
session ok
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [13] sessionGet:  
populating attributes for session (ID:  
_e388743ad71df49988c9339c176f4749)
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [13] sessionGet:  
trying to get new attributes for session  
(ID=_e388743ad71df49988c9339c176f4749)
2009-06-17 13:29:08 DEBUG SAML.SAMLSOAPHTTPBinding.CURLPool [13]  
sessionGet: getting connection handle to https://
shibboleth.cites.uiuc.edu:8443/shibboleth-idp/AA
2009-06-17 13:29:08 DEBUG SAML.SAMLSOAPHTTPBinding.CURLPool [13]  
sessionGet: nothing free in pool, returning new connection handle
2009-06-17 13:29:08 INFO SAML.SAMLSOAPHTTPBinding [13] sessionGet:  
sending SOAP message to https://shibboleth.cites.uiuc.edu:8443/ 
shibboleth-idp/AA
2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: About to  
connect() to shibboleth.cites.uiuc.edu port 8443 (#0)

2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet:   Trying  
128.174.86.250...
2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: connected

2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: Connected to  
shibboleth.cites.uiuc.edu (128.174.86.250) port 8443 (#0)

2009-06-17 13:29:08 DEBUG shibtarget.ShibHTTPHook [13] sessionGet:  
OpenSAML invoked SSL context callback
2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: SSLv3, TLS  
handshake, Client hello (1):

2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: SSLv3, TLS  
alert, Server hello (2):

2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: error:
14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: Closing  
connection #0

2009-06-17 13:29:08 ERROR SAML.SAMLSOAPHTTPBinding [13] sessionGet:  
failed while contacting SAML responder: error:14094410:SSL  
routines:SSL3_READ_BYTES:sslv3 alert handshake failure
2009-06-17 13:29:08 ERROR shibtarget.SessionCache [13] sessionGet:  
caught SAML exception during SAML attribute query:  
SOAPHTTPBindingProvider::send() failed while contacting SAML  
responder: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert  
handshake failure
2009-06-17 13:29:08 ERROR shibtarget.SessionCache [13] sessionGet: no  
response obtained
-------


On Jun 17, 2009, at 6:21 AM, Scott Cantor wrote:

Shibboleth Service Provider Security Advisory [15 June 2009]

Updated versions of the Shibboleth 1.3.x and 2.x Service Provider
software are now available which correct a security issue.
.......


--
Michael A. Grady
Executive Program Officer for Cyberinfrastructure
Office of the CIO, University of Illinois at Urbana-Champaign
2222 DCL, MC 256, 1304 W. Springfield Ave., Urbana, IL 61801
217.244.1253 phone, 217.244.4780 fax

Reply | Threaded
Open this post in threaded view
|

Re: SSL handshake error after updating to 1.3.2 - Re: Shibboleth Service Provider Security Advisory [15 June 2009]

Grady, Michael Allen
Probably should have added this is on a Windows 2003 SP2 server,  
running IIS 6.


On Jun 17, 2009, at 1:57 PM, Michael A. Grady wrote:

So we updated a Windows Shib SP that was at version 1.3.1 to 1.3.2  
using the postinstall zip file:
  http://shibboleth.internet2.edu/downloads/shibboleth/cppsp/1.3.2/ 
win32/shibboleth-sp-1.3.2-win32-postinstall.zip

following the instructions at:
  https://spaces.internet2.edu/display/SHIB2/NativeSPWindowsUpgrade

and then updating shibboleth.xml appropriately. And then trying to  
authenticate to an IdP we know our setup has been working with (the  
UIUC IdP). The authentication assertion is working fine, but when the  
SP goes to get an attribute assertion from the AA endpoint, we are  
getting an SSL handshake error (lines from the shibd.log on the SP  
follow). Any pointers as to what to look into/do to resolve this?

----
2009-06-17 13:29:08 DEBUG Shibboleth.ShibBrowserProfile [12]  
sessionNew: searching metadata for assertion issuer...
2009-06-17 13:29:08 DEBUG Shibboleth.ShibBrowserProfile [12]  
sessionNew: matched assertion issuer against metadata
2009-06-17 13:29:08 DEBUG Shibboleth.ShibBrowserProfile [12]  
sessionNew: passing signed response to trust layer
2009-06-17 13:29:08 DEBUG Shibboleth.Trust.Basic [12] sessionNew:  
validating signature with KeyDescriptors
2009-06-17 13:29:08 DEBUG Shibboleth.Trust.Basic [12] sessionNew:  
KeyDescriptor resolved into a key, trying it...
2009-06-17 13:29:08 DEBUG Shibboleth.Trust.Basic [12] sessionNew:  
signature verified with KeyDescriptor
2009-06-17 13:29:08 INFO Shibboleth.ShibBrowserProfile [12]  
sessionNew: verified digital signature over SSO response
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [12] sessionNew:  
caching new entry for application default:  
"_e388743ad71df49988c9339c176f4749"
2009-06-17 13:29:08 INFO shibtarget.SessionCache [12] sessionNew: new  
session created with session ID (_e388743ad71df49988c9339c176f4749)
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [12] sessionNew:  
NameID (_099e811c1561a73b42b2c967710ed23e), IdP  
(urn:mace:incommon:uiuc.edu), Address (128.174.84.43)
2009-06-17 13:29:08 DEBUG shibtarget.Listener [12] sessionNew: new  
session id: _e388743ad71df49988c9339c176f4749
2009-06-17 13:29:08 DEBUG shibtarget.Listener [13] sessionGet:  
checking for session: _e388743ad71df49988c9339c176f4749@128.174.84.43
2009-06-17 13:29:08 DEBUG shibtarget.Listener [13] sessionGet:  
application: default
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [13] sessionGet:  
searching memory cache for key (_e388743ad71df49988c9339c176f4749)
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [13] sessionGet:  
Match found
2009-06-17 13:29:08 DEBUG shibtarget.Listener [13] sessionGet:  
Checking address against 128.174.84.43
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [13] sessionGet:  
testing session (ID: _e388743ad71df49988c9339c176f4749)  
(lifetime=7200, timeout=3600)
2009-06-17 13:29:08 DEBUG shibtarget.Listener [13] sessionGet:  
session ok
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [13] sessionGet:  
populating attributes for session (ID:  
_e388743ad71df49988c9339c176f4749)
2009-06-17 13:29:08 DEBUG shibtarget.SessionCache [13] sessionGet:  
trying to get new attributes for session  
(ID=_e388743ad71df49988c9339c176f4749)
2009-06-17 13:29:08 DEBUG SAML.SAMLSOAPHTTPBinding.CURLPool [13]  
sessionGet: getting connection handle to https://
shibboleth.cites.uiuc.edu:8443/shibboleth-idp/AA
2009-06-17 13:29:08 DEBUG SAML.SAMLSOAPHTTPBinding.CURLPool [13]  
sessionGet: nothing free in pool, returning new connection handle
2009-06-17 13:29:08 INFO SAML.SAMLSOAPHTTPBinding [13] sessionGet:  
sending SOAP message to https://shibboleth.cites.uiuc.edu:8443/ 
shibboleth-idp/AA
2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: About to  
connect() to shibboleth.cites.uiuc.edu port 8443 (#0)

2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet:   Trying  
128.174.86.250...
2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: connected

2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: Connected to  
shibboleth.cites.uiuc.edu (128.174.86.250) port 8443 (#0)

2009-06-17 13:29:08 DEBUG shibtarget.ShibHTTPHook [13] sessionGet:  
OpenSAML invoked SSL context callback
2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: SSLv3, TLS  
handshake, Client hello (1):

2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: SSLv3, TLS  
alert, Server hello (2):

2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: error:
14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

2009-06-17 13:29:08 DEBUG SAML.libcurl [13] sessionGet: Closing  
connection #0

2009-06-17 13:29:08 ERROR SAML.SAMLSOAPHTTPBinding [13] sessionGet:  
failed while contacting SAML responder: error:14094410:SSL  
routines:SSL3_READ_BYTES:sslv3 alert handshake failure
2009-06-17 13:29:08 ERROR shibtarget.SessionCache [13] sessionGet:  
caught SAML exception during SAML attribute query:  
SOAPHTTPBindingProvider::send() failed while contacting SAML  
responder: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert  
handshake failure
2009-06-17 13:29:08 ERROR shibtarget.SessionCache [13] sessionGet: no  
response obtained
-------


On Jun 17, 2009, at 6:21 AM, Scott Cantor wrote:

Shibboleth Service Provider Security Advisory [15 June 2009]

Updated versions of the Shibboleth 1.3.x and 2.x Service Provider
software are now available which correct a security issue.
.......


--
Michael A. Grady
Executive Program Officer for Cyberinfrastructure
Office of the CIO, University of Illinois at Urbana-Champaign
2222 DCL, MC 256, 1304 W. Springfield Ave., Urbana, IL 61801
217.244.1253 phone, 217.244.4780 fax


--
Michael A. Grady
Executive Program Officer for Cyberinfrastructure
Office of the CIO, University of Illinois at Urbana-Champaign
2222 DCL, MC 256, 1304 W. Springfield Ave., Urbana, IL 61801
217.244.1253 phone, 217.244.4780 fax

Reply | Threaded
Open this post in threaded view
|

RE: SSL handshake error after updating to 1.3.2 - Re: Shibboleth Service Provider Security Advisory [15 June 2009]

Cantor, Scott E.
Michael A. Grady wrote on 2009-06-17:
> and then updating shibboleth.xml appropriately. And then trying to
> authenticate to an IdP we know our setup has been working with (the
> UIUC IdP). The authentication assertion is working fine, but when the
> SP goes to get an attribute assertion from the AA endpoint, we are
> getting an SSL handshake error (lines from the shibd.log on the SP
> follow). Any pointers as to what to look into/do to resolve this?

Same as I told Max in the other thread, I don't really control what libcurl
does beyond a few settings. In most cases, the first thing to do is nail
down that it's in fact an openssl or libcurl issue, by using s_client and
curl directly with the same keypair to try and open a connection, the goal
being to get through and have the IdP complain about the invalid message to
the AA, or to reproduce the same handshake failure.

Presumably, the latest libcurl and openssl combo, which of course is what I
packaged into the SP, is breaking here.

The only known handshake issue I'm aware of recently involves recent openssl
builds that use TLS extensions. That seems to break with some servers, and
the curl author disabled that feature in openssl by default, so I didn't
need to.

See here:

http://n2.nabble.com/OpenSSL-0.9.8j-and-Tomcat-td2272756.html

The error messages don't match yours, FWIW.

I have that code fix in the new SP, but I didn't patch the old one. I
probably should have, but with the Windows build I control the versions, and
I used a new enough libcurl so this shouldn't be the problem anyway.

So that leaves, again, reproducing it with the underlying libraries. I can
set options to work around issues, but I don't have any say in the actual
TLS connection code directly. Obviously I tested the newest code I built, in
my case against a Red Hat 5 Apache server. What's the server end here?

Obviously the only real work-around is to push the attributes. If there are
additional reports of TLS problems, I'll be actively digging, obviously.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: SSL handshake error after updating to 1.3.2 - Re: Shibboleth Service Provider Security Advisory [15 June 2009]

Cantor, Scott E.
In reply to this post by Grady, Michael Allen
Hey Mike,

C:\opt\shibboleth-sp\bin\debug>curl -3 -ki --key
..\..\etc\shibboleth\sp-key.pem
 --cert ..\..\etc\shibboleth\sp-cert.pem
https://shibboleth.cites.uiuc.edu:8443/
shibboleth-idp/AA
curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure

When I ran the same command with -1 or no option, it worked.

In other words, the trigger is the explicit selection of SSLv3 in the
command, and that matches part of the symptom I saw with the TLS extensions
problem. Not exactly but similar.

The new SP no longer explicitly selects SSLv3. I leave that defaulted and
libcurl now disables SSLv2 for me. I didn't backport that change. The new SP
also includes a low-level feature to allow altering detailed libcurl
settings at runtime (search wiki for TransportOption).

My suggestion, like it or not, is to test 2.2 with that IdP and if it works
like I suspect it will, that's pretty much my answer. I guess if this is a
major issue, my other option is a patch. I don't know whether I can get the
old code working close enough to the new to make this work, but it's not
impossible. Before I'd try, I would want some proof the new one actually
does work.

-- Scott