Turning off isecure renegotiation in RabbitMQ

[Surabhi Diwan Ahuja]

Hi,

We have a request from our customers to turn off insecure re-negotiation in RabbitMQ.

This is the general info about our systems:

 rabbitmqctl status
Status of node rabbit@localhost ...
[{pid,27762},
{running_applications,[{rabbit,"RabbitMQ","3.2.4"}, and Erlang
 
vcac148-085-023:~ # erl
Erlang R16B03 (erts-5.10.4) [source] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false]
 
Eshell V5.10.4  (abort with ^G)
1> erlang:system_info(otp_release).
"R16B03"
2>

rabbitmq.config (We have turned off SSLv3 and reduced the cipher sets)

[
  {ssl, [{versions, ['tlsv1.2', 'tlsv1.1',tlsv1]},
 {ciphers, ["DHE-RSA-AES128-SHA", "DHE-RSA-AES256-SHA", "AES256-SHA", "AES128-SHA"]}
        ]},
  {rabbit, [
     {ssl_listeners, [5672]},
     {tcp_listeners, []},
     {ssl_options, [{cacertfile,"/*/cacert.pem"},
                    {certfile,"/*/server.pem"},
                    {keyfile,"/*/server.pem"},
                    {verify,verify_peer},
                    {fail_if_no_peer_cert,false},
                    {versions, ['tlsv1.2', 'tlsv1.1',tlsv1]},
                    {ciphers, ["DHE-RSA-AES128-SHA", "DHE-RSA-AES256-SHA", "AES256-SHA", "AES128-SHA"]}
                   ]},
     {heartbeat,30}
   ]}
].


We are using the tool "sslyze"  to test for the weak re-negotiation https://code.google.com/p/sslyze/wiki/InsecureRenegotiation

This is the output for our system

python sslyze.py --reneg hostname:5672



 REGISTERING AVAILABLE PLUGINS
 -----------------------------

   PluginCertInfo - OK
   PluginOpenSSLCipherSuites - OK
   PluginSessionRenegotiation - OK
   PluginSessionResumption - OK



 CHECKING HOST(S) AVAILABILITY
 -----------------------------

   hostname:5672 => 10.152.14.182:5672



 SCAN RESULTS FOR hostname:5672 - 10.152.14.182:5672
 -------------------------------------------------------------------------

  * Session Renegotiation :
      Client-initiated Renegotiations: Honored
      Secure Renegotiation: Not Supported



 SCAN COMPLETED IN 0.59 S

And the test clearly says that

A server is vulnerable to insecure renegotiation if:

• It honors client-initiated renegotiations.
• It doesn't support secure renegotiations which seems to be the case above.
  

Any inputs on how we can stop this behavior?

Thanks!

Surabhi

[Jean-Sébastien Pédron]

On 09.12.2014 20:46, Surabhi Diwan Ahuja wrote:
> Hi,

Hi!

> A server is vulnerable to insecure renegotiation if:
>

> * It honors client-initiated renegotiations.
> * It doesn't support secure renegotiations which seems to be the case

> above.
>
> Any inputs on how we can stop this behavior?

To only accept secure renogetiations, try to add the following option to
the ssl_options:
{secure_renegotiate, true}

All ssl options available in Erlang 17.x are documented here:
http://www.erlang.org/doc/man/ssl.html#id61579

AFAIK, there's no way to disable client-initiated renegotiations completely.

--
Jean-Sébastien Pédron

[Surabhi Diwan Ahuja]

Thanks Jean for the prompt reply,

I did make the change as below : and restarted my RabbitMQ,

[
  {ssl, [{versions, ['tlsv1.2', 'tlsv1.1',tlsv1]},
  {ciphers, ["DHE-RSA-AES128-SHA", "DHE-RSA-AES256-SHA", "AES256-SHA", "AES128-SHA"]},

  {secure_renegotiate, true}

        ]},
  {rabbit, [
     {ssl_listeners, [5672]},
     {tcp_listeners, []},

     {ssl_options, [{cacertfile,"/etc/apache2/vcacca/cacert.pem"},
                    {certfile,"/etc/apache2/server.pem"},
                    {keyfile,"/etc/apache2/server.pem"},

                    {verify,verify_peer},
                    {fail_if_no_peer_cert,false},
                    {versions, ['tlsv1.2', 'tlsv1.1',tlsv1]},
                    {ciphers, ["DHE-RSA-AES128-SHA", "DHE-RSA-AES256-SHA", "AES256-SHA", "AES128-SHA"]},

                    {secure_renegotiate, true}
                   ]},
     {heartbeat,30}
   ]}
].

but no change in the output of sslyze. Or for that matter even openssl connect says "secure re-negotiation is not supported" even after that change.

vcac152-014-182:/var/log/vcac # openssl s_client -connect 127.0.0.1:5672 -ssl3
CONNECTED(00000003)
140614648882856:error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version:s3_pkt.c:1217:SSL alert number 70
140614648882856:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1418156699
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)

--
You received this message because you are subscribed to a topic in the Google Groups "rabbitmq-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rabbitmq-users/BJ7isQFDYrI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send an email to rabbitm...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Klishin]

Known ssl app issue on R16:
http://erlang.org/pipermail/erlang-bugs/2014-January/003984.html

I suspect the fix posted in the thread is in 17.x.
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Surabhi Diwan Ahuja]

Great! Thanks...that makes sense.

 - Would a RabbitMQ upgrade take care of the Erlang upgrade too? Or is that we need to do separately.

 - Our product plans to upgrade from RabbitMQ 3.4.2 to 3.4.0+ to disable SSLv3 out of the box. Will that upgrade address this issue too?

Thanks!
Surabhi

[Michael Klishin]

 On 10 December 2014 at 01:04:47, Surabhi Diwan Ahuja (diwan....@gmail.com) wrote:
> Great! Thanks...that makes sense.
>
> - Would a RabbitMQ upgrade take care of the Erlang upgrade too?
> Or is that we need to do separately.

Except for the standalone Mac builds, RabbitMQ does not include Erlang. Erlang has to be upgraded
separately. When you upgrade Hadoop or Cassandra, it doesn't change your JDK version ;)

> - Our product plans to upgrade from RabbitMQ 3.4.2 to 3.4.0+ to
> disable SSLv3 out of the box. Will that upgrade address this issue
> too?

I assume you mean 3.2.4. This is an Erlang issue (that said, upgrading RabbitMQ to 3.4.2 is very welcomed
by the Rabbit team!).

[Surabhi Diwan Ahuja]

Ok Great! I will add this information to our RabbitMQ upgrade story.

[Gunjan Thapliyal]

Hi

Replying on the post as I had a question on the discussion that has happened.

Was SSL secure re-negotiation checked and seen to be working with the use of Erlang 17 or greater?

Thanks

Gunjan

[Michael Klishin]

I have personally used the option in testssl.sh [1] tests on Erlang 18.3 and then 21.x (recently).

I haven't inspected the traffic or tried to trigger renegotiation in the client but according to [1],

the option was correctly disabled (which is the recommended option [2]).

HTH.

1. https://testssl.sh/

2. https://www.rabbitmq.com/ssl.html#tls-evaluation-tools

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Gunjan Thapliyal]

Thanks. Looks like the tests have been run

I am checking the "rabbitmqctl environment" to verify the defaults. I do not see "ssl_options.client_renegotiation". I am running Rabbit 3.7.7 with Erlang 20.

Also with the mentioned flag as false as per the document, is there no renegotiation? And thus the other flag "ssl_options.secure_renegotiate" is meaningless till the first flag is turned on? Apology in advance if being dumb.

Thanks

Gunjan

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitm...@googlegroups.com.

To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Klishin]

We cannot suggest why you don't see the option as you haven't posted your config files.

I believe renegotiation is allowed by default in Erlang's TLS implementation. This may be specific to TLS version used and Erlang release. Either way, explicitly disabling client initiated session renegotiation is a good idea. See the section on TLS setup evaluation linked to earlier.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.

To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Staff Software Engineer, Pivotal/RabbitMQ