validation when key does not have keyinformation

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

validation when key does not have keyinformation

Law, Bob

I am encountering an IdP that doesn’t have embedded key information in the UK Federation Metadata.  This is causing a signature validation error.  Is there any way to cause it to bypass the signature validation?  I know that this is a possible terrible security hole, but is there a way?

 

 Robert Law
Software Engineer
Wolters Kluwer Health Medical Research

Lippincott, Williams & Wilkins
Ovid Technologies
9350 South 150 East, Suite 200
Sandy, UT 84070-2702

801.304.3327 tel
801.819.2592 cell

[hidden email]
www.ovid.com

 

 

 

 

Confidentiality Notice: This email and its attachments (if any) contain confidential information of the sender. The information is intended only for the use by the direct addressees of the original sender of this email. If you are not an intended recipient of the original sender (or responsible for delivering the message to such person), you are hereby notified that any review, disclosure, copying, distribution or the taking of any action in reliance of the contents of and attachments to this email is strictly prohibited. If you have received this email in error, please immediately notify the sender at the address shown herein and permanently delete any copies of this email (digital or paper) in your possession.

 

Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Cantor, Scott E.
Law, Robert wrote on 2009-06-17:
> I am encountering an IdP that doesn't have embedded key information in the
> UK Federation Metadata.  This is causing a signature validation error.

What's causing the error is the failure of the trust engines used. If
there's no key there, either there's a KeyName, or it's using the entityID
as a key name, and it's evaluating the certificate based on rudimentary PKIX
against the KeyAuthority CAs in the metadata and against the key name(s).

> Is there any way to cause it to bypass the signature validation?  I know
that
> this is a possible terrible security hole, but is there a way?

https://spaces.internet2.edu/display/SHIB2/NativeSPPolicyRule#NativeSPPolicy
Rule-NullSecurityRule

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Law, Bob
My security policies are this:

    <SecurityPolicies>
        <Policy id="default" validate="false">
            <Rule type="MessageFlow" checkReplay="true" expires="60"/>
            <Rule type="ClientCertAuth" errorFatal="false"/>
            <Rule type="XMLSigning" errorFatal="false"/>
        </Policy>
    </SecurityPolicies>


But I get the following messages.  There is a KeyName in the metadata,
just no embedded key.

2009-06-17 13:01:45 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [1]:
validating signature profile
2009-06-17 13:01:45 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]:
attempting to validate signature with the peer's credentials
2009-06-17 13:01:45 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]: public
key did not validate signature: Credential did not contain a
verification
 key.
2009-06-17 13:01:45 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]: no
peer credentials validated the signature
2009-06-17 13:01:45 ERROR OpenSAML.SecurityPolicyRule.XMLSigning [1]:
unable to verify message signature with supplied trust engine
2009-06-17 13:01:45 DEBUG Shibboleth.SSO.SAML1 [1]: processing message
against SAML 1.x SSO profile

These were after I set the XMLSigning and ClientCertAuth to false.
Other than forcing IdPs to put they key information in the metadata,
what can I do.  Their key in the metadata is:

<shibmeta:Scope xmlns:shibmeta="urn:mace:shibboleth:metadata:1.0"
regexp="false">cardiff.ac.uk</shibmeta:Scope>

Robert Law
Software Engineer
Wolters Kluwer Health Medical Research
801.304.3327 tel
[hidden email]
www.ovid.com

-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Wednesday, June 17, 2009 11:44 AM
To: [hidden email]
Subject: RE: [Shib-Users] validation when key does not have
keyinformation

Law, Robert wrote on 2009-06-17:
> I am encountering an IdP that doesn't have embedded key information in
the
> UK Federation Metadata.  This is causing a signature validation error.

What's causing the error is the failure of the trust engines used. If
there's no key there, either there's a KeyName, or it's using the
entityID
as a key name, and it's evaluating the certificate based on rudimentary
PKIX
against the KeyAuthority CAs in the metadata and against the key
name(s).

> Is there any way to cause it to bypass the signature validation?  I
know
that
> this is a possible terrible security hole, but is there a way?

https://spaces.internet2.edu/display/SHIB2/NativeSPPolicyRule#NativeSPPo
licy
Rule-NullSecurityRule

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Cantor, Scott E.
Law, Robert wrote on 2009-06-17:
> My security policies are this:

Why do you appear to be running with just one TrustEngine? Did you change
the default TrustEngine chain for some reason?

> 2009-06-17 13:01:45 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]: no
> peer credentials validated the signature
> 2009-06-17 13:01:45 ERROR OpenSAML.SecurityPolicyRule.XMLSigning [1]:
> unable to verify message signature with supplied trust engine

That means the PKIX engine isn't running, which I think means you had to
have turned it off.

>  Their key in the metadata is:

No, it isn't. That's a Scope, not a KeyDescriptor.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Law, Bob
I don't even know that I have a PKIX engine running.  It is not in
shibboleth2.xml.  I just set the security policy to

    <SecurityPolicies>
        <Policy id="default" validate="false">
            <Rule type="MessageFlow" checkReplay="false" expires="60"/>
            <Rule type="ClientCertAuth" errorFatal="false"/>
            <Rule type="XMLSigning" errorFatal="false"/>
            <Rule type="NullSecurity"/>
        </Policy>

    </SecurityPolicies>

And it went ahead and went to the final desitination, however, the soap
validation still failed.

2009-06-18 10:08:09 DEBUG XMLTooling.SOAPTransport.CURL [1]: sending
SOAP message to https://idp.cf.ac.uk:8443/shibboleth-idp/AA
2009-06-18 10:08:10 DEBUG XMLTooling.SOAPTransport.CURL [1]: invoking
custom X.509 verify callback
2009-06-18 10:08:10 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]:
attempting to match credentials from peer with end-entity certificate
2009-06-18 10:08:10 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]: no
keys within this peer's key information matched the given end-entity
certificate
2009-06-18 10:08:10 ERROR XMLTooling.SOAPTransport.CURL [1]: supplied
TrustEngine failed to validate SSL/TLS server certificate
2009-06-18 10:08:10 ERROR Shibboleth.AttributeResolver.Query [1]:
exception during SAML query to
https://idp.cf.ac.uk:8443/shibboleth-idp/AA: CURLSOAPTransport failed
 while contacting SOAP responder: SSL certificate problem, verify that
the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
2009-06-18 10:08:10 ERROR Shibboleth.AttributeResolver.Query [1]: unable
to obtain a SAML response from attribute authority

It went ahead and started the session, I suspect due to the
NullSecurity.  What I want is for it to accept and process the soap
message without the security check since the metadata doesn't have the
keyinfo.

I put in the TrustEngine

        <TrustEngine type="Chaining">
            <TrustEngine type="ExplicitKey"/>
            <TrustEngine type="PKIX"/>
        </TrustEngine>

Which for some reason I don't have in my shibboleth2.xml file.  Can you
think of anything else or will this solve my problem?

Robert Law
Software Engineer
Wolters Kluwer Health Medical Research
801.304.3327 tel
[hidden email]
www.ovid.com
-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Wednesday, June 17, 2009 7:23 PM
To: [hidden email]
Subject: RE: [Shib-Users] validation when key does not have
keyinformation

Law, Robert wrote on 2009-06-17:
> My security policies are this:

Why do you appear to be running with just one TrustEngine? Did you
change
the default TrustEngine chain for some reason?

> 2009-06-17 13:01:45 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]: no
> peer credentials validated the signature
> 2009-06-17 13:01:45 ERROR OpenSAML.SecurityPolicyRule.XMLSigning [1]:
> unable to verify message signature with supplied trust engine

That means the PKIX engine isn't running, which I think means you had to
have turned it off.

>  Their key in the metadata is:

No, it isn't. That's a Scope, not a KeyDescriptor.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Law, Bob
In reply to this post by Cantor, Scott E.
After removing the verify key trust engine and replacing it with PKIX, I
am getting transferred to the destination, but I'm still having problems
with the soap messages.  Here is the appropriate portion of my log.

2009-06-18 10:25:19 DEBUG XMLTooling.SOAPTransport.CURL [1]: sending
SOAP message to https://idp.cf.ac.uk:8443/shibboleth-idp/AA
2009-06-18 10:25:19 DEBUG XMLTooling.SOAPTransport.CURL [1]: invoking
custom X.509 verify callback
2009-06-18 10:25:19 DEBUG XMLTooling.TrustEngine.PKIX [1]: performing
certificate path validation...
2009-06-18 10:25:19 DEBUG XMLTooling.TrustEngine [1]: building CA list
from PKIX Validation information
2009-06-18 10:25:19 DEBUG XMLTooling.TrustEngine [1]: successfully
validated certificate chain
2009-06-18 10:25:19 ERROR Shibboleth.AttributeResolver.Query [1]:
exception during SAML query to
https://idp.cf.ac.uk:8443/shibboleth-idp/AA: CURLSOAPTransport failed
 while contacting SOAP responder: error:1409D08A:SSL
routines:SSL3_SETUP_KEY_BLOCK:cipher or hash unavailable
2009-06-18 10:25:19 ERROR Shibboleth.AttributeResolver.Query [1]: unable
to obtain a SAML response from attribute authority
2009-06-18 10:25:19 DEBUG Shibboleth.SessionCache [1]: creating new
session
2009-06-18 10:25:19 DEBUG Shibboleth.SessionCache [1]: storing new
session...

Logging in as an IdP with a valid signature still works.

Robert Law
Software Engineer
Wolters Kluwer Health Medical Research
801.304.3327 tel
[hidden email]
www.ovid.com

-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Wednesday, June 17, 2009 7:23 PM
To: [hidden email]
Subject: RE: [Shib-Users] validation when key does not have
keyinformation

Law, Robert wrote on 2009-06-17:
> My security policies are this:

Why do you appear to be running with just one TrustEngine? Did you
change
the default TrustEngine chain for some reason?

> 2009-06-17 13:01:45 DEBUG XMLTooling.TrustEngine.ExplicitKey [1]: no
> peer credentials validated the signature
> 2009-06-17 13:01:45 ERROR OpenSAML.SecurityPolicyRule.XMLSigning [1]:
> unable to verify message signature with supplied trust engine

That means the PKIX engine isn't running, which I think means you had to
have turned it off.

>  Their key in the metadata is:

No, it isn't. That's a Scope, not a KeyDescriptor.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Cantor, Scott E.
In reply to this post by Law, Bob
Law, Robert wrote on 2009-06-18:
> I don't even know that I have a PKIX engine running.  It is not in
> shibboleth2.xml.

Then you or somebody else had to have removed it.

> And it went ahead and went to the final desitination, however, the soap
> validation still failed.

You're right, I forgot that the SSL connection is handled separately. I'd
have to think about it, I don't know if there's any way to override that
easily right now. The debugging support was primarily for front channel
support of SAML 2.

Your better option is to use the trust engine setup you should be using and
then if it still fails, report that to the federation or the IdPs.

But once PKIX is running, the log should change and more information will be
available about the problem.

> It went ahead and started the session, I suspect due to the
> NullSecurity.  What I want is for it to accept and process the soap
> message without the security check since the metadata doesn't have the
> keyinfo.

Again, the metadata normally has to have a KeyDescriptor, but not a key. It
does NOT have to have a key for this to work.

> I put in the TrustEngine

That's definitely necessary.

> Which for some reason I don't have in my shibboleth2.xml file.  Can you
> think of anything else or will this solve my problem?

No, I don't recall offhand if it's possible to force it to accept an invalid
SSL certificate. It probably is, but it's not coming to mind.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Cantor, Scott E.
In reply to this post by Law, Bob
Law, Robert wrote on 2009-06-18:
> After removing the verify key trust engine and replacing it with PKIX, I
> am getting transferred to the destination, but I'm still having problems
> with the soap messages.  Here is the appropriate portion of my log.

You need both. Just use the default configuration.

> 2009-06-18 10:25:19 DEBUG XMLTooling.TrustEngine [1]: successfully
> validated certificate chain

That means it's happy certificate-wise. The rest is something entirely
unrelated.

> 2009-06-18 10:25:19 ERROR Shibboleth.AttributeResolver.Query [1]:
> exception during SAML query to
> https://idp.cf.ac.uk:8443/shibboleth-idp/AA: CURLSOAPTransport failed
>  while contacting SOAP responder: error:1409D08A:SSL
> routines:SSL3_SETUP_KEY_BLOCK:cipher or hash unavailable

I would have to conclude the IdP is set up in some very unusual fashion and
isn't supporting a compatible encryption type. I've never seen that error
come up.

Does this IdP work for anybody/anything else?

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Law, Bob
Yes it works under shibboleth 1.3.  It has to be something in the way
that Shibboleth 2 is working.

Robert Law
Software Engineer
Wolters Kluwer Health Medical Research
801.304.3327 tel
[hidden email]
www.ovid.com

-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Thursday, June 18, 2009 9:41 AM
To: [hidden email]
Subject: RE: [Shib-Users] validation when key does not have
keyinformation

Law, Robert wrote on 2009-06-18:
> After removing the verify key trust engine and replacing it with PKIX,
I
> am getting transferred to the destination, but I'm still having
problems
> with the soap messages.  Here is the appropriate portion of my log.

You need both. Just use the default configuration.

> 2009-06-18 10:25:19 DEBUG XMLTooling.TrustEngine [1]: successfully
> validated certificate chain

That means it's happy certificate-wise. The rest is something entirely
unrelated.

> 2009-06-18 10:25:19 ERROR Shibboleth.AttributeResolver.Query [1]:
> exception during SAML query to
> https://idp.cf.ac.uk:8443/shibboleth-idp/AA: CURLSOAPTransport failed
>  while contacting SOAP responder: error:1409D08A:SSL
> routines:SSL3_SETUP_KEY_BLOCK:cipher or hash unavailable

I would have to conclude the IdP is set up in some very unusual fashion
and
isn't supporting a compatible encryption type. I've never seen that
error
come up.

Does this IdP work for anybody/anything else?

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Jim Fox
In reply to this post by Cantor, Scott E.

>
>> 2009-06-18 10:25:19 ERROR Shibboleth.AttributeResolver.Query [1]:
>> exception during SAML query to
>> https://idp.cf.ac.uk:8443/shibboleth-idp/AA: CURLSOAPTransport failed
>>  while contacting SOAP responder: error:1409D08A:SSL
>> routines:SSL3_SETUP_KEY_BLOCK:cipher or hash unavailable
>
> I would have to conclude the IdP is set up in some very unusual fashion and
> isn't supporting a compatible encryption type. I've never seen that error
> come up.
>

I'd guess it is a build issue with the SP.  Maybe a curl or openssl
library is linking wrong or is old and buggy.

Jim
Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Law, Bob
I'm using curl 7.18.2 and openssl 0.9.7l.  This all works with an IdP
that has the key information in the federation metadata.  Cardiff has a
key entry but not the signature in the metadata.  This combination works
with shibboleth 1.3, just not shibboleth 2.1.

Robert Law
Software Engineer
Wolters Kluwer Health Medical Research
801.304.3327 tel
[hidden email]
www.ovid.com

-----Original Message-----
From: Jim Fox [mailto:[hidden email]]
Sent: Thursday, June 18, 2009 10:09 AM
To: [hidden email]
Subject: RE: [Shib-Users] validation when key does not have
keyinformation


>
>> 2009-06-18 10:25:19 ERROR Shibboleth.AttributeResolver.Query [1]:
>> exception during SAML query to
>> https://idp.cf.ac.uk:8443/shibboleth-idp/AA: CURLSOAPTransport failed
>>  while contacting SOAP responder: error:1409D08A:SSL
>> routines:SSL3_SETUP_KEY_BLOCK:cipher or hash unavailable
>
> I would have to conclude the IdP is set up in some very unusual
fashion and
> isn't supporting a compatible encryption type. I've never seen that
error
> come up.
>

I'd guess it is a build issue with the SP.  Maybe a curl or openssl
library is linking wrong or is old and buggy.

Jim
Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Cantor, Scott E.
Law, Robert wrote on 2009-06-18:
> I'm using curl 7.18.2 and openssl 0.9.7l.  This all works with an IdP
> that has the key information in the federation metadata.  Cardiff has a
> key entry but not the signature in the metadata.

That is NOT involved.

> This combination works with shibboleth 1.3, just not shibboleth 2.1.

With the same library versions?

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Cantor, Scott E.
In reply to this post by Law, Bob
Law, Robert wrote on 2009-06-18:
> Yes it works under shibboleth 1.3.  It has to be something in the way
> that Shibboleth 2 is working.

The cipher suites set in the curl client are the same in the two versions.
Unless the error is misleading in some way, there's no reason why 2.x would
behave differently, so I guess the error message itself is suspect. That
obviously makes it difficult to diagnose.

Obviously library versions can be involved, but this is the first case of it
involving such an error message. Handshakes failing, yes, but not cipher
suites.

I would add that right now, the operative condition seems to be that the
*old* SP code is causing interop issues with some SSL servers, which is the
opposite of this case.

I really don't know what to tell you, other than to emphasize that this has
nothing to do with metadata or anything trust-related. Your problem there
was self-inflicted, the removal of the standard trust engines. This is a
lower layer issue in the SSL code I rely on.

It would be helpful to determine if any installation of the 2.2 SP can
negotiate a connection to that IdP. Maybe the Windows version, which is
pre-built.

-- Scott


Reply | Threaded
Open this post in threaded view
|

Re: validation when key does not have keyinformation

Cantor, Scott E.
In reply to this post by Law, Bob
Law, Robert wrote on 2009-06-18:
> I'm using curl 7.18.2 and openssl 0.9.7l.  This all works with an IdP
> that has the key information in the federation metadata.  Cardiff has a
> key entry but not the signature in the metadata.  This combination works
> with shibboleth 1.3, just not shibboleth 2.1.

Just FYI, I had a chance to do some testing against that SSL server with my
builds and was not able to reproduce that particular SSL error. I did
identify an issue apparently identical to the one Mike Grady ran into, that
indicates a patch will probably be needed to the 1.3.2 code, but the 2.2
code should work as is.

I believe that your issue (now that the trust engine correction was made)
reflects a problem specific to the versions of curl and/or openssl you're
building on, and would have to suggest moving either forward or back there.

I may have missed what you're building on, so I don't know how feasible that
is. All I can suggest is to try 2.2 with the newest openssl/libcurl and see
what happens. My own testing with that combination appears to handshake with
that server.

The only reason I can give for 1.3.1 working is if its sitting on older
openssl or libcurl code. Sadly, the newer stuff is causing problems, and the
reason the newest code works is that curl and the latest SP have code that
works in concert to work around some of the problems openssl seems to be
creating.

-- Scott



Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Law, Bob
I have tried an openssl connect command manually, and among a lot of
other things I am getting this error:

CONNECTED(00000004)
depth=2 /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE
CyberTrust Global Root
verify error:num=19:self signed certificate in certificate chain
verify return:0

Is that error 19, something that Shibboleth 2.1 would have a problem
with when doing back channel communication?  Is there a way to allow
self signed certificates from a client (IdP)?

Robert Law
Software Engineer
Wolters Kluwer Health Medical Research
801.304.3327 tel
[hidden email]
www.ovid.com

-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Thursday, June 18, 2009 9:36 PM
To: [hidden email]
Subject: Re: [Shib-Users] validation when key does not have
keyinformation

Law, Robert wrote on 2009-06-18:
> I'm using curl 7.18.2 and openssl 0.9.7l.  This all works with an IdP
> that has the key information in the federation metadata.  Cardiff has
a
> key entry but not the signature in the metadata.  This combination
works
> with shibboleth 1.3, just not shibboleth 2.1.

Just FYI, I had a chance to do some testing against that SSL server with
my
builds and was not able to reproduce that particular SSL error. I did
identify an issue apparently identical to the one Mike Grady ran into,
that
indicates a patch will probably be needed to the 1.3.2 code, but the 2.2
code should work as is.

I believe that your issue (now that the trust engine correction was
made)
reflects a problem specific to the versions of curl and/or openssl
you're
building on, and would have to suggest moving either forward or back
there.

I may have missed what you're building on, so I don't know how feasible
that
is. All I can suggest is to try 2.2 with the newest openssl/libcurl and
see
what happens. My own testing with that combination appears to handshake
with
that server.

The only reason I can give for 1.3.1 working is if its sitting on older
openssl or libcurl code. Sadly, the newer stuff is causing problems, and
the
reason the newest code works is that curl and the latest SP have code
that
works in concert to work around some of the problems openssl seems to be
creating.

-- Scott



Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Cantor, Scott E.
Law, Robert wrote on 2009-06-22:
> I have tried an openssl connect command manually, and among a lot of
> other things I am getting this error:

You'll get an error like that no matter what unless the certificate just
happens to be chained to a root in the trust list. It doesn't have any
meaning here.

> Is that error 19, something that Shibboleth 2.1 would have a problem
> with when doing back channel communication?  Is there a way to allow
> self signed certificates from a client (IdP)?

Yes, that has nothing to do with the other error.
 
-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Law, Bob
In reply to this post by Cantor, Scott E.
Is there any reason why, if my curl and openssl are messed up, that I
would be able to communicate with one IdP, but not the other?  This
would seem to indicate to me that the problem is with the second IdP.
However since 1.3 works with both, I have to wonder about Shibboleth
2.1.  I know that the sponsor for this project is getting very nervous
and about ready to toss it and probably me along with it.

Robert Law
Software Engineer
Wolters Kluwer Health Medical Research
801.304.3327 tel
[hidden email]
www.ovid.com

-----Original Message-----
From: Scott Cantor [mailto:[hidden email]]
Sent: Thursday, June 18, 2009 9:36 PM
To: [hidden email]
Subject: Re: [Shib-Users] validation when key does not have
keyinformation

Law, Robert wrote on 2009-06-18:
> I'm using curl 7.18.2 and openssl 0.9.7l.  This all works with an IdP
> that has the key information in the federation metadata.  Cardiff has
a
> key entry but not the signature in the metadata.  This combination
works
> with shibboleth 1.3, just not shibboleth 2.1.

Just FYI, I had a chance to do some testing against that SSL server with
my
builds and was not able to reproduce that particular SSL error. I did
identify an issue apparently identical to the one Mike Grady ran into,
that
indicates a patch will probably be needed to the 1.3.2 code, but the 2.2
code should work as is.

I believe that your issue (now that the trust engine correction was
made)
reflects a problem specific to the versions of curl and/or openssl
you're
building on, and would have to suggest moving either forward or back
there.

I may have missed what you're building on, so I don't know how feasible
that
is. All I can suggest is to try 2.2 with the newest openssl/libcurl and
see
what happens. My own testing with that combination appears to handshake
with
that server.

The only reason I can give for 1.3.1 working is if its sitting on older
openssl or libcurl code. Sadly, the newer stuff is causing problems, and
the
reason the newest code works is that curl and the latest SP have code
that
works in concert to work around some of the problems openssl seems to be
creating.

-- Scott



Reply | Threaded
Open this post in threaded view
|

RE: validation when key does not have keyinformation

Cantor, Scott E.
Law, Robert wrote on 2009-06-22:
> Is there any reason why, if my curl and openssl are messed up, that I
> would be able to communicate with one IdP, but not the other?

Yes, that's the nature of openssl interop issues. It's likely to depend on
the SSL implementation at the other end.

> This would seem to indicate to me that the problem is with the second IdP.

In a sense, but the "problem" is that there are bugs in OpenSSL, and I can't
fix those (or even identify them in most cases, I'm not a TLS engineer). I
can work around them to some degree, but that work is basically done at this
point. Both releases are now as fixed as they're going to get.

Probably the quickest fix for you would be to build the new SP on top of the
*older* openssl/libcurl libraries that apparently work. That's a short term
fix, but eventually you have to be able to stay current because of security
issues in those libraries. But it might buy you some time.
 
> However since 1.3 works with both, I have to wonder about Shibboleth 2.1.

Well, 2.1 is now updated as of last week, and there *are* improvements to
those workarounds in 2.2, as there are in 1.3.2 at this point. But the
problems are due to the library versions underneath the SP, not the SP
itself.

The other interop problems that came up once 2.2 was released affected only
the 1.3 branch, for example. If you were running 1.3 on the same library set
that you're running 2.1 on, you would see the same error. I'd put money on
it.
 
> I know that the sponsor for this project is getting very nervous
> and about ready to toss it and probably me along with it.

I can only do what I can do. It took a bit of time to correct for the
configuration having been changed fatally by removing that TrustEngine. If
you saw *anything* that suggested you to do that, I need to know about it.
At that point, I was expecting the problem to be fixed, and in any normal
situation it would have been. I don't know what's happening now, but it has
nothing to do with the certificates at all at this point.

I can only conclude that the message means what it says, that the cipher
suites don't match. But I was able to connect to that IdP using the latest
code without any special workaround, so my advice remains the same, get to
the latest code and then see what happens. Alternatively, you can try with
the older libraries.

-- Scott