[ 
https://issues.apache.org/jira/browse/CAMEL-25102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned CAMEL-25102:
-----------------------------------

    Assignee: Claus Ibsen

> camel-core - JSSE utility and camel.ssl configuration: fix bugs found in a 
> deep review
> --------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25102
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25102
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>            Priority: Minor
>
> A review of the JSSE utility ({{SSLContextParameters}}) and the 
> {{camel.ssl.*}} configuration of camel-main found these bugs:
> # A filter with only exclude patterns (such as {{camel.ssl.namedGroupsExclude 
> = X25519MLKEM768}}, the documented way to disable the post-quantum named 
> groups, or {{camel.ssl.cipherSuitesExclude}}) includes nothing, so every TLS 
> handshake fails ("No common named group" / "No appropriate protocol").
> # A signature schemes filter ({{signatureSchemesFilter}}, 
> {{camel.ssl.signatureSchemesInclude/Exclude}}) always configures an empty 
> list on JVMs that do not provide their default signature schemes (JDK 25 and 
> older return null), so every TLS handshake fails ("No supported signature 
> algorithm"). The existing test asserted this.
> # The SNI host names of the client parameters are only set on {{SSLSocket}}, 
> not on {{SSLEngine}}, so engine based clients (such as camel-netty) send no 
> SNI.
> # Property placeholders in filter patterns are not resolved when configured 
> from Java (the XML factory beans do resolve them): {{addInclude("{{inc}}")}} 
> fails with PatternSyntaxException.
> # SNI host names cannot use property placeholders (they are validated when 
> set).
> # The auto-configured post-quantum named groups are left on the 
> SSLContextParameters instance (and then regarded as user configuration) when 
> creating the SSLContext fails.
> # {{clientAuthentication}} is case-sensitive ({{want}} fails).
> # {{camel.ssl.trustStore=#bean:name}} fails, as the KeyStore bean is 
> converted to a String when binding the properties ({{Could not open 
> java.security.KeyStore@...}}), so the {{#bean:}} support never works.
> # {{camel.ssl.*}} with only a trust store (or trustAllCertificates), such as 
> a client that must trust a private certificate authority, creates no global 
> SSL configuration (only a WARN to set a keystore).
> # Documentation: the default secure socket protocol is TLSv1.3 (not TLS), 
> {{createSSLContext()}} does not exist (needs the CamelContext), and the 
> {{camel.ssl.signatureSchemes}} example used names that are not valid JSSE 
> signature scheme names.
> Not changed:
> * The toString of the SSL context parameters does not include the named 
> groups, signature schemes and their filters.
> * SSLConfigurationProperties has no secureSocketProtocols list/filter, no 
> separate key password and no trustStoreType.
> _Claude Code on behalf of Claus Ibsen_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to