[JIRA] Commented: (CPPXT-85) ChainingTrustEngine resets SOAP/TLS-based null peer entity name, forces TrustEngine name matching

[Scott Cantor (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/CPPXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13834#comment-13834 ] 

Scott Cantor commented on CPPXT-85:
-----------------------------------

Trying to rephrase what you're seeing: you want the libcurl layer to handle the name validation and skip that in the TrustEngine because your metadata contains neither the certificate itself nor even a KeyName for the host. Therefore, if the PKIX engine runs second, after the reset() call, the engine fails while verifying the name of the certificate because the only valid key name it's using as input to the check is the entityID of the peer. Is that about it?

I think you can work around this without changing the order of the engines by adding a KeyName to the metadata explicitly that contains the hostname that would be in the TLS cert. That probably isn't a better way since you'd have to change the metadata in that case, just like adding the certificate would require. But it would help me verify I understand the issue.

> ChainingTrustEngine resets SOAP/TLS-based null peer entity name, forces TrustEngine name matching
> -------------------------------------------------------------------------------------------------
>
>                 Key: CPPXT-85
>                 URL: https://issues.shibboleth.net/jira/browse/CPPXT-85
>             Project: XMLTooling - C++
>          Issue Type: Bug
>      Security Level: Standard(Standard bug, may impact functionality but does not represent a security vulnerability ) 
>          Components: Security
>    Affects Versions: 1.4.2
>         Environment: RHEL 5 64-bit, Shibboleth SP 2.4.3 with libxmltooling 1.4.2
>            Reporter: mthornton at idp.protectnetwork.org
>            Assignee: Scott Cantor
>              Labels: ChainingTrustEngine, PKIX, SOAP, TLS, TrustEngine
>             Fix For: 1.5
>
>
> CURLSOAPTransport->verify_callback explicitly calls TrustEngine's with a null PeerName in the criteria, to bypass name checking (as documented in comments).  If multiple TrustEngine's are configured, implicitly creating a ChainingTrustEngine, the second and later TrustEngine's will now contain a non-null PeerName ie the entityId of the peer to validate.  Suspect the m_criteria->reset() in the chaining loop introduces the problem.
> Observed with chaining ExplicitKey TrustEngine with StaticPKIX for back-channel single logout, was unable to get TLS name validation to occur, only PKIX validation, which did not consider the TLS destination hostname.  In our scenario, ExplicitKey is required for all front-channel SSO-related activities, required StaticPKIX only for TLS since the TLS server certificate/key is not included in the metadata.
> Workaround:  place ExplicitKey second in the chain, since ExplicitKey does not validate name information... This workaround may not take into consideration any other potential side-effects of the m_criteria->reset() other than name validation, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira