I am trying to demonstrate to others that my queue is using SSL, however from the RabbitMQ web management tools there seems to be no distinction over which queues are using SSL and which are not.
Using RabbitMQ management on localhost, I am able to see all my queues. I have set up SSL on port 5671 successfully using the troubleshooting from RabbitMQ website.
Using MassTransit I have configured my incoming bus to use localhost:5671/my_queue_name with a client certificate and all is working successfully - I just can't confirm to others that the queue is secure. If I get a message from the queue using the web management tools, I can read the (JSON) message in plain text. Any ideas how I can prove my messages are secure?
I've attempted using BusDriver to peek the queues but get nothing back (independent of whether is SSL or not).
SSL is used to secure connections, not to encrypt queue contents.
What SSL gives you is that communication from clients to RabbitMQ will be encrypted, so you could theoretically be sure that nobody tampered with your messages.
Also if you need to validate that the sender of the message is a particular user, you could use this RabbitMQ extension: http://www.rabbitmq.com/validated-user-id.html
Related
We have been migrating to .net core console app microservices. currently, each microservice works in a chain and puts messages in rabbitmq, then the next service picks a message from rabbitmq, processes it, then puts in another rabbitmq....we have around 9 services.
We are seeing issues where services fail and have no idea why, but often see problems with rabbitmq connections or network issues hitting the next server (some vm's have all services hosted on the same box, others are distributed between boxes)
I've been looking at envoy proxy as it deals with the circuit breaker etc stuff and claims to have observability
However, I cannot find anywhere online that has anyone using envoy proxy with rabbitmq
Can envoy proxy be used with rabbitmq in this manner?
Or does envoy proxy act as the queue?
We deal with about 4,000 messages a sec currently, and we need to process in near as real-time as possible.
Envoy does not act as the queue, so it can't replace your message-based communication system. It can, however, proxy traffic to/from the RabbitMQ servers to give you some bits of what you're looking for.
What you'd do is use the TCP Proxy capability to setup TCP reverse proxies to RabbitMQ. Then your servers should all connect to the Envoy proxy rather than directly to the message queue. Envoy's built in stats will then output metrics on the TCP connections (all the RabbitMQ protocols seem to be TCP) that it handles. It also does intrinsically support circuit breakers, timeouts, retries, etc, so you'll get all those. But you'll definitely have to tweak those to your particular deployment.
We've done this pattern multiple times at my company, just with Kafka rather than RabbitMQ. However, since they're both TCP based it should work similarly.
I have done an SSL configuration for my IBM MQ v9, created a Java client, and added the certificates both sides. A Put and Get messages works fine. My issue is I'm able to browse the message using the MQ Explorer in the server. Is it because the message is decrypted and shown? Can I keep this message encrypted to a MQ Admin user who has access to the MQ explorer.
Any advice is very much appreciated.
Thanks in advance,
Yasothar
Configuring encryption at the channel level only encrypts data in motion (on the network).
Messages on a queue are not encrypted unless you do this at the application layer or use the IBM MQ Advanced Message Security (AMS) extension of the product, this requires additional configuration with different certs to represent the putting and getting applications as well as policies to tell MQ AMS what to encrypt and who can receive.
Even with IBM MQ AMS configured, someone with MQ admin authority can still override configurations to allow viewing of messages sent, since the the MQ admin controls the policy, so can easily add themselfs as a new recipient so they can also view message that are sent.
I have a chat implementation working with CometD.
On front end I have a Client that has a clientId=123 and is talking to VirtualMachine-1
The longpolling connection between the VirtualMachine-1 and the Client is done through the clientId. When the connection is established during the handshake, VirtualMachine-1 registers the 123 clientId as it's own and accepts its data.
For some reason, if VM-1 is restarted or FAILS. The longpolling connection between Client and VM-1 is disconnected (since the VirtualMachine-1 is dead, the heartbeats would fail, thus it would become disconnected).
In which case, CometD loadBalancer will re-route the Client communication to a new VirtualMachine-2. However, since VirtualMachine-2 has different clientId it is not able to understand the "123" coming from the Client.
My question is - what is the cometD behavior in this case? How does it re-route the traffic from VM-1 to a new VM-2 to successfully go through handshaking process?
When a CometD client is redirected to the second server by the load balancer, the second server does not know about this client.
The client will send a /meta/connect message with clientId=123, and the second server will reply with a 402::unknown_session and advice: {reconnect: "handshake"}.
When receiving the advice to re-handshake, the client will send a /meta/handshake message and will get a new clientId=456 from the second server.
Upon handshake, a well written CometD application will subscribe (even for dynamic subscriptions) to all needed channels, and eventually be restored to function as before, almost transparently.
Messages published to the client during the switch from one server to the other are completely lost: CometD does not implement any persistent feature.
However, persisting messages until the client acknowledged them is possible: CometD offers a number of listeners that are invoked by the CometD implementation, and through these listeners an application can persist messages (or other information) into their own choice of persistent (and possibly distributed) store: Redis, RDBMS, etc.
CometD handles reconnection transparently for you - it just takes a few messages between client and the new server.
You also want to read about CometD's in-memory clustering features.
I am planning to implement SSL connection with RPC structure in RabbitMQ, where I have RPC server and one RPC client. My understanding is not very clear about the SSL certificate exchange in RabbitMQ. I refered https://www.rabbitmq.com/ssl.html before. My questions are:
Do I have to make connection in my RPCServer as well as in RPCClient code?
Will RPCServer and RPCClient both act as my RabbitMQ clients? If yes, then will I have to create different certificates for both?
Please help me on this as soon as possible.
As the title says - i have 3 servers:
server-1 [wcf services]
server-2 [wcf services]
server-3 [esb using rhino.esb]
So -
server 1 publishes message to server-3 esb
server 2 subscribes to messages from server 1 via server-3 esb
do they all need to be in the same domain or anything?
For security there is no difference between public and private queues - "public" just means published in Active Directory.
Also, you need to differentiate between "different domain" and "different forest". I assume you mean the latter. Two domains in the same forest share the same security database so would not be a problem.
Do not regard Access Control Lists on queues as being a robust form of security. A message can be sent with the SID of any account to get round the queue permissions. Authentication with internel (MSMQ) or external certificates is a much better alternative if security is an issue.
How to send authenticated MSMQ messages without using a domain account
Authenticating MSMQ messages between forests
Cross-forest MSMQ? You need to be trusting
"How do I send MSMQ messages between domains?"
Understanding how MSMQ security blocks RPC traffic
Cheers
John Breakwell
No. But its less secure or more complicated. Depending if you are using no security ( everyone has access) or certificates.
Look at Securing Messages Using Transport Security.
Private queues are just accessed via a TCP port, so there is no need for the hosting server to even be on a domain for the MSMQ queue to be accessible. However, I would recommend that you apply transport-level security at the network layer (i.e. firewalls) to prevent any unauthorised traffic from putting messages on / retrieving from the queues.