Do you have a clear idea of what you would change if you forked ActiveMQ "Classic"? If so, you could send that change as a PR, and it could potentially be incorporated into the next release. Given what you've observed regarding Java's SSLServerSocket and SSLParameters it seems like the JDK doesn't provide applications with any options here. It's not clear what the broker might do to support your use-case.
If BouncyCastle provides the configuration you need can you not integrate BouncyCastle with the broker's JVM as the security provider? If using ActiveMQ Artemis is an option for you it provides integration with OpenSSL so if you can configure what you need in OpenSSL then that also may be a possibility for you. Justin On Wed, Nov 16, 2022 at 9:42 AM Frank Crow <fjcrow2...@gmail.com> wrote: > Yeah, I'm pretty familiar with the javax.net.ssl package, related system > properties, security providers and their configurations. I'm also > familiar with other middleware products that offer a specific configuration > item for elliptic curves (e.g., PostgreSQL, OpenSSL, etc.). I'm fairly > confident that, unless I fork ActiveMQ and implement that myself, there is > no external configuration, property or even bean that I could add to make > it happen. > > Looking at the ActiveMQ "SSL Transport Reference" we see that such > *transport > *options are passed to SSLServerSocket which, if you read through the > Javadoc, is really handled by the SSLParameters and even that has zero > provision for ECDH parameters. Many products that support very granular > encryption configuration do so via 3rd party libraries such as > BouncyCastle. > > So, I think that, unless anyone knows differently, ActiveMQ does not > support what I'm looking for by any means. > > Thanks, > Frank > > > On Tue, Nov 15, 2022 at 7:07 PM Justin Bertram <jbert...@apache.org> > wrote: > > > The broker delegates all this work to the JVM in the first place so I > think > > you're more likely to find what you're looking for in the JVM directly. > > Even the value for the "transport.enabledCipherSuites" parameter is > passed > > through to the underlying SSL implementation provided by the JVM. > > > > Have you investigated this from the JVM's perspective? > > > > > > Justin > > > > On Tue, Nov 15, 2022 at 3:33 PM Frank Crow <fjcrow2...@gmail.com> wrote: > > > > > No because, the ability to specify cipher suites does not include any > way > > > to specify the specific type of elliptic curve. > > > > > > At the moment, the configuration that is in place is using the > > > ECDHE-RSA-AES256-GCM-SHA384 cipher. > > > > > > The ECDHE key exchange is apparently using P-256 by default. I need > it > > to > > > be stronger or I need to document that I am unable to change that > > > configuration item. > > > > > > > > > Thanks, > > > Frank > > > > > > > > > On Tue, Nov 15, 2022 at 4:21 PM Justin Bertram <jbert...@apache.org> > > > wrote: > > > > > > > Did you try using the "transport.enabledCipherSuites" parameter > > mentioned > > > > here [1]? > > > > > > > > > > > > Justin > > > > > > > > [1] https://activemq.apache.org/ssl-transport-reference > > > > > > > > On Tue, Nov 15, 2022 at 2:16 PM Frank Crow <fjcrow2...@gmail.com> > > wrote: > > > > > > > > > Hello all, > > > > > > > > > > Does anyone know if it is possible to specify which elliptic curve > > will > > > > be > > > > > used by the broker for ECDHE key exchanges? Currently I have TLS > > > enabled > > > > > and I'm seeing that it is using a 256-bit (P-256) elliptic curve. > I > > > > have > > > > > requirements for 384-bit elliptic curves or better. > > > > > > > > > > Is there some transport.option that I can use or is there some > other > > > > method > > > > > to configure the elliptic curve that ActiveMQ uses? > > > > > > > > > > > > > > > Thanks, > > > > > -- > > > > > Frank > > > > > > > > > > > > > > > > > > -- > > > Frank > > > > > > > > -- > Frank >