[rabbitmq-discuss] AMQP authentication with RabbitMQ

Mon Jul 20 20:20:12 BST 2009

Darien, Eric, Lauren,

Darien Kindlund wrote:
> 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.

We are in the final stages of qa'ing "native" SSL support for the 
RabbitMQ server, Java, .net and Erlang clients that addressed the above. 
A description of the new functionality is available at 
https://dev.rabbitmq.com/wiki/SslSupport, and you can find the code in 
the 'bug19356' branches of the respective hg repositories.

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

The new code can verify the client certs. Access to particular vhosts, 
and specific resources can be controlled by the existing RabbitMQ 
permissions system based on the supplied user name.

Note that there is no association of subjectDNs and users, so in 
principle any user can use any trusted cert. That should be ok though as 
long as the username/password are treated as sensitive information in 
the same way as the private keys for the client certs.

Regards,

Matthias