[
https://issues.apache.org/jira/browse/CAMEL-26549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino updated CAMEL-26549:
-------------------------------------
Description:
Both SSH stacks Camel ships propose a hybrid post-quantum key exchange ahead of
the classical groups, and neither can perform it at runtime.
* jsch 2.28.7 proposes {{mlkem768x25519-sha256}} first in its default key
exchange list, and implements ML-KEM through the JDK 24+ multi-release classes
({{META-INF/versions/24/com/jcraft/jsch/jce/MLKEM.class}}) or through the
Bouncy Castle lightweight API ({{com/jcraft/jsch/bc/MLKEM.class}}).
* Apache MINA SSHD 2.20 has {{mlkem768x25519-sha256}},
{{mlkem768nistp256-sha256}}, {{mlkem1024nistp384-sha384}} and
{{sntrup761x25519-sha512}} in {{BuiltinDHFactories}}, and its
{{org.apache.sshd.common.kex.MLKEM}} is written against
{{org.bouncycastle.crypto}}.
{{camel-ftp}} (jsch) and {{camel-mina-sftp}} (sshd-sftp) declare Bouncy Castle
with {{<scope>test</scope>}} only, so on the Java 21 baseline there is no
ML-KEM implementation on the runtime classpath: the group is dropped from the
proposal and the connection falls back to classical ECDH without a word. The
main build runs on Java 25, where jsch's multi-release path works, so no test
catches it. {{camel-jsch}} (scp) depends on {{camel-ftp}} at compile scope and
is fixed with it.
{{camel-ssh}} is not affected: it already has {{bcpg}} and {{bcpkix}} at
compile scope, which pull {{bcprov}}.
None of these components documents the post-quantum key exchange, nor that
{{keyExchangeProtocols}} (sftp, mina-sftp) and {{kex}} (ssh) *replace* the
proposal rather than adding to it - so a user who pinned a list of classical
algorithms years ago is silently stuck on classical, with no note to tell them.
was:
jsch 2.28.7 proposes {{mlkem768x25519-sha256}} first in its default key
exchange list, but it implements ML-KEM in one of two ways: through the JDK 24+
multi-release classes
({{META-INF/versions/24/com/jcraft/jsch/jce/MLKEM.class}}) or through Bouncy
Castle ({{com/jcraft/jsch/bc/MLKEM.class}}).
{{camel-ftp}} declares {{bcpg-jdk18on}} and {{bcpkix-jdk18on}} with
{{<scope>test</scope>}}, so on the Java 21 baseline there is no ML-KEM
implementation on the classpath, jsch drops the group from its proposal and the
connection falls back to classical ECDH without a word. The main build runs on
Java 25, where the multi-release path works, so no test catches it.
{{camel-ssh}} is not affected: sshd 2.20 ships {{mlkem768x25519-sha256}},
{{mlkem768nistp256-sha256}}, {{mlkem1024nistp384-sha384}} and
{{sntrup761x25519-sha512}} in {{BuiltinDHFactories}}, its ML-KEM implementation
is Bouncy Castle based, and camel-ssh has BC at compile scope.
Neither component documents the post-quantum key exchange, nor the
{{keyExchangeProtocols}} (sftp) and {{kex}} (ssh) values needed to pin or
verify it - and a user who pinned {{kex}} years ago is silently stuck on
classical.
Summary: camel-ftp, camel-jsch, camel-mina-sftp - the SFTP and SCP
clients cannot negotiate the post-quantum key exchange because Bouncy Castle is
test scoped (was: camel-ftp - SFTP cannot negotiate the post-quantum key
exchange on Java 21 because Bouncy Castle is test scoped)
> camel-ftp, camel-jsch, camel-mina-sftp - the SFTP and SCP clients cannot
> negotiate the post-quantum key exchange because Bouncy Castle is test scoped
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26549
> URL: https://issues.apache.org/jira/browse/CAMEL-26549
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
>
> Both SSH stacks Camel ships propose a hybrid post-quantum key exchange ahead
> of the classical groups, and neither can perform it at runtime.
> * jsch 2.28.7 proposes {{mlkem768x25519-sha256}} first in its default key
> exchange list, and implements ML-KEM through the JDK 24+ multi-release
> classes ({{META-INF/versions/24/com/jcraft/jsch/jce/MLKEM.class}}) or through
> the Bouncy Castle lightweight API ({{com/jcraft/jsch/bc/MLKEM.class}}).
> * Apache MINA SSHD 2.20 has {{mlkem768x25519-sha256}},
> {{mlkem768nistp256-sha256}}, {{mlkem1024nistp384-sha384}} and
> {{sntrup761x25519-sha512}} in {{BuiltinDHFactories}}, and its
> {{org.apache.sshd.common.kex.MLKEM}} is written against
> {{org.bouncycastle.crypto}}.
> {{camel-ftp}} (jsch) and {{camel-mina-sftp}} (sshd-sftp) declare Bouncy
> Castle with {{<scope>test</scope>}} only, so on the Java 21 baseline there is
> no ML-KEM implementation on the runtime classpath: the group is dropped from
> the proposal and the connection falls back to classical ECDH without a word.
> The main build runs on Java 25, where jsch's multi-release path works, so no
> test catches it. {{camel-jsch}} (scp) depends on {{camel-ftp}} at compile
> scope and is fixed with it.
> {{camel-ssh}} is not affected: it already has {{bcpg}} and {{bcpkix}} at
> compile scope, which pull {{bcprov}}.
> None of these components documents the post-quantum key exchange, nor that
> {{keyExchangeProtocols}} (sftp, mina-sftp) and {{kex}} (ssh) *replace* the
> proposal rather than adding to it - so a user who pinned a list of classical
> algorithms years ago is silently stuck on classical, with no note to tell
> them.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
