[
https://issues.apache.org/jira/browse/CAMEL-26546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137257#comment-18137257
]
Andrea Cosentino commented on CAMEL-26546:
------------------------------------------
Scope note while implementing.
The three affected transports cannot apply named groups at all - Vert.x's
{{TCPSSLOptions}} has no such setting, Kafka builds its engine from flat
{{ssl.*}} properties, and {{TSSLTransportParameters}} carries protocol, cipher
suites and stores only. A shared *apply* helper would therefore not help any of
them; what they need is to stop dropping a configured value in silence.
This issue is fixed as:
* a shared {{JsseParametersHelper.engineOnlyParameters(SSLContextParameters)}}
in camel-api, naming the configured options a native TLS stack cannot carry;
* a warning from camel-kafka, camel-vertx-common (which covers
camel-platform-http-vertx, camel-vertx-http and camel-vertx-websocket) and the
camel-thrift producer when those options are configured;
* the documentation correction - the security guide claimed the preference
applies to *all* {{SSLContextParameters}}, and there was no per-transport
statement anywhere.
Two corrections to the description above, found while checking:
* camel-elasticsearch, camel-elasticsearch-rest-client and camel-solr are *not*
affected - they pass the decorated {{SSLContext}} through. Only the
{{createSslContextFromCa}} fallback path reads the parameters directly, and
that path has no {{SSLContextParameters}} to lose.
* In camel-thrift only the *producer* is affected. The consumer already uses
the server socket factory of the decorated {{SSLContext}}.
De-duplicating camel-netty's private copy of the ordering logic
({{SSLEngineFactory.applyPqcNamedGroups}}) is left out of this issue: it builds
on the refactor in CAMEL-26545, which turns that logic into a pure function,
and is better done once that has landed.
> the transports that map SSLContextParameters onto their own TLS stack
> silently drop namedGroups and signatureSchemes
> --------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26546
> URL: https://issues.apache.org/jira/browse/CAMEL-26546
> Project: Camel
> Issue Type: Bug
> Components: camel-kafka, camel-platform-http, camel-vertx
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
>
> Since CAMEL-23154 (4.19) {{SSLContextParameters}} auto-prefers the hybrid
> post-quantum group {{X25519MLKEM768}}, and the security guide states this
> applies to *all* {{SSLContextParameters}}. It does not.
> A component only gets the preference when it uses the decorated
> {{SSLContext}} returned by {{createSSLContext()}}. The components that
> instead read the key and trust material out of {{SSLContextParameters}} and
> hand it to a native TLS stack keep the protocol and the cipher suites and
> drop {{namedGroups}} and {{signatureSchemes}}, with no warning:
> * {{camel-kafka}}:
> {{KafkaClientConfiguration.applySslConfigurationFromContext()}} maps
> protocol, provider, cipher suites, enabled protocols and the two key stores.
> Named groups and signature schemes never reach the Kafka client.
> * {{camel-vertx-common}}: {{VertxHelper.setupSSLOptions()}} forwards cipher
> suites and protocols only. This covers {{camel-platform-http-vertx}} - the
> embedded HTTP server used by camel-main and Camel JBang - plus
> {{camel-vertx-http}} and {{camel-vertx-websocket}}.
> * {{camel-thrift}}: {{ThriftProducer}} and {{ThriftConsumer}} build
> {{TSSLTransportParameters}} from the key store path and password and drop
> everything else.
> {{camel-elasticsearch}}, {{camel-elasticsearch-rest-client}} and
> {{camel-solr}} are *not* affected: they pass the decorated {{SSLContext}}
> through.
> {{camel-netty}} works around the problem with its own copy of the ordering
> logic, {{SSLEngineFactory.applyPqcNamedGroups()}}, so the same algorithm now
> lives in two places and in neither of them reusable.
> Expected:
> * one shared helper in camel-api/camel-support, used by camel-netty and by
> every transport that can apply it;
> * a transport that cannot express named groups must say so (warn once)
> instead of dropping a configured value silently;
> * correct the "all SSLContextParameters" claim in {{security.adoc}} and state
> per transport what is honoured.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)