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

[mthornton@idp.protectnetwork.org (JIRA)]

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

mthornton at idp.protectnetwork.org commented on CPPXT-85:
-------------------------------------------------------

Yes, you've nailed it... and that seems to be the intent of the CURLSOAPTransport->verify_callback, based on inline comments: to skip TrustEngine name validation, deferring it to CURL by explicitly setting/leaving the PeerName to null.  As you've surmised, changing the metadata wouldn't be a preferred approach.

To be honest, the TrustEngine documentation suggests that all of this name validation occurs within the PKIX TrustEngine and that hostname is added to the list of trusted names for TLS, in addition to the entityId.  Implementation doesn't quite follow that, since it would ONLY support one or the other based on sequence of configuration, etc...  unless the entityId is fed into the libCurl name validation as an alternate trusted name (not even sure if that's possible).

Thinking out loud... would it be worth "cloning" the input m_criteria for input into each TrustEngine in the chaining to eliminate any cross-contamination?  Obviously, from an code/encapsulation perspective, I wouldn't expect input criteria to be changed by a TrustEngine, only read... but I'm sure that's a whole other discussion.

> 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
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> 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