Nice!
On 2022-11-17, 6:23 AM, "Frank Crow" <fjcrow2...@gmail.com> wrote:
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you can confirm the sender and know the
content is safe.
Hey Lucas,
I tried that on a development VM this morning and that (the namedGroups)
worked perfectly! For my requirements, I only need FIPS-approved and
384-bit or better, so something as simple as:
export ACTIVEMQ_OPTS='-Djdk.tls.namedGroups=secp384r1'
Covers the requirement. Reading around the net regarding EC, I think I'll
also include secp521r1 but that's about it. At least until FIPS 140-3
kicks in.
Thanks!
-Frank
On Wed, Nov 16, 2022 at 1:04 PM Frank Crow <fjcrow2...@gmail.com> wrote:
> Hey Lucas,
>
> I'll definitely give that a try. Thanks!
>
> -Frank
>
>
> On Wed, Nov 16, 2022 at 12:14 PM Tetreault, Lucas
> <tetlu...@amazon.com.invalid> wrote:
>
>> Hey Frank,
>>
>> There are loads of configuration options available, e.g.:
>> https://www.java.com/en/configure_crypto.html
>>
>> You should be able to enable only specific curves (
>> https://www.java.com/en/configure_crypto.html#DisablenonNIST) using
>> something like:
>>
>> export ACTIVEMQ_OPTS='-Djdk.tls.namedGroups="secp256r1, secp384r1,
>> secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1,
>> sect571r1, secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144,
>> ffdhe8192"'
>>
>> Hopefully that helps!
>>
>> Lucas
>>
>> On 2022-11-16, 9:31 AM, "Justin Bertram" <jbert...@apache.org> wrote:
>>
>> CAUTION: This email originated from outside of the organization. Do
>> not click links or open attachments unless you can confirm the sender and
>> know the content is safe.
>>
>>
>>
>> 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
>> >
>>
>>
>
> --
> Frank
>
--
Frank
