Repository navigation
Permit to pass SslParameters to ExporterBuilders for fine grain TLS configuration #8558
Description
Problem
Post quantum resistant key exchange for TLS RFC is quite stable, enough for Java to implement it in JDK 27.
So when running the JDK OpenTelemetry exporter on java 27, it'll use a post-quantum-resistant algorithm as primary choice (X25519MLKEM768), and this can be defined at the entire JVM level with jdk.tls.namedGroups property.
The issue arise when we want to enforce OTLP to use only PQ-resistant algorithm (by setting jdk.tls.namedGroups=X25519MLKEM768 for example) while needing to call external services that does not offer yet a PQ-resistant key exchange algorithm.
Since the property affects the whole JVM other HttpClients will be impacted.
Proposed solution
Since HttpClient builder accepts javax.net.ssl.SSLParameters, I'd like to be able to pass an instance of these parameters alongside the SslContext in xxxExporterBuilder (such as OtlpHttpLogRecordExporterBuilder).
This way we could easily low level parameters of future TLS handshakes.
Alternatives/Workaround
Since one can currently pass an SslContext, it's possible to create a custom SslContext that will set SslParameters to the SslEngines it produces. But that's about 150 lines of boilerplate code...
Additional context
PostQuantum resistance is a hot topic right now, lots of countries have set deadlines for critical software to become PQ-resistant.
Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.
Activity
cfcromn commentedon Jul 7, 2026
Hi maintainers, I’m interested in investigating this feature request.
From the issue description, the goal seems to be allowing per-exporter TLS configuration by passing
SSLParametersto OTLP HTTP exporter builders, instead of relying on JVM-wide properties such asjdk.tls.namedGroups.Before attempting an implementation, I’d like to confirm the preferred API direction:
setSslParameters(SSLParameters sslParameters)method on the OTLP HTTP exporter builders?HttpClientsender, or should OkHttp-based senders also support it where possible?sslContext(...)andsslParameters(...)are configured, should the builder pass both to the underlying HTTP client?SSLParametersis mutable, should the builder defensively copy it when it is provided?If this direction sounds reasonable, I’d be happy to prepare a focused PR with tests covering propagation of the configured
SSLParameters.jack-berg commentedon Jul 24, 2026
I've been investigating this as part of #8610, which solves the problem of configuring which TLS protocols should be. TLS protocols also shows up in
SSLParameters, and so I considered whether a genericsetSslParameter(SSLParameters)might be the preferred API design. My opinion is no.SSLParametersis a bag of many SSL/TLS parameters, many of which we don't support, and some of which its not clear if we could even support across our suite of senders.Instead, I think that we gradually add the configuration options we need, some of which are part of
SSLParameters, as standalone setters.In this case, I think we could more simply add
setEnabledCipherSuites(List<String>)to accommodate this use case.raheelshahzad commentedon Sep 24, 2026
I'd like to pick up the standalone setter approach described above. Plan:
setEnabledCipherSuites(List<String>)to the OTLP HTTP and gRPC exporter builders (traces, metrics, logs, profiles), mirroring the structure ofsetEnabledProtocolsfrom Add setEnabledProtocols option to OTLP exporter builders #8610.HttpSenderConfig/GrpcSenderConfigto the JDK sender (SSLParameters.setCipherSuites) and the OkHttp senders (ConnectionSpec.Builder.cipherSuites). The upstream gRPC managed-channel sender is left alone, same as for protocols.TLS_AES_128_GCM_SHA256.Unless there's an objection I'll open a PR in the next few days.
Add setEnabledCipherSuites option to OTLP exporter builders
Add setEnabledCipherSuites option to OTLP exporter builders