Erlang's RabbitMQ Client & SSL CommonName Verification

393 views
Skip to first unread message

Graham Christensen

unread,
Sep 24, 2017, 9:24:19 PM9/24/17
to rabbitm...@googlegroups.com

Hello,

Can the erlang rabbitmq client verify the server's tls certificate
matches its common name?

With my server configured with a commercial certificate, listening on
fizz.com:

[
{rabbit, [
{ssl_listeners, [{"0.0.0.0", 5671}]},
{ssl_options, [
{cacertfile,"${cert_dir}/fullchain.pem"},
{certfile,"${cert_dir}/cert.pem"},
{keyfile,"${cert_dir}/key.pem"},
{verify,verify_none},
{fail_if_no_peer_cert,false}]},
{log_levels, [{connection, debug}]}
]},
{rabbitmq_management, [{listener, [{port, 15672}]}]}
].


And my client connecting with verify enabled, connecting to buzz.com,
which points to the same server, serving the certificate for fizz.com:

amqp_connection:start(#amqp_params_network{
username = <<"foobar">>,
password= <<"foobar">>,
host = "buzz.com",
port = 5671,
ssl_options = [
{verify, verify_peer},
{cacertfile, "/etc/ssl/certs/ca-certificates.crt"}
{fail_if_no_peer_cert, true}
]
}).

I get no error, the client doesn't check to see if the CN matches the
hostname. Compared to openssl which has the correct behavior:

$ openssl s_client -connect buzz.com:5671 -verify_hostname buzz.com
...snip...
Verify return code: 62 (Hostname mismatch)

Can the erlang rabbitmq client verify the CN matches?

Thank you,
Graham Christensen

Michael Klishin

unread,
Sep 25, 2017, 4:50:05 AM9/25/17
to rabbitm...@googlegroups.com
Erlang's TLS implementation supports peer verification
for clients.

There is a section at the bottom of http://www.rabbitmq.com/ssl.html that covers
the Erlang client. amqp_client.ssl_options and ssl app's settings are merged with
those provided to the function:


--
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-users+unsubscribe@googlegroups.com.
To post to this group, send an email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
MK

Staff Software Engineer, Pivotal/RabbitMQ
Message has been deleted

Michael Klishin

unread,
Sep 25, 2017, 9:25:29 AM9/25/17
to rabbitm...@googlegroups.com
I know nothing about your certificates, please see http://rabbitmq.com/troubleshooting-ssl.html.

CA certificates should be sufficient for a peer to perform chain verification. In theory a peer isn't
required to provide certificates (and [1] confirms this in the server section). Assuming `openssl s_client` doesn't use a default pair of some kind,
it works fine there.

I haven't tried using Erlang TLS client without a certificate/key pair and it isn't necessarily the problem here.
It should be easy enough to configure
the client with a certificate/client pair, e.g. something generated for development [2] and
compare. Same for providing "inline" ssl_options vs. configuring amqp_client.ssl_options [3],
since they are merged.


On Mon, Sep 25, 2017 at 2:06 PM, Graham Christensen <gra...@grahamc.com> wrote:
Hi Michael,

Thank you for your reply. Since I don't need my server to validate my client's certificate, I don't pass the certfile or keyfile. This makes my usage and the provided code sample for the erlang client on https://www.rabbitmq.com/ssl.html identical. This leaves me with what I believe I should have a valid configuration. However, it isn't.

Have I passed the cacertfile wrong?
Is ca-certificates.crt not sufficient for this?
Must I send a bogus certfile/keyfile?

Thank you,
Graham
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 an email to rabbitm...@googlegroups.com.

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



--
MK

Staff Software Engineer, Pivotal/RabbitMQ

--
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-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.

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

Graham Christensen

unread,
Sep 29, 2017, 6:58:34 AM9/29/17
to Michael Klishin, rabbitm...@googlegroups.com

Hi Michael,

Thank you for the help and information. It turns out my SSL certificates
are configured correctly, however before Erlang R20, Erlang's SSL
implementation doesn't validate certificates match the server you're
connected to.

From the R20 changelog:

OTP-14197 Application(s): ssl

TLS client processes will by default call
public_key:pkix_verify_hostname/2 to verify the
hostname of the connection with the server certifcates
specified hostname during certificate path validation.
The user may explicitly disables it. Also if the
hostname can not be derived from the first argument to
connnect or is not supplied by the server name
indication option, the check will not be performed.

I hope this helps someone else in the future.

Graham
>> To post to this group, send email to rabbitm...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> MK
>
> Staff Software Engineer, Pivotal/RabbitMQ
>
> --
> 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/igSfZeRfC2k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to rabbitmq-user...@googlegroups.com.

Michael Klishin

unread,
Sep 29, 2017, 7:06:50 AM9/29/17
to Graham Christensen, rabbitm...@googlegroups.com
In other words, before OTP 20 Erlang TLS client does not perform peer verification
by default (or possibly at all?)

We should definitely mention this in the docs, thank you so much for reporting back!

>> email to rabbitmq-users+unsubscribe@googlegroups.com.
>> To post to this group, send email to rabbitmq-users@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> MK
>
> Staff Software Engineer, Pivotal/RabbitMQ
>
> --
> 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/igSfZeRfC2k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
> To post to this group, send an email to rabbitmq-users@googlegroups.com.

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

Graham Christensen

unread,
Sep 29, 2017, 7:26:04 AM9/29/17
to Michael Klishin, rabbitm...@googlegroups.com
Michael Klishin <mkli...@pivotal.io> writes:

> In other words, before OTP 20 Erlang TLS client does not perform peer
> verification
> by default (or possibly at all?)

Before 20 verify_peer would check the the certificate chain was valid,
ie the remote's certificate was signed by something in in the chain of
your provided cacerts.

Example: rabbitmq.com is signed by DigiCert. If I connect to
rabbitmq.com and pass in DigiCert's root certificate, Erlang would
accept a certificate for any domain as long as it was also signed by
DigiCert.

There is a third party library for implementing proper validation
behavior in R19: https://github.com/benoitc/ssl_verify_hostname

I'm also talking with Erlang's security team about issuing an
announcement or CVE about it.

> We should definitely mention this in the docs, thank you so much for
> reporting back!

You're welcome! It was a surprising find[0] :)

Best,
Graham

[0] though not _THAT_ surprising: Python didn't validate certificates
matched hostnames until late 2014, with 2.7.9:
https://docs.python.org/2/library/ssl.html#certificate-handling
Reply all
Reply to author
Forward
0 new messages