Does Rabbitmq support Elliptic Curve Encryption?

[Shravan Kumar]

I am using rabbitmq for chat. I have already installed the ssl on machine, which work fine for Android platform, but iOS broker not able to establish connection with machine and always show SSL Handshake error. After doing some research i found that iOS required following Elliptic Curve Encryption

• Elliptic curve: secp256r1 (0x0017)
• Elliptic curve: secp384r1 (0x0018)
• Elliptic curve: secp521r1 (0x0019)

But didn't find whether rabbitmq support Elliptic Curve Encryption ?

[Michael Klishin]

Erlang provides a TLS implementation. 18.x certainly supports some ECC ciphers. I highly doubt ECC is a requirement on iOS, too.

--
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.

[Shravan Kumar]

Hi Michael

Earlier i had same thought then I decided to use my Apple Developer Technical Support instance, and here's what they have said about the query:


Attn: Shravan Kumar
Re:   CFNetwork SSLHandshake failed (-9800)

Shravan,

I’m responding to your report of problems connecting to your server
from iOS (and, incidentally, other Apple platforms).  You wrote:

> We are trying to connect to this MQTT server ssl://channel.cogxio.com,
> and already bypassed all of the ATS securities for testing purpose.
> Still, the log is throwing this error: CFNetwork SSLHandshake failed
> (-9800).

You’re correct that this is not an ATS problem.  Error -9800 is
errSSLProtocol, indicating that something went wrong at the TLS
protocol layer.

After looking at a packet trace of the failed connection it’s clear
that this failure is caused by a bug in your server.  I’ve attached a
packet trace of the failure occurring on OS X 10.11.3 (iOS and OS X
share a TLS implementation, so I expect that the failure is the same
in both cases).  I’ve included both the raw trace  (“trace-cap.pcap”)
and a decoded trace (“trace-cap.pcap.txt”).  Open the decoded trace
and look at the “Client Hello” and “Server Key Exchange” messages.
Here’s the edited highlights, for your convenience.

Secure Sockets Layer
    SSL Record Layer: Handshake Protocol: Client Hello
        …
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            …
            Extension: elliptic_curves
                Type: elliptic_curves (0x000a)
                Length: 8
                Elliptic Curves Length: 6
                Elliptic curves (3 curves)

                    Elliptic curve: secp256r1 (0x0017)
                    Elliptic curve: secp384r1 (0x0018)
                    Elliptic curve: secp521r1 (0x0019)

            …

Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
        …
        Handshake Protocol: Server Key Exchange
            Handshake Type: Server Key Exchange (12)
            Length: 329
            EC Diffie-Hellman Server Params
                Curve Type: named_curve (0x03)
                Named Curve: secp256k1 (0x0016)
                …

As you can see, in the “Client Hello” message the client tells the
server that it supports three different elliptic curves (secp256r1,
secp384r1, secp521r1).  The server must choose an elliptic curve from
this list.  However, the server has chosen a completely different
curve (secp256k1).  This is a clear violation of the TLS EC
negotiation protocol [1], and hence the connection fails.

Specifically, iOS does not support the curve chosen by the server, and
that causes the errSSLProtocol error.  You can see this in the Darwin
open source for coreTLS (the TLS implementation used by Apple
platforms).  Specifically, SSLDecodeECDHKeyParams (file URL below)
contains this code:

    switch(ctx->ecdhPeerCurve) {
        case tls_curve_secp256r1:
        case tls_curve_secp384r1:
        case tls_curve_secp521r1:
            break;
        default:
            … logging elided …
            return errSSLProtocol;
    }

<http://www.opensource.apple.com/source/coreTLS/coreTLS-82/lib/sslKeyExchange.c>

You should resolve this problem by fixing the server.  If that’s not
possible it may be possible to work around this problem on the client,
but only in some situations and definitely at the expense of security
(you’d basically have to disable the ECDHE TLS cypher suites, which
are the ones that allow for forward secrecy [2]).

Share and Enjoy
--
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
<http://www.apple.com/developer/>

[1] Specifically, Section 4 of RFC 4492 says:

    A TLS client that proposes ECC cipher suites in its ClientHello
    message SHOULD include these extensions.  Servers implementing ECC
    cipher suites MUST support these extensions, and when a client uses
    these extensions, servers MUST NOT negotiate the use of an ECC
    cipher suite unless they can complete the handshake while respecting
    the choice of curves and compression techniques specified by the
    client.
    -- <http://www.ietf.org/rfc/rfc4492.txt>

The server here is breaking the “MUST NOT” requirement above.  The
paragraph goes on to say:

    This eliminates the possibility that a negotiated ECC handshake will
    be subsequently aborted due to a client's inability to deal with the
    server's EC key.

Which is exactly what’s happened in this case.

[2] <https://en.wikipedia.org/wiki/Forward_secrecy>


On March 05, 2016 at 14:00:16 PM GMT, stus...@gmail.com wrote:

>Name: Shravan Kumar
>Person ID: xxxxxxxx
>E-mail: xxxxxxxxxx
>Team Name: xxxxxxx
>Team ID: xxxxxxx
>Team Type: Individual
>
>PLATFORM AND VERSION
>iOS
>MacBook Pro mid-2014 model
>El Capitan 10.11.3
>Xcode 7.2.1
>
>Test Device: iPhone 6s with iOS 9.2.1
>
>DESCRIPTION OF PROBLEM
>We are trying to connect to this MQTT server ssl://channel.cogxio.com, and already bypassed all of the ATS securities for testing purpose. Still, the log is throwing this error: CFNetwork SSLHandshake failed (-9800).
>
>STEPS TO REPRODUCE
>1. Pod MQTTClient-framework: https://github.com/ckrey/MQTT-Client-Framework
>2. Disable ATS and add exceptions in info.plist
>3. Connect to open MQTT Brokers: test.mosquitto.org at port 8883
>4. The log will probably you throw the error, if you follow this code.
>
>https://gist.github.com/tush4r/6df79f40eb6121e3b522
>
>On the other front, all of the non-secure connections with port: 1883 get easily connected without any trouble.

Thanks and Regards,
Shravan

--
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/N8JorI6tWIk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rabbitmq-user...@googlegroups.com.

[Michael Klishin]

RabbitMQ does not provide a TLS implementation, Erlang/OTP does. We cannot "fix it in the server."

Please report this to the Erlang mailing list and specify the exact version of Erlang used.