[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=13836#comment-13836 ] 

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

HTTP over TLS has its own rules that have to be followed, and we believe it's counterproductive to try and impose a different set of rules for TLS than people ordinarily expect. While it would be somewhat attractive to do the more generic cert matching we do for signing, no other implementation will ever support that. At least with signing, there are no rules for what to do anyway, but we don't think deployers would appreciate being led to rely on TLS name matching that would only work with Shibboleth.

Cloning is probably the appropriate solution here, but I have to maintain backward API compatibility. I can add new methods, but adding virtual methods that a subclass would have to override isn't possible, and there's no other way to clone. So I'll have to come up with something else for now.

> 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