0

I'm attempting to limit the SSL cipher suites that are able to be used when connecting to an ActiveMQ broker by using the transport.enabledCipherSuites attribute in the transportConnector element. This is on a RHEL 7 server running ActiveMQ "Classic" 5.15.5 with OpenJDK 1.8.0_342.

Is it possible to limit the cipher suites that clients can connect to the ActiveMQ broker with on the broker side? If so, how does it work?

Here is my transportConnector:

<transportConnectors>
  <transportConnector name="ssl" uri="ssl://0.0.0.0:61616?transport.enabledCipherSuites=DHE-RSA-AES256-GCM-SHA384&amp;transport.enabledProtocols=TLSv1.2&amp;needClientAuth=true"/>
</transportConnectors>

The ActiveMQ service starts up, and port 61616 is binding properly. Testing the cipher using openssl I am able to connect with a cipher other than the one specified.

Here is my openssl command that I expect to fail, but it is connecting successfully:

openssl s_client -connect server.example.com:61616 -cipher 'ECDHE-RSA-AES256-GCM-SHA384'

Considering that everything is starting properly, I feel like I am misunderstanding what the transport.enabledCipherSuites attribute is doing.

Justin Bertram
  • 29,372
  • 4
  • 21
  • 43
Natolio
  • 116
  • 3
  • I did mean 5.15.5, sorry for the typo. I've corrected the version with an edit. – Natolio Apr 28 '23 at 15:52
  • What version of Java JDK? RHEL 7 is quite dated and may not have the latest ciphers. Also.. you may have a type-o-- the cipher names don't match. – Matt Pavlovich Apr 28 '23 at 16:04
  • JDK: openjdk version 1.8.0_342, the cipher names are not supposed to match above. The goal is to enforce specific ciphers with the hope that others cannot connect. My example was setting one, and then testing against a different one that still connected when I was expecting it to fail. – Natolio Apr 28 '23 at 16:22
  • Need to share the output, or add verbose output to the openssl command. Also, may need to enable ssl debugging on the ActiveMQ server-side – Matt Pavlovich Apr 28 '23 at 16:54
  • Does your comment imply that the `transport.enabledCipherSuites` that I've set above should be limiting the connection to the one that I've set? Or is it not that straightforward? – Natolio Apr 28 '23 at 17:08
  • 1
    FWIW, if I do this same thing in ActiveMQ Artemis it works as you'd expect. The broker logs `javax.net.ssl.SSLHandshakeException: no cipher suites in common`. – Justin Bertram Apr 28 '23 at 18:00
  • @Natolio Yes, limiting the SSL cipherSuites should work as expected. Specify the list and it is restricted. – Matt Pavlovich Apr 28 '23 at 19:25
  • FWIW, if you specify an _invalid_ cipher name in ActiveMQ Artemis the broker logs `AMQ224059: Invalid cipher suite specified. Supported cipher suites are: ` and then `java.lang.IllegalArgumentException: Unsupported CipherSuite: ` and the client is unable to connect. This would seem a bit safer than ignoring an invalid cipher configuration and falling back to the default. – Justin Bertram Apr 28 '23 at 19:56
  • @Natolio, did you get this sorted? – Justin Bertram May 01 '23 at 19:39
  • Not yet, I'm just getting back to looking at it from the weekend. I do not think that switching to Artemis is currently an option for me right now though. – Natolio May 01 '23 at 19:44
  • I'd broken the string out into multiple lines following this answer as an example: https://stackoverflow.com/questions/39793498/activemq-how-do-i-make-the-transportconnector-uri-more-readable and I think that formatting was causing some things to be ignored. Combining back to one line gave failures when attempting to start the service, so I tried the IANA naming for the same cipher and that seems to have taken properly. – Natolio May 01 '23 at 20:11

1 Answers1

0

Use a valid cipher name vs an invalid one. I suspect Java is falling back to a set of ciphers since the named one does not exist.

In your test:

  1. Set the server to valid 'cipherA'
  2. Command line openssl to use valid 'cipherB'

SSL negotiation should fail, since they mismatch

Matt Pavlovich
  • 4,087
  • 1
  • 9
  • 17
  • Could you expound on "the named one does not exist"? `DHE-RSA-AES256-GCM-SHA384` both exists and is listed by java when printing out the list of ciphers given by getSupportedCipherSuites() under the name `TLS_DHE_RSA_WITH_AES_256_GCM_SHA384`. The documentation I've read for activemq says to use the openssl name for the cipher, which is what I've done. However I've also tested using the IANA name with the same result. I've also attempted using multiple other valid cipher suites and the result is the same. I agree the behavior aligns with what you said, but am failing to see my mistake. – Natolio Apr 28 '23 at 20:20