[jira] [Created] (CAMEL-25368) camel-spiffe: the documented SpiffeSecurityPolicy example denies every request

["Andrea Cosentino (Jira)" <ji...@apache.org>]

Andrea Cosentino created CAMEL-25368:
----------------------------------------

             Summary: 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
             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)