Andrea Cosentino created CAMEL-25369:
----------------------------------------
Summary: 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
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)
