[
https://issues.apache.org/jira/browse/CAMEL-25369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-25369 started by Andrea Cosentino.
------------------------------------------------
> camel-spiffe - the SpiffeSecurityPolicy doc example denies every request, and
> the policy has no negative tests
> --------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25369
> URL: https://issues.apache.org/jira/browse/CAMEL-25369
> Project: Camel
> Issue Type: Bug
> Components: camel-spiffe
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Minor
>
> Follow-up to CAMEL-24735 (#27385), from davsclaus's review. The code is
> correct; the documentation that ships with it is not. Worth fixing before
> 4.23.0 goes out, so no user ever meets it.
> h2. The shipped example cannot work
> {{spiffe-component.adoc}} documents the policy like this:
> {code:java}
> from("netty-http:https://0.0.0.0:8443?sslContextParameters=#spiffeSsl";)
> .policy(spiffePolicy)
> .to("direct:handleOrder");
> {code}
> There is no client-authentication setting.
> {{SSLContextServerParameters.clientAuthentication}} defaults to {{null}}, so
> the JSSE default applies and the server never *requests* a client
> certificate. {{SSLSession.getPeerCertificates()}} then throws
> {{SSLPeerUnverifiedException}}, {{SpiffePeerIdentity}} returns null, and the
> policy denies - correctly, failing closed. The documented route therefore
> rejects **every** request, and the only signal is the authorization failure.
> The example needs {{clientAuthentication=REQUIRE}} on the server
> {{SpiffeSSLContextParameters}}.
> h2. Two more things the docs should say
> * *The server must use {{SpiffeSSLContextParameters}}*, not a plain
> truststore. A truststore that happens to trust the SPIFFE CA accepts any
> SPIFFE SAN issued by it, which is a different and weaker check than the one
> the policy's allow-list implies.
> * *Only camel-netty and camel-netty-http put the {{SSLSession}} on the
> message today.* Behind platform-http, jetty, undertow or servlet there is no
> {{CamelNettySSLSession}} header, so the policy fails closed and denies
> everything. A reader seeing a generic {{AuthorizationPolicy}} will reasonably
> assume it works with any HTTP consumer.
> h2. Negative tests
> The 13 tests from CAMEL-24735 cover the allow and deny paths, but not the
> attack-shaped inputs:
> * a {{String}}-valued {{CamelNettySSLSession}} header - a sender trying to
> spoof the session object; must be ignored and denied;
> * near-miss ids: {{spiffe://example.org.evil/frontend}} and
> {{spiffe://example.org/frontend/x}} against an allow-list of
> {{spiffe://example.org/frontend}};
> * a malformed {{spiffe://}} URI SAN;
> * a leaf certificate that is not an X509Certificate.
> h2. Not doing
> davsclaus also asked whether {{sslSessionHeader}} should be required to start
> with {{Camel}}. It should not: an {{SSLSession}} is a Java object, so it
> cannot be injected through an HTTP string header, and the spoof test above is
> what demonstrates that. Worth recording in the PR rather than implementing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
