[JIRA] Moved: (CPPOST-75) ChainingTrustEngine resets SOAP/TLS-based null peer entity name, forces TrustEngine name matching

[Scott Cantor (JIRA)]

     [ https://issues.shibboleth.net/jira/browse/CPPOST-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Cantor moved CPPXT-85 to CPPOST-75:
-----------------------------------------

          Component/s:     (was: Security)
                       Security
                       Metadata
        Fix Version/s:     (was: 1.5)
                       2.5
    Affects Version/s:     (was: 1.4.2)
                       2.4
                       2.4.1
                       2.4.2
                       2.4.3
                  Key: CPPOST-75  (was: CPPXT-85)
              Project: OpenSAML 2 - C++  (was: XMLTooling - C++)

> ChainingTrustEngine resets SOAP/TLS-based null peer entity name, forces TrustEngine name matching
> -------------------------------------------------------------------------------------------------
>
>                 Key: CPPOST-75
>                 URL: https://issues.shibboleth.net/jira/browse/CPPOST-75
>             Project: OpenSAML 2 - C++
>          Issue Type: Bug
>      Security Level: Standard(Standard bug, may impact functionality but does not represent a security vulnerability ) 
>          Components: Metadata, Security
>    Affects Versions: 2.4.3, 2.4.2, 2.4.1, 2.4
>         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: 2.5
>
>   Original Estimate: 4 hours
>          Time Spent: 45 minutes
>  Remaining Estimate: 0 minutes
>
> 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