[rabbitmq-discuss] AMQP authentication with RabbitMQ

Wed Jul 8 20:45:51 BST 2009

Okay, I think Laurens original issue was that she wanted RabbitMQ to
verify SSL connections -- not individual messages... with the idea of
different client certificates being allowed access to different
vhosts.

So, based on this, there's no need to have consumers verify
signed/encrypted messages ... since the logic of comparing credentials
per vhost is more suited on the RabbitMQ server than pushing that
verification to each consumer.  I agree that if you're looking for
end-to-end security, signing/encrypting/verifying messages certainly
prevents any consumers from handling untrusted data.  However, having
only this signing/encrypting/verifying capability at the end points
(producer/consumer) and doing nothing on RabbitMQ does not address the
issue of dealing with an _untrusted_ producer from shoving malformed
messages onto RabbitMQ -- although these messages would eventually be
discarded by the consumer, it could still end up being a
denial-of-service (DoS) condition.

> Second, you have a case where you simply want to your consumer or
> publisher to know basic details such as the server's DN, the cipher
> used, etc.  In that case, the server can use stunnel and then the
> client's AMQP library must understand SSL.  This provides, at a minimum,
> verification of the server's identity to the clients (otherwise, someone
> could install a rogue stunnel proxy and you'd never know!)

I think this is closer (but not exactly) what Laurens was looking for.
 Specifically, the RabbitMQ server needs to verify the CLIENT's
certificate credentials (not any server certs) -- specifically (I'm
guessing) verifying the client's certificate is valid and that its
path is valid (which stunnel can already do for you, given a valid set
of CA certificates to use).  But also, look at the client
certificate's DN and depending on what the DN matches... allow or deny
access to the corresponding vhost channel.

After thinking about it further, yes, this capability would definitely
require modifying the RabbitMQ server's source code... the trick is
whether or not stunnel exposes the client certificate's DN as an
environment variable which can then be used inside of the Erlang code.
 If that's not possible, then Lauren would have to not use stunnel and
simply develop a new wrapper which talks directly to the OpenSSL
libraries.

-- Darien

On Wed, Jul 8, 2009 at 3:19 PM, eric<eric at grokthis.net> wrote:
> On Wed, 2009-07-08 at 14:55 -0400, Darien Kindlund wrote:
>> Thanks for the clarification.  So what you're saying is: "If you need
>> to access these environment variables, don't use stunnel and just have
>> your client application talk to OpenSSL directly."
>
> There are a few use-cases to consider here.
>
> First, is the use-case where you simply want encryption and don't care
> about knowing how it is done.  That is easy, you can just use stunnel
> directly on both ends.  This is encryption pure and simple, without any
> AAA.
>
> Second, you have a case where you simply want to your consumer or
> publisher to know basic details such as the server's DN, the cipher
> used, etc.  In that case, the server can use stunnel and then the
> client's AMQP library must understand SSL.  This provides, at a minimum,
> verification of the server's identity to the clients (otherwise, someone
> could install a rogue stunnel proxy and you'd never know!)
>
> Third, there are certainly use-cases where a publisher speaks SSL with a
> client-certificate, and the consuming client wants to know where the
> message came from, which client published the message.  This is
> impossible without modifications to RabbitMQ itself and, more
> importantly, as I understand it, the AMQP protocol.
>
> For use-case #3, your best bet is to implement the solution to the
> second use-case and then having the contents of your messages signed.
> This is how e-mail is done currently, and it works reasonably well.
>
> Before anyone publicly suggests mentions DTLS or SCTP, they only solve
> the transport issues and do not solve any AAA issues for Rabbit.
>
> --
> Regards,
> Eric Windisch
>
>