[ 
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)

Reply via email to