Andrea Cosentino created CAMEL-25650:
----------------------------------------
Summary: camel-core - support endpointIdentificationAlgorithm in
SSLContextClientParameters
Key: CAMEL-25650
URL: https://issues.apache.org/jira/browse/CAMEL-25650
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Andrea Cosentino
h3. Summary
The JSSE Configuration Utility has no way to ask for host name verification.
{{SSLContextClientParameters}} and {{BaseSSLContextParameters}} configure
cipher suites, secure socket protocols, named groups, signature schemes and SNI
server names, but nothing in {{org.apache.camel.support.jsse}} ever touches
{{SSLParameters.setEndpointIdentificationAlgorithm}}.
So an operator who configures TLS the documented Camel way, through
{{sslContextParameters}}, cannot ask for the server's certificate to be checked
against the host being connected to. Each component has to remember to do it on
its own socket or engine, with its own option name - and when a component
forgets, there is no way to compensate from configuration.
h3. Why this keeps costing us
Every one of these was the same omission in a different component, found
separately:
* CAMEL-25604 ({{camel-mllp}}) and CAMEL-25605 ({{camel-mina}}) - no
verification, no option at all.
* CAMEL-25622 ({{camel-smpp}}) - same, and no {{SSLContextParameters}} support
either (CAMEL-25643).
* CAMEL-25649 ({{camel-netty}}) - an option exists but could never work.
* CAMEL-20812 ({{camel-netty-http}}) - the option existed and was not wired up.
* CAMEL-24379 ({{camel-as2}}) - a custom {{HostnameVerifier}} was bypassed
because verification happens at the JSSE level.
The components that get it right each hard-code the algorithm behind their own
flag ({{hostnameVerification}} in netty and netty-http, now also in mllp, mina
and smpp). Nothing makes a new component do the same, and a review has to
notice its absence.
h3. Proposal
Add an {{endpointIdentificationAlgorithm}} setting to
{{SSLContextClientParameters}}, applied to the {{SSLParameters}} that
{{BaseSSLContextParameters}} already decorates for client sockets and engines -
the same mechanism that applies cipher suites and SNI today.
Points for discussion:
* *Default.* Leaving it unset keeps today's behaviour and makes it opt-in,
which is safe but keeps the insecure default. Defaulting it to {{HTTPS}} would
make verification the default for every component that uses the utility - the
right default for a client, but a breaking change that needs an upgrade-guide
entry and sign-off. A middle option is to leave the default alone and have the
security policy framework (CAMEL-23250, {{camel.main.profile = prod}}) require
it, since an unverified TLS client fits {{insecure:ssl}}.
* *Interaction with the per-component flags.* The component option should keep
winning where it exists, so that routes which set {{hostnameVerification}}
today behave the same.
* *The peer has to be attached.* The algorithm alone is not enough: the JDK
matches against {{SSLSession.getPeerHost()}}, which is only set when the socket
or engine is created with the peer. CAMEL-25649 is exactly that trap. Whatever
the utility does, a component that creates an engine with the no-arg factory
method will still fail with "Hostname or IP address is undefined" - so this
needs a documented expectation for component authors, and ideally a note in the
committer review checklist in the security model.
Filed unassigned: the default is a project decision rather than a mechanical
change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
