[
https://issues.apache.org/jira/browse/CAMEL-25368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-25368 started by Andrea Cosentino.
------------------------------------------------
> camel-spiffe: the documented SpiffeSecurityPolicy example denies every request
> ------------------------------------------------------------------------------
>
> Key: CAMEL-25368
> URL: https://issues.apache.org/jira/browse/CAMEL-25368
> Project: Camel
> Issue Type: Bug
> Components: camel-spiffe
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.23.0
>
>
> The SpiffeSecurityPolicy section added in CAMEL-24735 ships an example that
> cannot work, and the surrounding text does not say where the policy is usable
> at all. Worth fixing before 4.23.0 ships, since a reader who copies the
> example gets a route that denies all traffic and no indication why.
> h3. The example never authorizes anything
> {code:java}
> from("netty-http:https://0.0.0.0:8443?sslContextParameters=#spiffeSsl";)
> .policy(spiffePolicy)
> .to("direct:handleOrder");
> {code}
> Nothing sets {{clientAuthentication}} on the server parameters. Traced
> through main:
> * {{SSLContextServerParameters.getSSLEngineConfigurers}} adds its client-auth
> configurer only {{if (this.getClientAuthentication() != null)}}, so an unset
> value installs no configurer at all - neither {{setNeedClientAuth}} nor
> {{setWantClientAuth}} is ever called, leaving the JSSE default of no client
> authentication.
> * {{SpiffeSSLContextParameters}} does not set it either; it only preserves
> whatever the parent's {{serverParameters.clientAuthentication}} says.
> * With no client certificate requested, {{SSLSession.getPeerCertificates()}}
> throws {{SSLPeerUnverifiedException}}, which {{SpiffePeerIdentity}} catches
> and turns into {{null}}.
> * {{null}} is the fail-closed path, so the policy denies - every request, for
> every peer.
> The docs must show {{clientAuthentication=REQUIRE}} on the server
> {{SSLContextServerParameters}}, and say that the server has to use
> {{SpiffeSSLContextParameters}} rather than a plain truststore: a plain
> truststore accepts any certificate chaining to the trust bundle, so the
> policy would be authorizing an identity nobody constrained.
> h3. The scope of the policy is not stated
> The identity comes from an {{SSLSession}} on the message, and
> {{NettyEndpoint.updateMessageHeader}} is the only place in the codebase that
> puts one there (gated on {{configuration.isSsl()}}). So the policy works with
> camel-netty and camel-netty-http and silently denies everything on
> platform-http, jetty, undertow and servlet. The servlet certificate fallback
> was dropped during the review of #27385, so there is no longer any non-netty
> path. That belongs in the docs rather than being discovered in production.
> h3. Negative tests
> The 13 tests that shipped cover the allow paths and the
> plainly-absent-identity denials. The denials that would actually be attacked
> are untested:
> * a String-valued {{CamelNettySSLSession}} header, i.e. a sender trying to
> pass an identity as text rather than an {{SSLSession}};
> * near-miss SPIFFE IDs against the allow-list -
> {{spiffe://example.org.evil/frontend}} and
> {{spiffe://example.org/frontend/x}} against an accepted
> {{spiffe://example.org/frontend}};
> * a malformed {{spiffe://}} URI SAN;
> * a leaf certificate that is not an X509Certificate.
> No behaviour change is proposed for the code itself - the first of those is
> also the answer to the review question of whether {{sslSessionHeader}} should
> be forced to start with {{Camel}}: it need not, because an {{SSLSession}} is
> a Java object and a String header is already rejected. The tests pin that
> rather than relying on the argument.
> Follow-up to CAMEL-24735.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
