[rabbitmq-discuss] ssl certificate to client lookup

Tue Jul 6 18:09:26 BST 2010

On Tue, Jul 6, 2010 at 4:40 AM, Matthias Radestock
<matthias at rabbitmq.com> wrote:
> Lionel,
>
> On 06/07/10 11:11, Lionel Cons wrote:
>>
>> The "public messaging service" is exactly the model we try to work
>> towards. In such a model, the service provider needs to protect its
>> resources. Unauthenticated clients may get directed to a sacrificial
>> broker so that abuses do not harm authenticated clients. Similarly,
>> authenticated clients that do not want to expose their "identity" may
>> get a different level of service. Clients who play by the rules
>> (i.e. authentication plus traceability) may get better service.
>>
>> I don't believe you can build a decent public messaging service
>> without a minimum security.
>
> I wasn't suggesting that clients should be able to work unauthenticated, but
> that they may not want their identity passed to consumers. So the question
> is, if the authentication is only of interest to the broker, why does it get
> passed to the *consumer*? Would it instead be sufficient to retain the
> credentials internally in the broker and present them in various admin
> tools, but not pass them to the consumers? That way we would also preserve
> message fidelity.
>
>> There are two ways to achieve message authentication: outside or
>> inside of messaging.
>>
>> Outside, the producer signs the message body and the consumer checks
>> the signature. There are no requirements on the brokers but only the
>> consumer knows who the sender is. This is good for the clients, not
>> for the messaging service.
>>
>> Inside, all intermediaries (broker, proxy, shovel...) must be trusted.
>> Otherwise, a rogue intermediary could do evil things with the message.
>> This is good for the messaging service as it can control who does
>> what, not for the clients, unless they trust the messaging service.
>>
>> So to answer your question, if the consumer trusts X and Y then it can
>> know the sender identity via "inside" authentication. If it does not
>> trust the service, it has to use "outside" authentication.
>
> Right, except the consumer doesn't even know the message came via broker X.
> And, furthermore, the identity presented to broker X may be meaningless in
> the context of broker Y and the consumer.
>
> So it seems to me that if you want *consumers* to know about sender
> identities then that should be handled at the app level, outside the
> messaging layer.

I would agree if RabbitMQ did not support SSL, but since it does it
why not take advantage of the features of SSL?  I'm speaking of the
scenario where producers and consumers trust the broker but not each
other.

People who try to take care of security at the app level could easily
make mistakes that the RabbitMQ SSL implementation avoids.

>
> OTOH, servers, and those administering them, should be able to find out
> which AMQP users are responsible for certain actions (such as the creation
> of an exchange or queue, the sending or retrieval of a message) and their
> resulting artifacts (such as a created queue or exchange, or a stored
> message).
>

I'm noticing a layering issue; am I the only one?

I opted for managing many certificates instead of managing many users
on the AMQP server.  In this system a certificate represents a user.
This solution for authentication works well over many systems that
support SSL.

Certainly clients could implement their own authentication mechanism,
their own transport security, and more; however, rabbit supports SSL--
why does rabbit support SSL?  ZeroMQ doesn't and now I understand
better why they do not.  Is SSL support in rabbit designed to follow
the role of SSL for HTTPS that is primarily to establish broker/server
authenticity?

>
> Regards,
>
> Matthias.
>

-Nate