[JIRA] Resolved: (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:all-tabpanel ]

Scott Cantor resolved CPPXT-85.
-------------------------------

    Resolution: Fixed

http://svn.shibboleth.net/view/cpp-opensaml?rev=720&view=rev

This looks like a regression created in 2.4 that mistakenly resets the peer name property, even though the base class never actually clears it during reset anyway.

> 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: 2.4, 2.4.1, 2.4.2, 2.4.3
>         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